The average first reply takes 42 hours because the work is queued

Operations automation removes the steps that built the queue: the record that had to be typed into a second system, the assignment that waited for a meeting, the report that consumed a morning, the reminder that depended on somebody remembering. Each step removed returns time to the part of the work that genuinely needs a person, and the effect is visible in a number that existed before the build started.

Nothing gets rebuilt. The systems you already run are connected, the manual steps between them are replaced one at a time in priority order, and every one ships with a written runbook and a recorded walkthrough, in accounts that are in your name. If you stop working with me, nothing has to be rebuilt to carry on.

The repetitive internal steps between an event and its outcome — data entry, assignment, chasing, reminding, reporting — are moved into systems that run whether or not anyone is at a desk, with a person left on every step that contains a judgement.

A 42-hour average first response is usually read as a service failure, and it is almost never one. It is a queueing outcome. Inbound arrives continuously, capacity is finite and shared with delivery, and intake is the only work in the building with no external deadline attached. Given those three conditions, the queue is arithmetic — and no amount of asking people to be more responsive changes arithmetic.

This is why operations work sits underneath the other four systems rather than beside them. Response, qualification, follow-up and marketing all assume that the business can act on what they produce. If a booking still has to be typed into two systems by hand, if an assignment waits for a Monday meeting, if the report that shows whether any of it worked takes half a day to build, then every improvement upstream lands in the same queue and produces the same delay.

The order of work matters more here than in any other part of the system, and it runs against instinct. The measurement ships first — before the first automation — because a business that cannot see the number will not be able to tell an improvement from a good month, and will cancel the whole programme during a bad one. Double entry is removed next, because it is the most common failure and the cheapest to fix, and because silently corrupted data undermines everything built on top of it. Only then does anything genuinely clever get built.

What is deliberately not automated is any step that contains a judgement. The tools available now are extremely good at moving a fact from one place to another, extracting a field from a message, drafting from a template and noticing that something has not happened yet. They are not good at deciding whether an exception is worth making, and a system that quietly makes those decisions produces errors nobody catches until a customer does. Every automation I build has a person on the judgement and a machine on everything around it.

The last piece is documentation, and it is a commitment rather than a deliverable. Every account is created in your name. Every automation is recorded and written up as it goes live. Configuration is exportable. This is not generosity — it is the only honest way for one operator to build systems a business will depend on, because the alternative is a business whose operations only work while I am reachable, and that is a risk I would refuse to accept if I were on the other side of it.