Questions to ask anyone building your automations
Ask how they decide which system holds the true record, how they stop duplicates and double sends, who hears about a failure, what stays with a person, who controls the data and the automations after handover, and how changes are made and priced later. A careful builder answers each one in plain words before you sign.
You can't judge an automation by looking at it. On the day it's handed over, a careful build and a fragile one look the same: the test lead goes in and the right email comes out. The difference shows months later, when a step fails, a contact gets created twice, or the person who built it has moved on.
These are the questions I'd want an owner to ask me before signing, with what a careful answer sounds like and what should make you wary. Listen for whether each answer is specific to your process and names who does what.
The questions, and what to listen for
| Question | A good answer sounds like | A red flag sounds like |
|---|---|---|
| Which system is the source of truth for each piece of client data? | One system owns each field, usually the CRM for contacts and deals. Other tools read from it, and an edit made somewhere else goes back to the owner. | "Everything syncs both ways, so they'll always match." |
| How do you stop duplicate contacts? | A match rule checked before any record is created, such as email address first, then company domain and name. A match updates the existing record. | "The tool handles duplicates," or "I'll clean them up every so often." |
| What happens when a step fails, and who hears about it? | An alert that names the system, the step and what to do next, sent to a named person. The run can be repeated without sending anything twice. | "It won't fail," or "You can always check the logs." |
| If someone presses approve twice, how many emails go out? | One. Each approval sends once, however many times the button is pressed, and the extra presses are recorded. | "Why would anyone press it twice?" |
| What stays with a person? | The decisions that need judgment in your process, named one by one, such as scope, price and anything a client reads before you've seen it. | "I can automate all of it." |
| Who controls the data and the automations after handover? | You can see the data, export it and switch the automations off without the builder, and the builder's access is a login you can remove. | "You won't need access," or no clear answer on how you get your data out and switch it off without them. |
| What documentation do I get? | A written map of each automation: what starts it, what it changes, where its alerts go and how to switch it off, in words someone new can follow. | "It's self-explanatory," or "The workflow is the documentation." |
| How do changes get made later? | A short written request, the change tried on a copy before the live version moves, and the handover notes updated to match. | "Just message me and I'll tweak it live." |
| What would you not automate here? | Something specific from your process, with the reason, such as a step that needs judgment or happens too rarely to be worth building. | "Everything can be automated." |
| How do you price changes after the build? | The basis is written down before you sign, either per change or as a monthly arrangement that says what it covers. | "I'll work it out when it comes up." |
| Which tool would you use, and why that one? | A tool chosen after hearing your process, with the trade-off explained: who can maintain it, and how the cost grows as the volume grows. | A tool named before they've asked how your work runs. |
Why these questions
Each question tests something a demo can't show. A demo walks the path where everything goes right. These questions ask about the other paths: two tools holding different details for the same client, the same lead arriving twice, a step that stops halfway, a button pressed twice, and the day the builder is gone.
The reliability questions come first, and the standard behind them is short. One place owns each piece of data, nothing is created or sent twice, and a failure reaches a named person. The rest are about ownership. An automation you can't read, change or switch off without the person who built it belongs to them in practice, whatever the invoice says.
What handover should include
When the build ends, the system should be yours in three ways.
- Your data, kept in tools your business controls.
- The automations, which you can see, export and switch off without the builder, with the builder's access on a login you can remove.
- Handover docs written so whoever runs it next can follow them without calling the builder.
I don't build mystery automations. Each one should be documented and easy to maintain, so the business can run it without me.
How to use them
Ask them on the first call and listen for specifics. A careful builder will often answer some before you ask, and will say plainly when something depends on your setup. Then ask for the ownership answers in writing, in the proposal, so they are part of what you sign.
If you'd like to put these questions to me, book a free consultation. I'll answer each one about how I build, and you can hold the work to those answers later.
Questions
Should I ask these even for a small automation?
Yes, and the answers can be shorter. A small automation that sends email or creates contacts can still send twice or fail without anyone noticing. At the least, ask about failures and double sends, because those are the problems a client sees.
What if the builder can't answer one of them?
Ask how they would handle it, and listen for a plan you can check. A builder who hasn't met a problem before but explains how they would deal with it is still worth talking to. A builder who brushes the question off is the warning.
Do I need to understand the tools to judge the answers?
You can judge them on whether they are specific to your process and name who does what. If an answer is full of tool names and you still can't tell who hears about a failure, ask again in plain words.
Should the builder have a login to my accounts?
Usually yes, while they build and look after it. Give them their own login, so you can see what they changed and remove their access when the work ends. A shared password makes both of those hard.
How can I check the answers after the build?
Ask for a short test with you watching: press approve twice, send the same lead in twice, and break one step on purpose. Then check that one email went out, one contact exists, and the alert reached the person named in the handover docs.
Is a monthly support arrangement a bad sign?
Only if you couldn't walk away from it. Support should cover changes and watching the alerts. You should still be able to export your data and switch the automations off yourself, and the docs should be good enough for someone else to take over.
Related
- What a reliable automation looks likeFive properties any automation should have, checkable by an owner who doesn't build: logged runs, named alerts, one send per approval, safe reruns, an owner.
- n8n vs Zapier vs Make: which should a service business run on?What each one bills for, who can change a workflow, what happens when a step fails, and where n8n, Zapier and Make each fall short for a small service firm.
- Should I hire an operations coordinator or install a system?What an operations coordinator costs a year, set against installing a system: where each one fails, and which to pick first when your agency is growing.
- Two tools, two truths: which system is the source of truthWhen two tools disagree about a client, pick one owner tool for each field, let changes flow one way from it, and send edits made elsewhere back to the owner.
- Automations that fail without telling anyoneAn automation can stop for weeks before anyone notices. The usual causes, what not knowing costs, and what an alert should say when a step fails.