When I first started at Audicus, I followed my usual approach: interview people across departments and take stock of the existing tech stack before touching anything. One of the first things I noticed was that SOPs were all over the place. There was no standardized way of documenting processes, and no project management software was actually being used day to day.

When I dug a little deeper, I realized the company already had Jira and Confluence licenses. Nobody was using them. I pulled the cost of those licenses and realized we were paying real money every month for tools that had effectively become shelfware.

I had come across ClickUp through a YouTube channel I watched, so I compared its features and capabilities against what we actually needed. It was cheaper than what we were already paying for, and it could technically do everything Jira and Confluence were supposed to be doing for us.

On paper, Jira and Confluence made sense: Jira is a strong project management tool, and Confluence is a strong place to build SOPs and internal documentation. But neither one had actually become part of how the team worked. People weren't consistently creating tickets, and SOPs weren't living in one clear place. The company was paying for software with real value in theory, but it had quietly become shelfware.

That's one of the most common problems with internal tools: the platform can be powerful, but if people don't understand it or feel like it makes their work easier, it never gets adopted.

Within my first three weeks, I made the decision to sunset Jira and Confluence and implement ClickUp instead.

That might sound like a big change, but the actual rollout moved quickly. Within roughly the next week or two, while still handling my normal responsibilities, I onboarded the entire company of 50+ people into ClickUp.

The reason that worked was simple: ClickUp was approachable.

It gave people a clear place to create tasks, assign owners, manage due dates, organize projects, and document processes without needing a heavy amount of training. It felt more modern, more flexible, and less intimidating for teams that were not already deeply familiar with tools like Jira or Confluence.

Why ClickUp worked for SOPs

For SOPs, ClickUp Docs became especially useful.

ClickUp Docs can be organized with pages and subpages, which makes it possible to create a real internal handbook structure instead of one long document or a messy folder of disconnected files. ClickUp also has a Docs Hub, where teams can organize, search, and create Docs and wikis from one central place.

That matters because SOPs are only useful if people can actually find them.

In ClickUp, a team could have a high-level Doc for a department, then break that Doc into pages for different processes. For example, an Accounting Ops Doc could have separate pages for invoice processing, AP workflows, month-end close, vendor setup, approvals, and internal controls.

That structure made the documentation feel more like a living internal handbook than a pile of files.

It also made search easier. You could search inside Docs, use the Docs Hub, or use ClickUp's broader workspace search to find items you had permission to access. That is a big part of what makes documentation useful in a real company environment: people should not need to remember where something lives. They should be able to search for it and get to the answer quickly.

The other thing I liked about ClickUp Docs is that they were not just static pages.

You could use comments, formatting, cover images, tags, page organization, sharing permissions, and relationships. You could also connect Docs to tasks, which is what made the tool especially useful operationally.

That is where ClickUp became more than an SOP library.

A process could be written in a Doc. A task could be created from that process. A manager could assign ownership. Someone could leave a comment, ask a question, update a step, or connect the Doc to related work.

The documentation and the work were no longer completely separate.

That was the real value.

My take

This experience shaped how I think about operations tools.

The “best” tool is not always the most advanced tool. Sometimes the best tool is the one that gives the team enough structure without overwhelming them.

Jira can be excellent when you have the right workflows, the right team, and someone who knows how to manage it well. Confluence can be excellent when a company is committed to documentation and has a clear knowledge management culture.

But if a company is earlier in its operational maturity, or if the immediate goal is adoption, ClickUp can be a much easier starting point.

It gives teams a simple way to answer the basic questions that matter: what are we working on, who owns it, when is it due, where is the process documented, and what needs to happen next.

That is why I still like ClickUp. It is flexible enough to handle real work, but approachable enough that people can actually get started.

For me, that combination is what makes a tool operationally useful.

I still use ClickUp today for personal projects, planning, and keeping track of different things I am working on. It is not because I think every company should use ClickUp for everything. It is because I have seen firsthand how much value a tool can create when it lowers the barrier between “we should be more organized” and “we are actually using a system every day.”

Note: I am not affiliated with ClickUp. I just like the product and have used it firsthand in a real operating environment.

I’ve been a Salesforce admin at two different companies. Both times, I inherited a setup that had grown organically — fields nobody used, workflows nobody understood, and a general sense that the CRM was something the sales team had to deal with rather than something that helped them.

