You Can't Automate a Process Nobody Has Written Down
Automation projects in the mid-market rarely fail at the tooling. The tools work. Workflow rules fire on schedule, integrations move records, agents call APIs and get answers back. The stall happens earlier and quieter than that, usually in a room, when somebody finally asks: what should the system do when the order is over fifty thousand dollars, the customer is thirty days past due, and the rep says it's fine because there's a signed renewal coming?
Nobody answers. Or three people answer differently, and one of them is right because she has been doing it for eleven years and has never written it down. That is the moment the project actually stops. It gets reported later as integration complexity, which is how the real cause stays invisible.
Gartner predicts that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls (Gartner press release, 25 June 2025). Those are the visible failure modes. Under at least two of them sits something plainer: nobody could state the rule the agent was supposed to follow, so the project either kept expanding until the cost stopped making sense, or shipped something nobody would trust with a real decision.
What an automation actually needs is a decision rule
In that same release, Gartner's guidance is to use AI agents when decisions are needed, automation for routine workflows, and assistants for simple retrieval. Sensible advice, and it quietly assumes something most companies cannot supply: that you already know which of your steps are decisions.
A step that is not a decision is easy. Copy the value, send the email, create the record, move the stage. Business process documentation for that kind of step is nearly free, because the step has no judgment in it. Nobody argues about what "email the signed PDF to accounting" means.
A decision step is different. It has inputs, a rule, and an outcome, and the rule is the part that has to exist in writing before any system can execute it. "Approve the discount" is not a rule. "Approve up to 15% without escalation; above 15%, route to the regional director unless the account is on the strategic list, in which case route to the VP" is a rule. The first sentence is a label for where a human used to think. The second is something a Blueprint, a workflow, or an agent can carry out and be held to.
That is the whole gap. Most mid-market business process documentation describes the sequence of steps and stops there. Sequence is the easy half. The rules inside the steps are the half that decides whether automation is possible, and they are the half that is missing.
The happy path is already documented. The exceptions are not.
Ask an operations manager to describe quote-to-cash and you will get a clean answer in about four minutes. It will be accurate. It will also describe the version of the process that runs maybe seventy percent of the time — the version that never really needed a person in the first place.
The other thirty percent is where the business actually lives. The customer who gets net-60 because of a handshake in 2019. The three SKUs that need engineering sign-off before a quote goes out. The reseller whose POs arrive as a photo of a fax. The month-end rule where anything closing in the last two days skips the usual credit check, because finance would rather chase it than lose the quarter.
None of that is written down anywhere, and all of it is load-bearing. When an automation meets one of those cases it does one of two things, both bad: it processes the exception as if it were normal, or it halts and waits for a human who now has to unpick what the system already did. The first is how a $200,000 quote goes out to a customer in collections. The second is how a team ends up doing the old job plus supervising a robot.
So the useful test is not "have we documented the process." It is: could someone who has never worked here handle the next twenty edge cases correctly using only what we wrote down? If the answer is no, an automation cannot either, because that is exactly the position it is in.
What "documented enough to automate" looks like
This is a discipline, not a document format, and it works the same whether the thing that eventually executes the process is a workflow rule, a Blueprint, an integration or an agent. Run it on one process at a time.
Pick one process and set its boundaries. Name the trigger that starts it and the condition that ends it. "Quote to signed order," not "sales." Vague boundaries are where scope quietly doubles.
Pull the last twenty real records, not a whiteboard. Take the last twenty orders, tickets or invoices that actually went through, and trace each one. The whiteboard version is the happy path. The records are the truth, and twenty is usually enough for the exceptions to start repeating.
Mark every step as either mechanical or a decision. A mechanical step has one possible output given its input. A decision has more than one. Only the decisions need rules; everything else needs a sequence.
Write the rule for each decision as a sentence with a threshold and an else. Numbers, named roles, named record states. "Approve under $10,000" is incomplete until you say what happens at $10,000 and above, and who does it. If the sentence has no else, the rule is not finished.
Hunt the exceptions by asking who overrides this and when. Go to the person who has been doing the job longest and ask what they do that is not in the procedure. Then ask what they do at month end, for the top five accounts, and when the customer is angry. Those three questions surface most of the missing thirty percent.
Assign an owner to each rule by name, not by department. Someone accountable for the rule being right and for changing it when the business changes. A rule nobody owns goes stale inside two quarters, and the automation built on it starts producing confidently wrong outcomes.
Run the document against ten cases it has never seen. Hand it to somebody outside the team with ten more real records. Every case where they have to ask a question is a hole. Fix the holes and stop.
What comes out the other end is not a binder. It is usually two or three pages per process: a bounded sequence, a short list of decisions, a rule with a threshold and an else for each one, and a name against each rule. That is the specification an implementer builds from, and it is the same specification whether the build is a workflow, a Blueprint or an agent.
Why the exceptions, not the happy path, are the deliverable
Documenting the happy path feels productive and changes nothing. Everyone already knows it, and the steps it contains were never the expensive ones. The exceptions are where the cost sits: the rework, the escalation, the invoice that goes out wrong, the deal that waits four days for an approval nobody knew was needed.
They are also where the risk sits once you automate. An automation that handles the standard case and escalates cleanly on everything else is genuinely useful on day one. One that handles the standard case and guesses at the rest is a liability that compounds silently, because nobody is checking the cases that used to go to a person. The same pattern holds one layer down, where an AI forecast is only as good as the data feeding it — foundations fail quietly, not loudly.
Documenting to the exceptions also changes what an implementation costs and how confidently anyone can price it. Most of the overrun on integrated business solutions work is discovered rule-writing: the client and the integrator finding out together, during the build, what the process actually is. We would rather find that out in discovery, which is why our discovery is structured the way it is and why we can guarantee estimates. If we estimate low, we absorb the difference. That commitment is only possible when the rules are on paper before the build starts.
It pays whether or not the AI ever gets switched on
Worth being clear about this, because "do the documentation first" usually sounds like a tax on the interesting work.
A process written to this standard is immediately useful with no automation attached. It cuts onboarding for a new hire from months of shadowing to weeks. It lets a manager settle an escalation without calling the one person who knows. It survives that person leaving, which on a mid-market operations team is not hypothetical. It makes handoffs auditable, so a dispute about who dropped something has an answer instead of a debate.
And when you do automate, the work is already done. The rule that says "above 15% goes to the regional director unless the account is strategic" is the same sentence whether a person follows it, a Blueprint enforces it, or an agent executes it. Choosing among workflow rules, blueprints, custom functions and scheduled jobs is a comparatively small decision once the rule exists — a real skill, but downstream of knowing what you want the system to do.
The order matters more than the tooling. Write the rules, exceptions included, and name an owner for each. Then pick the mechanism. Teams that go the other way round spend their budget discovering their own process at consultant rates, and a fair number cancel before they reach the part that was supposed to pay for it.
Where to start this month
Pick the process that generates the most internal questions — the one where people message each other to ask what to do. That is the process with the most undocumented rules in it, which makes it both the best candidate for this exercise and the worst candidate for automation until you have done it.
Run the seven steps on it and time-box the work to two weeks. Do not buy anything, do not open a builder, and do not let it turn into a process-improvement project: the goal is to write down what happens today, exceptions included, not to redesign it. Then look at what you have. If the rules are clean and owned, you are ready to automate and the build will be short, because the arguing is finished. If they are still contested, you have found the real problem, and it was never going to be solved by a better tool.
Comments