How to automate one job without betting the business on it

It's 9pm on a Tuesday and somebody's furnace has quit. They ring you, they get the voicemail greeting you recorded four years ago, and they hang up and ring the next name on the list. By the time you play that message back over coffee, the job is booked with somebody else and you will never know it existed.

That, or a version of it. The submittal that gets re-keyed into the project system by the one person who should have been on site. The delivery slip that came back two pallets short and nobody caught until the customer rang, annoyed, eight days later. You already know which one yours is. What you probably don't know is how often it happens, and that turns out to be the first real question.

What follows is the order I'd work through it. It is not a project plan, it's a sequence, and the useful thing about a sequence is that you can stop partway. Stopping after step two because the numbers said don't bother is a good outcome, not a failed project. The version of this that goes wrong skips the first two steps and starts with a demonstration somebody liked at a trade show.

Step one: name one job, out loud, in one sentence

Not “we should look at AI”. One job, described the way you'd describe it to your foreman.

“Calls that come in after five go to voicemail and I lose the ones I don't ring back by seven.”

“Every delivery slip gets typed into the system by hand, twice if the driver's writing is bad.”

“Field notes come back on paper and somebody matches them to job numbers on a Friday afternoon.”

If you can't say it in one sentence, the problem isn't the technology, it's that two or three different problems are wearing one coat. Split them and pick the one that costs you the most sleep.

Step two: count it before you change anything

Two weeks, on paper if that's what you've got. For the after-hours calls: how many come in outside hours, how many you rang back, how many booked. For the paperwork: how many documents a week, how long one takes, who does it, and what else they weren't doing while they did it.

Do this before anything is installed, because once a system is running you cannot go back and take the reading. The “before” number stops existing the day you change the process, and every argument you'll have afterwards about whether the thing was worth it comes down to a number nobody wrote down.

Two weeks of counting also settles a question quietly. Sometimes you find you get four after-hours calls a month and three of them are the same customer asking about an invoice. That's not an automation problem, that's a phone message and a five-minute conversation, and you've just saved yourself a project. I'd rather a client find that out in a fortnight than after a build.

Step three: build the smallest version that helps somebody this month

The temptation is to do the whole thing: every call, every document, every branch of every exception, wired into the system of record. Resist it. The whole thing takes months, and months is long enough for the person who was enthusiastic about it to move on and for you to stop caring.

The smallest version of the after-hours call is: the line rolls over after six, the caller says what's wrong, and by the time you look at your phone there's a written summary sorted into “no heat, no hot water, tenant with no power” and “everything else”. Nothing is booked. Nothing is promised. It just means that at 6am you're reading four sentences instead of playing back nine voicemails at half speed.

The smallest version of the paperwork job is: slips get read, the numbers come out into a sheet, and a person checks the sheet. Nobody's system got replaced. Nothing got deleted.

That's deliberately unambitious, and it is the version that survives, because the failure mode is visible and cheap. When it gets something wrong, you find out on Tuesday morning with a coffee, not on Friday from a customer.

Step four: run it beside the old way, and don't turn anything off

For as long as it takes to trust it, both things run. The voicemail box still records. The paper slips still go in the tray. You're comparing, not switching.

This costs a few weeks of mild duplication and it's the cheapest insurance in the whole exercise. It also produces the only evidence that matters — a fortnight of the same inputs handled both ways, which tells you exactly where the new thing is better and exactly where it's worse. You will find it's both.

Step five: decide what happens when it's wrong, before it's wrong

Everything here gets things wrong. The question is never whether, it's what happens next, and there are four answers you want settled in advance.

What does it do when it isn't sure? The only acceptable answer is that it says so and hands over. A system that guesses confidently on a call it didn't understand is worse than no system, because you stop checking.

What happens when it's down? The phone line, the internet, the service it depends on — one of them will be out on a day that matters. There has to be a route back to the way you did it before, and somebody has to know what that route is without ringing me.

How does a person take over, and do they know it's their turn? A handover nobody notices is not a handover.

