Business process automation,
without a consultant.
The honest version, including the part where the right answer is often to delete the process rather than automate it, and how to tell whether you need help at all.
Start with the definition, not the tool
Take one process. Write down what it is supposed to produce, and for whom. Then write down what actually happens, step by step, including the parts that only exist because of who is on holiday.
The gap between those two lists is the project. Not the tool, not the automation, the gap. Everything after that is execution.
Businesses that start with the tool get the tool's opinion about what to fix, and tools have a strong opinion, because they were built for a certain shape of problem.
- Does this process need to exist? A surprising share of briefs ask us to speed up something that only happens because of a decision nobody revisits. Deleting it is cheaper than automating it.
- Who owns the output? If nobody owns it, nobody will notice when the automation produces a wrong one.
- What does it cost now? In hours and in errors. If that is not a number, the project has no way to succeed.
Should this process exist at all?
Roughly a third of the automation briefs this practice sees are asking to make something faster that should be removed. That conversation is free, and it is the one worth having first.
The order that does not waste money
One: agree the definition. What is a completed order, what is revenue, what counts as done. Two departments quietly meaning different things is the most common root cause of a reporting problem, and no amount of automation fixes it.
Two: remove what should not be there. Approvals that always pass, checks nobody reads, reports that get filed. Delete before you build.
Three: fix the data. An automated process running on a broken source produces wrong answers more confidently and more often.
Four: automate the repetition. Now, and only now, the clever part. Collecting, joining, calculating, assembling.
Five: put a check on it. An automated process needs something that notices when it produces an impossible number. This is the step that gets skipped and it is the one that saves you.
Skipping to step four is the most common way an automation project fails. It is also the most tempting, because it is the visible one.
- 01Agree the definition
- 02Remove what should not be there
- 03Fix the data
- 04Automate the repetition
- 05Put a check on it
Step four is the only one anybody can see, which is why projects start there. It is also the step that fails when one to three are skipped: the automation is correct and the answer is still wrong.
Where AI actually helps
AI is genuinely good at two steps in this sequence. Reading unstructured input: a PDF invoice, a scanned form, an email that says what somebody wants. And drafting: a first pass somebody then edits.
It is poor as a decision-maker and worse as an unattended one. The pattern that works is AI doing the reading, a fixed rule doing the deciding, and a person able to see both when the answer matters.
Anything that says otherwise is describing a demo.
- Probably not for the first process, if it lives in one department and one person understands it. That person can usually fix it given a week and permission.
- Probably yes when the process crosses departments, when the definition is genuinely disputed, or when it has already been attempted and failed.
- Definitely yes when two systems disagree about a number that gets reported externally. That is a reconciliation problem before it is an automation one.
Questions people actually ask
With the definition, not the tool. Pick one process, write down what it is supposed to produce, then write down what actually happens. The gap between those two lists is the project. Starting with a tool means the tool decides what you fix.
Often not for the first one. The first process is usually fixable by the person who runs it, given a week and permission to change it. A consultant earns their place when the process crosses departments, when the definition is genuinely disputed, or when it has already failed once.
Automating a process that should not exist. Roughly a third of the automation briefs we see are asking to speed up something that only happens because of an earlier decision nobody revisits. Deleting it is cheaper than automating it.
Agree the measure before you build. Time to produce the output, number of corrections afterwards, or how often somebody has to ask a person. If none of those improve, the project did not work, whatever the tool cost.
AI is good at two steps: reading unstructured input, and drafting. It is poor as a decision-maker and worse as an unattended one. The useful pattern is AI doing the reading and a fixed rule doing the deciding, with a person able to see both.
Two to six weeks for a single process, including the part where somebody has to agree what the output should be. That agreement is usually the long pole, not the build.
If one process is already failing
The audit exists for exactly this: one process, a week, and a written answer about what is broken, what it costs, and whether it is worth fixing. Sometimes the answer is that it is not, and that is a useful answer.
- The automation audit, which is where most of this starts.
- Reporting and reconciliation, for the two-systems-disagreeing case.
- Excel automation, for the work that is smaller than a process.
Tell us what is not working.
Describe the problem in a few lines. You get a plain answer about whether it is worth fixing and what it would take, before any money changes hands.