What is the difference between the consultant and the agency engagement?

The consultant delivers a specification and stops. The agency engagement delivers running automations. Buying the first does not commit you to the second, and the specification is written so another team could implement it.

Why would we buy advisory instead of just building?

When you have engineers but no agreement on the rules. Most stalled automation projects are stalled on precedence and ownership questions, not on code. Those are cheaper to settle on paper.

Do you take commission from tools you recommend?

No. That is deliberate, because a recommendation that pays us is not advice. It also means we sometimes recommend a setting change in software you already own instead of anything new.

What if the specification says we should not automate?

Then it says that, with the reasoning. That has happened, and it is a better outcome than a build that measures well and changes nothing.

Can our team implement the specification?

That is the intent. It is written for an implementer who was not in the room, with rule order and fallback behaviour explicit rather than assumed.

Services

AI Automation Consulting

An AI automation consultant maps where your inbound process leaks, decides which steps are safe to automate, and writes the rules before anyone builds. OperStack sells this as advisory work with named artefacts, separate from any build we might later do. Most engagements take 2 to 3 weeks for a full specification.

Entry point	Assessment · Free Free audit first, then a fixed advisory scope if a build is not what you need.
Typical timeline	2 to 3 weeks for a full specification Depends on how much of your data is already clean.
Updated	September 8, 2026 Reviewed by Maksim Shchegolev

Advisory is separable on purpose

We sell the specification separately from the build because bundling them corrupts the advice. A consultant who only gets paid if there is a build will find a build.

You can take the specification to your own engineers, to another agency, or nowhere. That is the point of writing it for an implementer who was not in the room.

Most projects stall on precedence, not on code

The recurring pattern: an engineering team is ready, and the project sits for two months because nobody has decided what happens when a lead matches two rules, or who owns a record when the assigned rep leaves.

Those are one-page decisions that need a person with authority, not a sprint. Getting them written down is usually the highest-value fortnight in the whole programme. The shape of those rules is in the lead routing playbook.

Every success metric gets a failure metric

Response time looks great until you notice it only counts records that got a response. Add “records with no first response” beside it and the picture changes.

Specifying that pair for each metric is boring, quick, and prevents a year of confident reporting on a number that was measuring the survivors. Who owns which artefact, and where lead ops ends and RevOps begins, is covered in lead ops versus RevOps.

When a consultant is the wrong purchase

If you already know what to build and simply lack hands, buy the build. If your volume is low enough that one person can watch every lead, buy neither and revisit in six months.

And if the real constraint is that nobody will own the rules afterwards, no specification fixes that. We will say so, and it will not be in a proposal.

What the engagement covers

Process map with the current failure rate at each handoff, measured not estimated
Automation boundary: which steps have a testable pass condition and which do not
Rule specification: precedence, ownership, fallbacks, written to be implemented by anyone
Metric definitions, including the failure metric that sits next to each success metric
Build or buy recommendation per module, with the reasoning stated
A sequencing plan, because doing three modules at once removes attribution

What you keep

The specification, in your vocabulary, implementable by your team or a third party
Metric definitions with named owners, so a number cannot quietly change meaning
A written recommendation that includes what not to do

What this does not cover

Implementation. That is a separate engagement, and you are free to take the spec elsewhere
Ongoing management. Advisory ends when the specification is delivered and reviewed
Tool procurement or reseller commissions. We take none, which is why the advice is separable

If one of these is the actual problem, say so on the audit call and we will point you somewhere better rather than sell you the wrong module.

Start with the written assessment

Free and in writing: send the site and how inbound works today, get the gap we see, the module that fixes it and a fixed price within two working days. No call at this stage.

Send the form → Pricing

Frequently asked questions

What is the difference between the consultant and the agency engagement?: The consultant delivers a specification and stops. The agency engagement delivers running automations. Buying the first does not commit you to the second, and the specification is written so another team could implement it.
Why would we buy advisory instead of just building?: When you have engineers but no agreement on the rules. Most stalled automation projects are stalled on precedence and ownership questions, not on code. Those are cheaper to settle on paper.
Do you take commission from tools you recommend?: No. That is deliberate, because a recommendation that pays us is not advice. It also means we sometimes recommend a setting change in software you already own instead of anything new.
What if the specification says we should not automate?: Then it says that, with the reasoning. That has happened, and it is a better outcome than a build that measures well and changes nothing.
Can our team implement the specification?: That is the intent. It is written for an implementer who was not in the room, with rule order and fallback behaviour explicit rather than assumed.