Automating a process nobody has documented

Nobody documents a process because the process is not what anyone thinks

Undocumented is the normal state, not a sign of a badly run company. Processes accrete. Somebody adds a check after a bad month. A customer negotiates an exception that becomes a standing rule. A system gets replaced and a workaround survives it by four years. The result is a set of behaviors that works, is genuinely sophisticated, and that no single person can fully describe — including the people who execute it every day.

This is why asking for the process document produces one of two bad outcomes. Either there is no document, and the project stalls waiting for someone to write one, which they will not do because it is nobody's job and it is genuinely hard. Or a document exists, it is confidently handed over, and it describes the intended process rather than the executed one. The second is worse, because it looks like an answer.

The useful reframe is that the specification is something you build from evidence rather than something you request. It takes one to three weeks for most processes, it costs a fraction of the automation itself, and it is the single artifact that determines whether the automation works. It also survives the project: a company that has a real specification for its own order intake or claims triage has something valuable regardless of what software gets written.

Three sources of truth, in order of reliability

The order matters. Most discovery efforts run it backwards, starting with interviews and ending with a document that describes what people believe they do. Run it in this order and the picture is different and better.

Artifacts first. The work leaves traces. Completed forms and their attachments. The email folder where requests arrive, including the ones that arrive in the wrong format. The spreadsheet, with its formulas, its manually coloured rows and its comments, which is usually the most honest specification in the building. System logs and status transitions with timestamps. The naming convention on the shared drive, which encodes a taxonomy nobody wrote down. Two hundred completed items with their inputs and outputs tell you more about the actual decision rule than a week of meetings, and they cannot misremember.

Observation second. Watch somebody do the work, five to ten times, without interrupting. Record the screen if the environment permits and the person consents. What you are looking for is the gap between what they say and what they do: the tab they check every time and never mention, the pause before a certain kind of case, the second system they open for one field. People are unreliable narrators of their own expertise, not from any wish to mislead but because skilled work becomes invisible to the person doing it.

Interviews last, and to explain rather than to elicit. Once you have the artifacts and the observations, the interview becomes powerful, because you can ask about specifics. “On these four you did something different — what did you see?” is a question an expert can answer precisely. “Walk me through your process” is a question that produces the trunk and omits everything that matters.

The exception is the process

Here is the pattern that explains most failed automation. A process has a trunk that covers a large share of volume — commonly somewhere between 60 and 85 percent — and a long tail of variants. People describe the trunk, because it is the shape of the work in their minds. People spend their time in the tail, because the trunk takes two minutes and a tail case takes forty.

An automation built from the description handles the trunk beautifully. It gets deployed. The team keeps doing all the tail work by hand, plus a new step where they check what the system did. Total human effort barely moves, the system gets a reputation for not helping, and it is quietly abandoned within two quarters.

The measurement is simple and worth insisting on. Take a real week of items. Classify each as trunk or variant, and record the time each took. You now have two numbers: share of volume and share of effort. Those two numbers decide the entire economics of the project, they take a day or two to collect, and almost nobody collects them before scoping.

When the tail holds the hours, the design changes completely. You are no longer building a system that does the work; you are building one that triages, gathers context, prepares a recommendation, and hands the operator a case that is already half done. That is a smaller build with a larger payoff, and it does not require the system to be right about the hard cases — only useful.

Write a decision table, then have it corrected

The output of discovery should not be prose. Prose hides ambiguity comfortably; a table cannot. Build a decision table: the conditions that can hold, and the action taken for each combination. Where the evidence is thin, write the cell as unknown rather than guessing, because an explicit unknown is a question somebody can answer and a plausible guess is a defect that ships.

Then run the strongest test available, and it takes an afternoon. Take thirty real cases the operators have already handled, including six or eight difficult ones. Apply the decision table by hand. Compare against what actually happened. Sit with the operator and go through every disagreement.

Two things come out of that session. The first is a corrected table, because a person who would never write a specification will happily tell you that your table is wrong about case seventeen — correcting is far easier than composing, and this is the whole trick. The second is a measured agreement rate, which is the honest ceiling on what any automation can achieve. If your table matches the operators on 90 percent of cases and the operators agree with each other on 88 percent, you have learned something important about how much of this work is genuinely rule-governed.

Automate the trunk, route the tail, instrument everything

The design that works is not a system that handles every case. It is a system that handles the cases it can, recognises the ones it cannot, and puts those in front of a person with the context already assembled.

Three properties make the difference. The system knows when it is unsure, and routing an uncertain case to a human is a success rather than a failure. The exception queue is instrumented, so every routed case records why it was routed — and after six weeks that queue is the most accurate description of the process anybody has ever had, ranked by frequency, which tells you exactly what to build next. The rules that change live as data, in a table an operator can edit, not in code that requires a release. Customer-specific exceptions, thresholds, and product rules all belong there, because they will change and the change will be urgent.