What does it keep a record of? Six weeks from now you'll want to know why a call got sorted the way it did. If the answer is “nobody can tell”, you have a system you can't fix and can't defend to a customer.

Step six: try it on the ugly ones

Every demonstration you'll ever be shown uses the clean example. The typed slip. The clear voicemail from a calm caller in a quiet room.

Your week isn't made of those. It's the slip photographed at an angle in the cab with a thumb over the corner. It's the voicemail with a compressor running behind it and a number said once, fast. It's the handwritten note with a job number that has a letter in it that could be a 1 or an l. It's the PDF that isn't really a PDF, it's a photo of a fax.

Take twenty of your worst real ones and run those. What you learn from twenty bad examples is worth more than anything a demonstration will show you, and it's the test I'd want to fail early, while it's a conversation rather than a build.

Step seven: give it to one person who'll complain

Not the one who's keen. The one who'll tell you it's annoying.

Give them a fortnight and ask them what they've stopped using it for, which is a different question from what they think of it. People are polite about software and specific about their own workarounds. If they've gone back to playing the voicemails because the summary missed something once, that's the most useful thing you'll hear all month, and you'll only hear it if you ask that way.

Expect a few things at this stage. The wording needs changing more than the technology does. One category is wrong — what you called “urgent” doesn't match what the person answering the phone means by urgent. And accuracy is fine in general and poor on one specific kind of input, which is always the kind that matters most to somebody.

Step eight: turn the old way off, in one lane at a time

After-hours only, before you touch daytime calls. One depot before four. One customer's paperwork before all of them.

Weeks between steps, not days. Each one gives you a chance to stop, and the person in the next lane hears it's working from a colleague rather than from you, which lands completely differently.

Step nine: accept that it doesn't stay fixed

This is the part that gets left out of every proposal I've read, and it's the reason I price my own work as a build plus a monthly rather than a one-off.

An automation isn't a boiler you install and walk away from. Your supplier changes the layout of their delivery note. The phone provider changes something. The model behind it gets updated and behaves slightly differently on the edge cases. A new customer arrives whose paperwork looks like nothing you've seen. None of that announces itself. It shows up as the thing quietly getting worse until somebody notices it's been wrong for a month.

So somebody has to be watching it, and you should know who that is before you switch it on. If the answer is “the person who built it, and I have their mobile number”, fine. If the answer is nobody, you've bought a thing that works today.

Where this usually goes off the rails

Your people think it's about their job. Say something about it early and directly, because they're already discussing it without you. In this kind of work the honest answer is usually that it takes the retyping, not the trade — but say it, name what changes for them specifically, and involve the person who does the job in the design. They know where the exceptions live, and the exceptions are the whole difficulty.

The scope grows sideways. Once one thing works, everything looks automatable. Keep a list of the next things and let it be a list. Being able to say “yes, and not this quarter” in one sentence is worth having.

The connecting part turns out to be harder than the clever part. Reading a delivery slip is the easy half. Getting the numbers into the system you already run, in the format it wants, without breaking whatever else writes to it, is the half that takes the time. Anyone who quotes you for the first half has quoted you for half a job.

How you'll know it worked

Early on, all you can see is whether people are using it or quietly going around it, whether it stays up, and how often it's right. Those aren't money, but they arrive first and they tell you whether to continue.

A few months in the real ones show up, and they're the ones you counted in step two: hours, jobs won that would have gone elsewhere, exceptions caught the same day instead of the next week.

And some of it never becomes a number. Whether you'd object if I switched it off tomorrow is worth knowing, and no dashboard reports it.

Where to start

If the after-hours call is your version of this, have a look at the demo I built for it. It takes a sample voicemail, works out what the caller actually needs and how urgent it is, and writes it down: triage a sample voicemail. The data in it is fictional and the whole thing takes a minute. Look at what comes out and ask whether reading that at 6am would have been better than playing the message.

Then book a call and tell me which job goes wrong most often. If the honest answer after ten minutes is that counting it for a fortnight would tell you more than hiring me would, I'll say so.