How we find the money.

A process is a system, not a list of tasks

A business can lose a six figure sum every year to one process and nobody notices, because nobody experiences the whole of it. Each person sees their own few minutes. The cost is in the space between them.

So we do not audit tasks. We map the process as a system and look at four things: what moves through it, where it waits, where the same fact gets written down twice, and what happens when a step fails quietly. That is where the money is, and none of it appears on anyone’s job description.

Everything below produces a number and a picture, taken from your process and your own examples. If we cannot get a real end to end example, we label the figure an estimate or we leave the analysis out. A confident number with nothing behind it is worse than no number.

1. Touch time against elapsed time

How long does this take, and how much of that is anyone actually doing anything?

We add up the minutes across every step. That is touch time. Then we measure trigger to finished output on real examples, including every wait in between. That is elapsed time.

You experience elapsed time. You budget for touch time. A process that takes six days, of which forty minutes is work, is not slow work. It is a process made of waiting, and waiting is usually cheaper to remove than work is.

Which of the two dominates decides what we recommend. If the work is the cost, we automate steps. If the waiting is the cost, we fix the handoffs, the queues and the approvals first, and a good part of that needs no build at all.

2. What can be automated, before what should be

Most audits skip this and go straight to what is worth doing, which assumes an answer to a question nobody asked.

Every step gets scored on three things: how often it happens, how similar each instance is to the last, and how clearly the rule behind it can be written down. Then we read the shape rather than the total.

• Consistent, and the rule is writable. Automatable. Whether it is worth building is a separate question, answered later.
• The rule is writable, but every instance looks different. Automatable with a model rather than fixed logic. That costs more to build and needs a human review step, and we put both in the scope rather than discovering them later.
• The rule cannot be written down at all. Leave it alone, however often it happens.

That last verdict is the one clients least expect to hear from us. Judgment nobody can articulate is not an automation candidate at any volume, and treating it as one is how AI projects quietly fail in month three.

3. What breaks, and whether you would find out

Every failure in the process gets three scores: how bad it is, how often it happens, and how likely you are to notice.

The third one is the whole point. Severity and frequency are what everybody already worries about. Detection is what nobody tracks, and a silent failure is the one that compounds, because it runs for months before anyone finds it.

Every silent failure we find has to map to something in the build: an alert, a check, or a step that reconciles two records against each other. That is where the hourly health checks on our builds come from. They are not a feature we thought sounded good. They are the answer to a specific finding, and you can read what they do and do not prove.

4. When it pays for itself

The build cost against the value recovered each month, with the crossover marked.

This is the number that has to survive a conversation you have without us in the room, so these are the rules we hold ourselves to:

• We plot the conservative end of the range, never the optimistic one. A payback chart built on the best case is the fastest way to lose your trust in month four.
• Your monthly software cost comes out of the running total. It does not get quietly left off.
• Recovered hours are only money if they go to work that earns. We say that out loud instead of assuming it.
• If payback runs long, we say so and give you a different reason to do the work, or tell you not to.

5. Where the same fact lives twice

Rows are the facts: a client name, a matter number, a fee, a date. Columns are your systems.

We mark where each fact lives. Any row with two marks means somebody is retyping it, or the two copies are drifting apart and nobody has noticed yet.

Double entry is invisible from inside a business, because each person only ever sees their half of it. Laid out as a grid it is obvious in a second, and it usually explains an error rate that had been accepted as normal for years. It also tends to identify the integration that actually matters, which is often not the one you called us about.

We only run this when three or more systems are involved. With two, a sentence does the same job.

Three at most, and each one has to change the answer

We do not run all five on every engagement. Each analysis has to earn its place by changing a recommendation, and if the picture would look the same whichever way the answer came out, we skip it.

An audit padded with charts is a tell. So is a report where every finding points at something to buy.

What this will not tell you

The limits are part of the method, so here they are.

• Whether your team will use it. We can measure a process. We cannot measure willingness, and a system nobody adopts is a loss whatever the analysis said. If a step depends on people who have no reason to cooperate, we design around them instead of assuming they will change.
• What your judgment is worth. The parts of the work that make you good at it are usually the parts we recommend leaving alone.
• Anything, if the inputs are guesses. Without a real example start to finish, every figure is an estimate, and it gets labelled as one in the report.
• That you need us. Sometimes the fix is a notification, a reordered step, or one extra field on a form. We tell you, and we do not invoice for a build you do not need.