Sequence it so the first release is embarrassingly small. One intake channel, one customer segment, the trunk only, with everything else routed. Deploy it beside the existing process rather than in place of it, and let it run in parallel for two weeks with a person checking its output. That parallel period costs a little extra effort and buys the two things that decide adoption: evidence that the system agrees with people, and a list of every place it does not.

The part everyone avoids saying out loud

The person who holds the process in their head is frequently the person whose job the automation touches. Pretending otherwise does not work; they have already worked it out, and they were doing so during the first meeting.

An unaddressed version of this conversation produces the most expensive failure mode in this kind of project. Nobody refuses to help. They are simply slightly less available, mention slightly fewer exceptions, and remember the difficult cases slightly less clearly. Six weeks of that and you have a specification with quiet holes in it, and no way to tell which parts are missing.

The honest handling is straightforward and it is the sponsor's job, not the vendor's. Say plainly what the intent is — volume growth, removing a single point of failure, freeing time for work that is currently not getting done, or, if it really is headcount, say that too. People handle a clear answer far better than an obvious evasion. Where the intent is to remove the drudgery and keep the person for the judgment, that is a genuinely good message and it happens to be true in most of the projects we see, because the judgment is the part that resists automation.

One further thing that costs nothing and changes the mood: put the operators' names on the decision table as its authors. It is accurate — they are the source — and it converts the exercise from something happening to them into something they own.

Cost, duration, and what to expect

Discovery for a single well-bounded process is typically one to three weeks and $15,000 to $45,000 of outside work, plus perhaps ten to twenty hours of operator time spread across the period. That produces the decision table, the volume and effort split, the intake inventory and the exception catalogue. It is worth buying on its own, and a firm should be willing to sell it as a standalone piece with no obligation to continue.

The build for a first useful release — one channel, the trunk, a working exception queue, an editable rules table and instrumentation — is commonly six to twelve weeks and $60,000 to $200,000 depending on how many systems it has to talk to. Integration with existing systems, not the logic, is usually the largest cost driver, and an old system without a decent interface can double the number.

The realistic outcome to plan for in year one is that a majority of volume flows through unattended and the exception queue absorbs the rest with better context than people had before. Systems that handle everything on day one are systems that were describing a simpler process than the one that existed.

The mistakes we see most

• Waiting for someone to write the process document that has not been written in nine years
• Building from interviews, which reliably produce the trunk and omit the tail
• Not measuring the volume and effort split before scoping
• Treating the maintained spreadsheet as a workaround rather than as the specification it is
• Hard-coding customer-specific exceptions that change every quarter
• No exception queue, so the system either guesses or stops, and both are unacceptable
• Failing to instrument why a case was routed, discarding the best data the project will ever generate
• Leaving the job question unanswered, and getting a quietly incomplete specification in return

When not to automate it

Four situations where the arithmetic or the logic does not work, and the honest recommendation is to leave it alone.

The volume is too low. Something that happens forty times a year and takes an hour is forty hours. A build is hundreds of hours. Write the checklist, put the reference data somewhere shared, and move on. This is the most common case where a firm should decline the work and frequently does not.

The process is about to change. A system migration, a regulatory change, a pricing overhaul, an acquisition being integrated. Automating a process that will be replaced in eight months means paying twice and getting a system that is wrong on arrival. Wait, and use the interval to do the discovery, which stays useful.

The mess is upstream. If the pain is caused by what arrives — incomplete requests, three intake channels, a form that lets people skip the field everyone needs — then fixing intake removes most of the work outright. Automating a well-run repair shop for bad inputs is a worse outcome than not needing the repairs.

The process exists to place responsibility. Some steps are not information processing. They exist so a named person looks at something and is accountable for having looked. Automating those removes the accountability and keeps the delay, which is the worst of both. The right move is to make the human step faster and better informed, not to remove it.

Before you scope an automation

• Two hundred completed items have been read, inputs and outputs
• Someone has been observed doing the work at least five times
• The volume split and the effort split are both measured
• Every intake channel is inventoried, including the informal ones
• The maintained spreadsheets have been found and their formulas read
• A decision table exists, with unknowns marked as unknown
• The table has been tested against thirty real cases with an operator present
• The job question has been answered honestly by the sponsor
• The first release is small, parallel to the existing process, and instrumented

Bottom line

A missing process document is the normal condition of a working business, not a failure of governance, and it is recoverable in weeks from evidence that already exists. Read the completed work, watch the work being done, and save the interviews for explaining what you saw. Measure how volume and effort divide between the common cases and the awkward ones, because that ratio decides whether the project is worth doing at all. Write a decision table and let the people who do the job correct it, since correcting is easy and composing is not. Then build something small that handles the trunk, routes everything else with its reasons recorded, and gets better because the exception queue tells you what to build next. And if the volume is small, or the process is about to change, or the real problem is upstream — say so and keep the money.

Frequently asked questions