The demo looks great. A form creates a lead, AI writes a summary, the record appears in your system and a reply goes out. You can see how it would save hours. Before you pay for the build, ask one question: “Can you show me what happens when something breaks?”
Every useful automation needs a way to notice problems, recover unfinished work and hand control back to a person. Those details matter as much as the successful demo, and you don’t need to be technical to check them. This guide gives you the questions.
Write down what the business must rely on
Take an enquiry workflow: a visitor fills in a form, the enquiry lands in your customer system, AI drafts a suggested reply, and a person approves it before sending.
What matters is that every enquiry reaches someone who can act on it, with enough context to respond. A notification alone isn’t enough if the record disappears. A saved record isn’t enough if nobody knows it needs attention.
Write your requirements in plain language:
- Every accepted enquiry is accounted for.
- A failed step is visible to the person responsible.
- The same enquiry never triggers two replies.
- A person can carry on the work if the automation is paused.
Ask the supplier which of these the build will meet, under what conditions, and how they’ll show you. “It never fails” is hard to judge. A defined failure-and-recovery process is something you can inspect.
Ask for three demonstrations
- The normal path. Using test data, follow one enquiry from the form to the record to the approved reply. Check that the business result happened, not just that the automation tool shows a green tick.
- A safe failure. In a test setup, make the destination system unavailable. Where does the enquiry wait? Who gets alerted? What happens when the system comes back? Also ask how you’d notice if a form submission never started the workflow at all.
- A repeated input. Someone clicks twice, or a step retries. How does the build avoid two customer records or two replies? You’re looking for a demonstrated result, not a particular technique.
Use dummy data and a test destination. You never need to disrupt real customer work to evaluate a proposal.
Make the failure review concrete
Scroll across to compare every column.
| Situation | Question to ask | Evidence to request |
|---|---|---|
| The form accepts an enquiry but the destination rejects it | Where is the unfinished item, and who recovers it? | A test record, a visible error, and recovery without losing the enquiry |
| The same enquiry arrives twice | What prevents duplicate records or replies? | A repeat test with the resulting records and messages checked |
| The AI draft has a wrong detail | Can a person catch it before the customer sees it? | The approval step, and proof that unapproved text isn’t sent |
| The automation is paused | Can normal work continue, and what happens on restart? | A written manual fallback and a demonstrated restart |
Prioritise by consequence. A draft filed in the wrong internal folder is very different from a wrong price sent to a customer.
Separate a tool failure from a judgement failure
A tool can stop with an error. It can also finish “successfully” while producing something unsuitable: a summary that misses the buyer’s main concern, or a confident reply about a service you don’t offer.
For work that involves interpretation, agree what a good result looks like and how it’s checked. Test with varied examples: an incomplete enquiry, an out-of-scope request, conflicting details and an ordinary good lead. Ask who approves changes to the AI instructions and who reviews outputs afterwards.
Keep automatic customer-facing actions separate from draft assistance in the proposal. You can buy one without the other.
Count the work left after automation
Suppose reviewing an enquiry by hand takes 10 minutes and you get 100 a month: 1,000 minutes, or about 16 hours and 40 minutes.
With automation, say reviewing each draft takes 4 minutes (400 minutes), plus 60 minutes for awkward cases and 90 minutes of routine upkeep: 550 minutes. That saves 450 minutes, or 7.5 hours a month, before counting setup, training and the switchover.
Compare that with the subscriptions, support charges and what you’ll actually do with the time. Freed time is valuable, but it isn’t automatically saved cash. Ask what would make the numbers worse: more volume, more exceptions, a process change or a supplier change.
Agree the handover before the supplier leaves
Agree who controls the business accounts, subscriptions and workflow after delivery, what you can export, and what another supplier would need to take over.
The handover should explain the workflow, the services it depends on, running costs, where errors appear, how to pause and restart, and who handles changes. Keep passwords in a proper password manager, never in a shared document.
Check what customer information each service receives and whether it really needs it. Clarify support too: does it cover defects in the delivered build, changes you make later, third-party service changes or ongoing monitoring?
Expand, revise or stop
Start with a small pilot you can inspect, and keep the manual route available until you trust the new one. Expand when agreed cases work, failures are visible and recovery works. Revise when the benefit is real but one weakness remains. Pause if you can’t account for every enquiry, review the output or recover safely.
Put acceptance into the proposal
Ask the supplier to include a short acceptance schedule with four cases: a normal enquiry, missing information, a duplicate and a destination service outage. For each, write the expected result, who sees a failure and how the unfinished work is recovered.
A question to send the supplier
“Please show where an accepted enquiry remains available if the next system is offline, how I will know it needs attention and how it is recovered without sending a duplicate reply.”
Agree account ownership, running costs and pause/restart instructions before the build starts. These are part of the deliverable, so another person can operate the workflow after handover.
Questions you may have
I’m not technical. How can I judge an automation proposal?
Ask three questions and have the supplier show you the answers with test data: “Where can I see the enquiry was received?”, “How will I know when something needs attention?” and “How would we keep working if this is paused?”
Should AI replies go to customers automatically?
For most small businesses, start with AI drafts that a person approves. Move to automatic sending only for low-risk messages, once you’ve measured how often drafts need correcting.
What should I get at handover?
Control of the accounts, a plain-language description of the workflow and its costs, instructions to pause and restart, where errors show up, and who to call for changes.
Bring the part of the proposal you can’t judge
No software names needed: “Today we do ___. The supplier proposes ___. I can’t tell what happens when ___.” Keep passwords and customer records out of it.
Read next: choose your first AI workflow and count the checking time.
Prefer a conversation on social? Message me on LinkedIn.