What Does An Operations Consultant Do? Scope And Cost

What the role actually does

An operations consultant is bought to answer a question: what's wrong with how this business runs, and what should change. Unlike a hire, they have no seat. Unlike a coach, they work on the company rather than the person. Unlike an implementation partner, their output stops at the recommendation.

The engagement usually has a recognizable shape. Discovery first: interviews with you and your team, a look at your tools, a review of whatever numbers exist. Then analysis — mapping how work actually flows versus how you think it flows, which is nearly always the most valuable part, because founders genuinely cannot see their own operation from inside it. Then a set of findings: here's where work stalls, here's what's undefined, here's the bottleneck and it's probably you. Then recommendations, prioritized, with a rough sequence.

The deliverables are documents and conversations. A process map. An audit. A roadmap. A workshop where the findings get presented and argued with. Sometimes an implementation plan, which is a document about implementation rather than implementation. Engagement lengths vary from a couple of weeks to a couple of quarters, and pricing varies so widely — day rates, project fees, monthly retainers — that any range we published would be noise.

The honest summary of the product: pattern recognition. You're renting someone who has seen your problem in forty other businesses and can compress that into a call you can act on. When the thing blocking you is not knowing what to do, that's worth a great deal.

What a consultant is genuinely better at than anyone else

Independence, and it's structural rather than a matter of character. A consultant has no stake in the answer being a build, a hire, or a tool. That means they can tell you the honest thing — that your problem is your pricing, or your co-founder, or that you should do nothing for six months — because none of those conclusions cost them their next invoice. Anyone who sells the fix cannot offer you that, no matter how honest they try to be, and you should discount our answer here accordingly. This page is written by an implementation partner.

Range. A good consultant looks at your whole business and goes wherever the constraint is. Specialists are shaped by what they sell: we look at an operation and see operations. If you don't yet know what's wrong, someone whose only product is thinking is a legitimately safer first purchase.

Speed to a decision. Sometimes you need an answer this month, not a build this quarter. Twenty years of pattern recognition compressed into three weeks is a genuinely efficient purchase, and it's a fraction of what construction costs.

And cost, on the day. Advice is cheaper than building. Always. If advice is sufficient, buying construction is a waste of your money and anyone who won't say that out loud is selling.

When you should genuinely hire one

Hire the consultant when you have execution capacity. This is the whole case and it's a strong one. If you have a team with real slack, a technical person who can build, or an ops lead who's capable and under-directed, then direction is your entire shortage. Pay for the thinking, let your own people build it, own it forever, spend a fraction of what an implementation engagement costs. That's not a compromise. That's the optimal purchase and we'd make it too.

Hire the consultant when the question isn't operational. Pricing, positioning, market, org design, whether to sell the company. Those are strategy problems. Anyone whose product is construction, asked to weigh in on them, will produce an opinion, and you should be suspicious of it.

Hire the consultant when you need someone with no incentive. Before a big irreversible decision, an independent read is worth exactly what it costs precisely because they don't sell the fix.

Hire the consultant when you're not ready to build. If the business is about to change shape — mid-pivot, testing a new model, uncertain what next year looks like — a build is premature and would be infrastructure for a business that won't exist. Get the thinking now. Build when the shape holds still.

And hire the consultant when you can't see your own operation. That's the most common and most legitimate reason of all. From inside your week, you cannot tell which of your problems is architecture and which is arithmetic. Someone who does this for a living can, in three weeks, and being told the truth is cheap relative to being wrong for a year.

Where consulting breaks — and where implementation does

Consulting breaks on the capacity assumption. The model presumes a business that can act, and most founder-led companies cannot — not from laziness, but because every hour is already committed and the person who'd have to build the recommendation is the same person who is the bottleneck the recommendation is about. So the document lands on a business with zero available hours and becomes an artifact.

That's the graveyard: a Drive folder with three strategic documents in it from three different firms, each of which was right. The founder concludes consultants are overpriced. They weren't. They were sold into a business with no ability to execute, and nobody said so.

The second consulting failure is subtler: the recommendation is written at a level of abstraction that can't be built from. 'Streamline your onboarding' is true and unbuildable. The person who has to turn it into an actual workflow — which fields, which trigger, which system owns what, what happens when the client doesn't reply — has to redo the thinking at a level the consultant never went to, which is where the real difficulty always was.

Now the failure on our side, because a page that only names theirs isn't worth reading. Implementation partners fail by building the wrong thing beautifully. We're incentivized toward construction, and a firm that builds will find a build. If your actual constraint is a decision you're avoiding, we will happily construct an elegant system around the avoided decision, and it will not help you, and it'll take six months and five figures to find out. The only defense is a diagnostic that's genuinely allowed to conclude 'don't build.'

How to tell which one you need

Look at the last strategic document someone handed you — a report, an audit, a plan. Did any of it get built? If yes, a consultant is a fine purchase and you should make it again. You have execution capacity and you were only ever short on direction. If it's still in Drive, unread since page four, then buying a second document is not a plan, and the variable that killed the first one is still sitting there.

Then check the shape of the deliverable before you sign, whichever way you go. Ask what exists on the last day. 'A roadmap' is consulting. 'A working pipeline in your CRM, a live dashboard, and documented ownership' is implementation. Firms blur this on purpose, and some of them say implementation and mean a slide deck with a Gantt chart in it. Ask the question in those words and watch what happens.

And ask whoever you're hiring the diagnostic question: under what circumstances would you tell me not to hire you? Anyone who can't answer concretely is selling. Ours: if your operation is basically sound and your constraint is a decision you're avoiding, or a person you won't confront, we say so and you don't buy a build.

Ops+AI is an implementation partner and says so on the About page — we don't stop at recommendations. Which makes us the wrong purchase for a founder who has capable people sitting idle and just needs to be told what to point them at. Buy the consultant, and buy a good one. Where we fit is the other case: the founder who already knows roughly what's wrong and has precisely zero hours in which to fix it. The OPERATE Report ($1,997) is diagnostic and it's allowed to say don't build; Build Days ($5K/day) and the retainer ($5,000+/mo, three-month minimum) are the construction. Doing more doesn't create growth — designing better does. But a design nobody builds is just a more articulate version of the problem you already had.