The biggest mistake companies make with Salesforce is treating it as a recording tool rather than a decision-making tool. If the only thing your CRM does is log calls and store contacts, you’re not using it — you’re just paying for an expensive Rolodex.

The unlock happens when you start designing Salesforce around how your team actually works: what decisions do they need to make, what information do they need to make them, and how do you surface that at the right moment? At Ottimate, connecting Salesforce to SaaSOptics to show invoice payment status changed how the sales team engaged with collections — suddenly they had context, and that changed behavior.

Best for: Any company serious about revenue operations. The ROI is real, but only if someone owns the admin work properly.

Watch out for: The cost scales fast. Before you add another license or another module, ask whether you’re actually using what you already have.

Before Plaid, connecting a bank account to our billing system meant micro-deposits — a process that took days, confused customers, and failed constantly. The UX was bad enough that customers who genuinely wanted to pay simply gave up. That became AR, and AR became a collections problem.

Plaid via Stripe changed that completely. Customers log in with their bank credentials, verify instantly, and are connected. The whole process takes under two minutes. After implementation, nearly every new customer had an active payment method on file from day one.

The thing I’d emphasize to anyone evaluating Plaid: it’s not just a UX improvement. It’s a structural fix. You’re not making the same broken process faster — you’re replacing the broken process entirely.

Best for: Any SaaS company collecting payment via ACH. If you have AR problems and you haven’t looked at your payment method onboarding, start there.

Watch out for: Make sure your team understands how the Stripe integration works before going live. The setup is simple, but the configuration details matter.

The knock on spreadsheets is usually that they don’t scale. That’s true — but scale isn’t the point of a spreadsheet. Speed and flexibility are. When you need to analyze something fast, test a hypothesis, or build a one-time model, nothing beats a spreadsheet.

The mistake is using spreadsheets as a permanent system instead of a diagnostic tool. A spreadsheet that tracks customer data for two years and is emailed around every week isn’t a spreadsheet — it’s a poorly designed database. At that point, you’ve grown beyond what the tool is good for.

I’ve used spreadsheets to build the first-ever AR analysis at Ottimate, to model legacy client billing, to prototype commission structures, and to track office move logistics. Every one of those was the right tool for the job at that stage. The skill is knowing when you’ve outgrown it.

Best for: Analysis, modeling, one-time projects, and any situation where you need answers fast and the data isn’t going to live there permanently.

Watch out for: The moment multiple people are editing the same spreadsheet regularly, it’s time to build something more permanent.

Jira has a reputation for being complicated. That reputation is mostly earned — but the complexity exists for a reason. At its core, Jira is an extremely flexible system for tracking work through defined states. That flexibility is exactly what makes it powerful for cross-functional ops work.

At Cardstop, I use Jira to manage product and engineering work. Coming from an ops background, the key for me was learning to think in tickets: every piece of work needs a clear definition of done, an owner, and a status. That discipline makes standups faster, makes blockers visible, and makes the relationship between ops and engineering much smoother.

For non-engineers, the most useful parts of Jira are the board views, the dependency tracking, and the ability to link bugs to business impact. If you can frame a bug as “this is causing X% of customers to fail at step Y,” engineers prioritize it differently.

Best for: Any team that ships software, especially when ops needs to stay in sync with engineering without being in every meeting.

Watch out for: Jira can become a ticket graveyard if nobody owns backlog hygiene. Regular grooming sessions are not optional.

The biggest mistake people make when joining a new company is moving too fast toward solutions before they understand the actual problem. The first thing I do at any new company is audit — tools, processes, data, and people. Not to judge, but to understand what exists and what the gaps are.

The interview phase is just as important. You learn things in a 30-minute conversation with a customer success rep that you’ll never find in a dashboard. People closest to the work know where the friction is. The goal is to collect those signals before they get filtered through organizational hierarchy.

After the audit and interviews, I prioritize based on a simple question: what’s causing the most pain with the highest leverage? At Audicus, that was Confluence adoption. At Ottimate, it was AR. At Cardstop, it was the lack of a structured operating model. Each time, the answer came from the audit, not from assumptions I brought in from the outside.

The shipping phase matters most. Insight without execution is just observation. The credibility you build in the first 90 days comes from shipping something real — even if it’s small — and making it stick.