The question almost everyone asks first
Owners usually open with a version of: what in my company can be automated? It is the wrong question, because the honest answer is almost everything, and that answer helps nobody.
The useful question is narrower. Which piece of repeated work, if it ran without a person, would move a number you already look at every month? If you cannot name the number, the automation is decoration.
We ask that question in every audit before anyone opens a tool. It kills about half the ideas in the room, which is the point.
Four numbers decide it
Every candidate process gets scored on four things. You can do this on paper in an afternoon.
- Frequency. How many times a week does this happen? Under five, park it. The maths rarely works.
- Human minutes. How long does one pass take, door to door, including the interruption it causes?
- Cost of getting it wrong. A mistyped invoice costs an apology. A missed lead costs the deal.
- How much judgement it needs. If a competent new hire could follow written rules, a machine can follow them too.
The best first system scores high on the first three and low on the fourth. High frequency, real minutes, painful errors, thin judgement. That combination is where software wins outright.
If you cannot name the number a system is supposed to move, you are not buying a system. You are buying a demo.
A worked example, with the arithmetic in the open
Take a 40 person engineering services firm. Quotes are the bottleneck. A request arrives by email, someone reads it, then someone digs out three past jobs that looked similar. Finally a price gets built in a spreadsheet and a director approves it.
Door to door it takes four working days. The work inside those four days is about 90 minutes.
Eighteen quotes a week at 90 minutes is 27 hours, roughly two thirds of a full time role. At a loaded cost of $34 an hour that is about $47,000 a year, spent assembling documents.
Now the part owners underrate. The four day wait is not idle time, it is competitive time. This firm wins 28 percent of quotes. Its two fastest competitors answer in a day.
What the fix actually was
No AI was needed for most of it. A form replaced the inbound email, so the missing information stopped triggering a second round of questions. Past jobs got tagged once, then matched automatically on scope and size.
A model wrote the first draft of the scope paragraph, because that is genuinely language work. The director still approves every quote from their phone.
Result after six weeks: 90 minutes became 20, and four days became six hours. The win rate moved to 34 percent inside a quarter. On 900 quotes a year at an average value of $9,400, six points of win rate is not a rounding error.
What we tell people to leave alone
This is the half of the advice that gets skipped, so here it is in a list.
- Work that happens five times a year. Annual reporting feels painful because it is rare, not because it is expensive. Write it down instead.
- Rules that change every month. If the policy is still moving, a system just freezes this month version of the confusion.
- Anything nobody has written down. If two people do it two ways, you have a process problem. Automating it picks a winner by accident.
- Reports nobody opens. We have found dashboards that ran for two years with nine total views. Deleting one is cheaper than rebuilding it.
The test that settles most arguments
Turn the output off for two weeks and see who complains. Nobody complains? You just found the thing to delete instead of build. It sounds glib, and it has saved clients more money than most of what we ship.
Sequencing matters more than picking
Smaller companies should start where money enters, not where the noise is loudest. Back office pain is louder, because it repeats every month in front of everybody. Sales pain is quieter, because a lead that never replies makes no sound at all.
A first system that produces revenue buys you internal permission for the next four. One that saves the finance manager three hours will be praised, then quietly ignored by everyone else.
There is a practical reason too. Revenue systems fail loudly and fast, so you learn in week two rather than month five.
How long the first one should take
Four to five weeks from first conversation to something live is a normal timeline for us, though small ones ship in one. What should worry you is a plan with nothing in production for six months.
Long builds are not more thorough. They just move the moment of truth further from the day anyone can act on it.
The payback test
Once you have a candidate, run one last piece of arithmetic. Annual hours saved times loaded hourly cost, plus any revenue you can defend conservatively, divided by what the build costs.
Under twelve months of payback, build it. Between twelve and twenty four, build it only when it also removes a risk you care about. Over twenty four, park the idea and look again next year.
That rule is strict on purpose. Volume moves fast in a growing company, so an idea that fails today often passes two quarters later, with a cheaper build because the process got clearer in the meantime.
It also protects you from the most expensive mistake in this field, which is building something impressive for a process that was about to change anyway.
Five things you can do tomorrow.
- List every process your team touches more than five times a week. Ten lines is plenty.
- Put two numbers next to each one: minutes per pass, and passes per week. Multiply.
- Circle the three that also cost you money when they go wrong.
- Of those three, pick the one closest to revenue. That is your first system.
- Switch off one report nobody has mentioned in a month. See if anyone notices.
