There is a number nobody has ever told you about your own business.
How many times a day does the work stop and wait for a person?
Not how many staff you have. Not how many hours they work. How many times something that was already in motion comes to a halt because it needs a human to pick it up and carry it to the next place.
Nobody counts it, so nobody manages it. And it is the single most useful figure you can have before you spend money on software, because it tells you whether you have a software problem at all.
Why this number is worth more than a quote
When you ask three developers what to build, you get three different answers and no way to judge them. That is not because any of them are dishonest. It is because none of them know where your work actually stops — and neither does the person writing the brief, in most cases, because the stops are invisible from the inside.
The count changes the conversation. Instead of “we need a system”, you arrive with “the work stops eleven times between an inquiry landing and an invoice going out, and four of those eleven are one person re-typing something that already exists in writing.”
That is a specification. It is also a budget test: you can price eleven stops against what it costs to keep paying for them.
What counts as a stop
Be strict about this or the number comes out meaningless. A stop is a point where work that is already in progress cannot continue until a specific person does something.
- A re-type. Information exists in one place in writing and a person puts it into another place by hand.
- A check. Somebody confirms the previous step actually happened — opening a system to look, rather than being told.
- A carry. An export, a download, an attachment, a copy-paste, a forwarded email whose only job is to move something along.
- A chase. Somebody remembers that a thing has gone quiet and pokes it.
- A decision that is not really a decision. A person approves something where the answer is the same every time and no judgement is being applied.
That last one deserves the most attention, and it is the one people miss. A decision nobody has ever said no to is not a decision. It is a delay wearing a tie.
What does not count: a genuine judgement call, where a human weighs something and could reasonably go either way. Those are the stops worth keeping — and an engine keeps them deliberately.
Run it in one week
This takes a few hours spread over five days, and you can do all of it without hiring anyone.
- Choose one flow. Inquiry to answer. Quote to decision. Job to invoice. Document to books. New customer to running. One only — doing four at once produces a mess you will abandon by Wednesday.
- Draw it as a line, left to right, from the moment it arrives to the moment it is finished. Boxes, not detail.
- Walk it with the people who actually do it, not with the person who designed it. Those are frequently different processes, and the real one is the one being walked.
- Mark every stop using the five types above. Put a name and a rough wait time on each.
- Mark which stops are real judgement and which are not. Two colours. This split is the whole point of the exercise.
- Add it up — stops per item, items per day, minutes per stop. Your figures, your arithmetic.
Reading your own map honestly
Three answers come out of this, and one of them saves you money.
Mostly real judgement stops, few carries. Your work already moves. The remaining stops are you and your team doing the part of the job that requires a brain. Do not buy software for this. Genuinely — you would be paying to remove the wrong thing.
A lot of carries and checks, clustered in one place. That cluster is a single job that should be one connected path, and it is the highest-value thing you could fix. It is also usually much smaller than the “we need a whole new system” conversation that gets triggered by the same frustration.
Stops spread evenly everywhere. This one is worth sitting with. Even spread usually means the systems were bought one at a time to solve one problem each, and nothing was ever asked to connect them. That is the ordinary history of almost every business over about eight years, and it is nobody’s mistake.
The bit I got wrong myself
I built a hosting control panel with an AI agent doing the typing while anime played on the second screen. It was fast and it was working, right up until it wasn’t. Hours went to bugs that should never have existed. The agent kept reporting success. The code kept not working.
I tried better prompts. That was not it. Intelligence bolted onto a bad structure is not intelligence — it is faster chaos.
The reason that story belongs in a guide about counting stops: I skipped the mapping step, because mapping is boring and building is fun. Everything expensive that happened next came from that one skip. If you do the count and then ignore it in favour of buying something shiny, you get my version of the week rather than the good one.
What good looks like when the stops are gone
Not a claim, a description of the target so you can tell whether an engine you are being sold would actually get there.
- Nobody re-types anything. Not once, anywhere on the line.
- The report is already written when you go looking for it.
- The thing that broke tells you before your customer does.
- The odd one gets caught, flagged, and put in front of a human — with a draft reply attached.
- The one stop that remains is the decision you actually wanted to make, and it arrives with the answer already prepared.
What to do next
Pick one flow and map it this week. The number at the end belongs to you whether you ever hire anyone, and it is the only honest starting point for deciding whether software would help.
If the count comes back high, the twelve-logins piece explains why it got that way, and the eight questions are what to ask before you pay anyone to fix it.
If you want the whole picture instead of one workflow: tell us what’s still manual. You get a map of every point where your business stops and waits for a person, what that costs you in hours, and which of those an engine would take over first. Free, yours to keep, and useful even if you never hire us — including on the days the honest answer is that you should not build anything yet.
Common questions
How accurate do the time estimates need to be?
Rough is fine and precise is a trap. You are looking for an order of magnitude — is this two hours a week or two days a week — and people burn the whole exercise trying to time things to the minute. If a stop is somewhere between three and ten minutes, write five and move on. The count of stops matters more than the minutes attached to them.
Should I do this with my team in the room or on my own?
With the people who do the work, and frame it as mapping the process rather than reviewing them. The difference matters: a map made alone at a desk describes the process you think you have. Every business has a real version that differs, usually because someone invented a sensible workaround years ago and never mentioned it.
What if the count shows we should not build anything?
Then you have saved yourself the price of a build, which makes it the most profitable week you will spend this quarter. Some maps genuinely come back recommending you configure what you already pay for, or delete a process rather than automate it. Automating a step that should not exist is the most expensive way to keep it.
Can I hand this map to a developer?
Yes, and it is the single most useful thing you can hand one. It changes the quote from a guess about scope into a response to a described path, and it lets you compare two quotes against the same document. Keep the map yourself regardless of who you hire — it is a record of how your business runs, and that is worth having whoever builds anything.