Buy, build or refuse: an automation decision that survives the demo

01

Refuse is the default, not the failure case

The business case needs an explicit benefit, an owner and a stopping condition. If a tool is expected to save time, state where the released time will go and how the service will notice the difference.

A technically successful pilot can still fail its operating purpose. I would separate reliability of the tool from improvement in the service and require evidence for both.

Ask the supplier to demonstrate the claimed capability on an agreed scenario. Record which steps are automatic, which require a person and which fall outside the product. A category label is not a specification.

02

The four gates

This is the sheet I would put in front of anyone facing an automation decision on Monday morning. In short, write the process as it runs, measure it for four weeks, name one owner and plan the exit. Pass all four before any purchase order is raised. Four gates. A failure at any one of them means refuse, and refuse means fix the operating condition first, then reopen the question next quarter.

Gate one. Write the process as it actually runs. Sit with the person doing the work and record exceptions, missing information and decisions that need judgement. Test those conditions alongside the routine path.

Gate two. The process is measured today. If you cannot say what the current call abandon rate, no-show rate or turnaround time is, you will never be able to prove the tool helped, and you will end up defending a spend with anecdotes. Measure for four weeks before you buy anything.

Gate three. One person owns the result by name. Not a committee, not the vendor, not the person who ran the pilot and has since moved teams. Somebody whose week gets worse when the tool misbehaves.

Gate four. You can survive the supplier disappearing. Can you export your data in a form you could actually use. What is the notice period. What happens if they are acquired next year and the pricing doubles. Write the exit before you write the purchase order.

An afternoon gets you through all four. It is the cheapest afternoon in the whole project.

03

Buy the things every clinic needs

Once the gates are clear, the buy or build split is much less interesting than people make it.

Buy anything that every clinic on earth needs and none of them wins on: reminders, telephony, payments, rostering, e-signature, document storage. You will never be better at sending an SMS than a company whose entire existence is sending SMS. Building it in house means you now maintain it forever, and the person who wrote it will leave.

A specialist supplier may be a sensible choice for a common task, but I would still compare service support, exit costs, data portability and the work retained by the clinic. Buying transfers some work; it does not remove accountability for the service.

The discipline in buying is not choosing well. It is choosing narrowly. One tool, one job, one owner, one measured number it is supposed to move. Bundles are how you end up paying for eleven modules to use two.

04

Build only what you would defend in a board meeting

Build when the process is the thing that makes your operation different from the clinic across the road, and when you already run it well manually. That last clause is the one people skip. Automating a process you have never made work by hand does not fix it. It industrialises the mess and adds a licence fee.

In practice that narrows the build list to almost nothing: your own quality scoring rules, your own escalation logic, the specific way you route a nervous first-time enquiry. Those are worth owning because nobody else can sell them to you.

Involve the clinicians who will use or be affected by the tool before selecting it. Ask them to define the clinical boundaries and the circumstances that require human review. The adoption decision needs their judgement as well as the commercial team's requirements.

05

What the demo is built to hide

A demo is a sales asset, and a good one is honest about the product and silent about the conditions. It will not show you what happens on the fourth exception in a row, at handover, with a partial record, in the second language your front desk actually uses.

So ask your own. Make them run your worst week, not their best case. Give them twenty real anonymised records including the three that break every system you have ever used. Ask what the tool does when it is unsure, and whether it says so or guesses. Ask who gets paged. Then ask for a customer of your size, in your market, who left them, and why.

The suppliers worth buying from answer all of that without flinching. The rest suddenly want to schedule a follow-up.

The demo is not lying to you. It is answering a question you did not ask.

06

The verdict

You do not control the supplier market. You do not control what they charge next year, which of them still exists in three years, what a regulator decides about the whole category, or whether the model behind the product gets better or quietly worse after an update you did not ask for. Treat all of that as weather. Plan for it, do not argue with it.

What you do control is the entire part that determines the outcome. Whether the process is written down as it truly runs. Whether it is measured before anyone spends money. Whose name is against the failure. What you agree to sign and how fast you can walk away. Whether the people who use it were asked.