Ten questions to ask before you hire anyone to automate your business

Before you hire anyone to automate your business, get clear answers to ten questions: who owns the system when you part ways, what breaks and who fixes it, where your data lives and who can see it, how success gets defined and measured, and whether you can exit without losing everything. Any vendor who cannot answer all ten cleanly is not ready to touch your operations.

---

What do you actually own when the project is done?

You own the system if you hold the credentials, the code or workflow exports, the API keys, and the documentation — on day one after launch, not after a maintenance contract expires. Ownership is binary. Either the system runs in your accounts or it runs in theirs. That distinction determines your leverage forever after.

Ask specifically:

• Accounts: Does the automation live in your Zapier, Make, or n8n workspace — or theirs?
• Code: If there is custom code, do you receive it in a repository you control?
• Credentials: Are all third-party API keys issued to your business accounts?
• Documentation: Is there a runbook written for someone other than the builder?

If any answer is “we manage that on your behalf,” treat it as a red flag until you understand the exit clause.

What breaks when it breaks, and who fixes it?

Every automation fails eventually. An API changes, a webhook stops firing, a form field gets renamed. The question is not whether it will break — it is how fast you find out and who is responsible for the fix. Get this in writing before you sign.

The answer you want: the vendor monitors the system, alerts you within a defined window, and fixes integration-level breaks as part of the retainer. The answer to walk away from: “just email us and we’ll look into it.”

Useful follow-up questions:

• What monitoring is in place — active alerts or manual checks?
• What is the documented response time for a critical failure?
• Is emergency support included or billed separately?
• Who do I call at 11 p.m. on a Sunday?

Where does my data live, and who can see it?

Your automation stack touches customer names, phone numbers, conversation transcripts, deal data, and sometimes payment information. Every tool in the chain is a potential exposure point. You need to know the full map before you build on top of it.

Ask for a data-flow diagram — a simple one is fine — that shows every system the data passes through and which country those servers sit in. Then ask who at the vendor’s company can read your customer records. The answer should be “no one without your explicit authorization.”

In the businesses I run — including an AI receptionist platform and a real-estate operation run end-to-end on automation — data residency and access controls are non-negotiable from the first conversation. As of July 2026, every system I build or advise on starts with a written data-flow map before a single workflow is created. The map names every tool, every API connection, and every human who can read the records. If a vendor cannot produce that document within a week of kickoff, I treat it as a signal that the system will be ungovernable at scale. Governance is not a compliance checkbox — it is what makes automation safe to run unattended.

How will we measure whether this worked?

Automation without a defined success metric is a science project. Before any build starts, agree on the specific number that will move and the baseline it is moving from. Run the model on your own inputs: if the system handles a volume of tasks you can estimate, at a time cost you can measure, what does that free up and what does it cost to maintain?

A clean engagement looks like this:

Element	What you want
Success metric	Named KPI already on your dashboard
Baseline	Documented before build starts
Measurement method	Automated report, not manual counting
Review cadence	Scheduled, not ad hoc
Definition of failure	Written, not implied

If the vendor pitches outputs (“we’ll build you a workflow”) instead of outcomes (“we’ll reduce your unhandled inbound calls by a target you set”), the project has no finish line.

Can I leave cleanly, and what does that cost?

An automation stack you cannot exit is a liability disguised as an asset. Ask for the offboarding procedure on day one. A confident vendor has one written already.

This is where working with a Fractional Chief Automation Officer changes the dynamic: the mandate is to build systems the business owns, not systems that create dependency. When I built Business Runner, the architecture assumption was that every component had to be replaceable. That discipline starts with the questions you ask before anyone writes a line of logic.

The ten questions above are not adversarial. They are the minimum standard for a vendor who is serious about your operations. Any builder worth hiring will answer them without hesitation — and probably respect you more for asking.

---

There is a voice agent running on this site right now — go ahead and talk to it.