Blog / Small Business Automation
Questions to Ask Before You Hire Automation Help
By Keyona Meeks, Founder, ReRev Labs · Oct 31, 2026 · 6 min read
The short answer: Ask who owns the automation after launch, where the code and data live, what happens when it breaks, what they would not automate, and how they handle a messy input. A good answer is specific to your workflow, names a person, and admits a limit. A vague answer, or "we can automate anything," is the warning sign.
By the end of this post, you'll be able to:
- Ask ten questions that sort a good fit from a poor one.
- Recognize what a good answer sounds like, and what a weak one sounds like.
- Paste the list into an email and send it to anyone you are considering.
You have a workflow that eats your week. You talked to two people who said they could fix it. Both sounded sure. You cannot tell which one to trust, because you do not know what to ask.
This list is for that. I sell build work, so you should know I wrote it knowing you might send it to me. I answer them for ReRev where the answer is a fact I can state. Where it is a judgment, I say what a good answer sounds like and leave it there. If someone you are considering will not answer these, that tells you something.
What are the ten questions?
1. Can you restate my workflow in your own words?
Why ask: It shows whether they listened. It also shows whether they understood the exception, not only the normal case.
A good answer: They name the trigger, the steps, who does each one and what goes wrong most often.
A weak answer: A general description of "automating your process" that could fit any business.
2. Who owns it after launch?
Why ask: Most automations do not fail on day one. They fail six months later, when something changes and nobody is watching.
A good answer: A named person on your side, a way for that person to know when it fails, and a handover note.
A weak answer: "It just runs."
Our answer: Every build we do includes a handover note that names who owns it, where it lives and how to change it.
3. Where do the code and the data live?
Why ask: If they live in the builder's account, you cannot leave without losing them.
A good answer: In accounts your business owns. For reference, our free install offer builds on the reader's own accounts, and they keep the tool whether or not we ever work together.
A weak answer: A hosted setup you cannot see, with a monthly fee to keep it alive.
4. What happens when it breaks?
Why ask: It will break at some point. A password changes, a form changes, a limit is hit.
A good answer: A plan. An alert that goes to a named person, a place to see what failed, and who fixes it.
A weak answer: A promise that it will not break.
Our answer: Every build we do includes a failure alert that goes to a named person, so a break does not sit unseen.
5. What would you not automate in my workflow?
Why ask: A person who says "everything" has not looked closely.
A good answer: A specific step that needs judgment, a relationship or a decision. They leave it to a person.
A weak answer: "We can automate all of it."
6. Where would an AI model fit, and where would it not?
Why ask: An AI model can be useful at a step with messy input. It is also harder to test and costs more to run than a plain rule.
A good answer: A rules-first answer. Steps with clear rules run as plain automation. A model appears only where the input is messy, and a person checks the result before it goes anywhere important. That is our stance: AI writes the code, plain automation runs it, and an LLM shows up only at specific points where input is messy and a person checks.
A weak answer: An AI agent for the whole workflow, with no description of how it is checked.
7. Which tools will it use, and which of those do I pay for?
Why ask: A build that depends on three paid subscriptions you did not budget for is not a fixed cost.
A good answer: A list of tools, and which have a free tier you can stay within. They say what happens if you outgrow it.
A weak answer: "We'll figure it out."
8. How will you test it, and with what data?
Why ask: The demo works with demo data. Your real data has missing fields, odd spellings and duplicates.
A good answer: They ask for a sample of your real inputs, with private details removed, and for the awkward cases.
A weak answer: A demo and a handshake.
Our answer: We test on a sample of your real data, with private details removed, before anything goes live.
9. What do you need from me, and how much of my time?
Why ask: Most delays come from waiting on the client. You want to know before you start.
A good answer: A list. Access they need, decisions they need, who on your side checks the result.
A weak answer: "Nothing, we'll take care of it."
Our answer: We give you a list of what we need from you before work starts: access, decisions and who checks the result.
10. Who else touches my data?
Why ask: Your workflow may carry customer names, emails and invoices. You should know which tools see them.
A good answer: A short list of tools and who has access. If the data is sensitive, such as health, payment or ID data, they say you should check with a professional first.
A weak answer: A general "it's secure."
How do you use this list?
- Copy the ten questions into an email.
- Add two sentences about your workflow: what starts it and what goes wrong.
- Send it to each person you are considering.
- Compare the answers side by side. Look for names, specifics and limits.
If an answer is vague, ask a follow-up. Whether they reply with "here is what we do not know yet" or "trust me" matters more than the answer itself.
What should you have ready first?
A builder can only answer well if you can describe the work. Write down seven things: what starts the workflow, the steps in order, who does each one, where the data lives, what goes wrong most often, what done looks like and who will own it afterward.
Where this has limits
- A good answer is not a good result. The list sorts out weak candidates. It does not guarantee a good build.
- I sell build work. I wrote this list, and I would like you to send it to us. Send it to everyone you consider and judge the answers.
- These are not legal or security advice. If your workflow carries sensitive data, or you need a contract reviewed, check with an attorney or a security professional.
- Price is a separate question. I have not included one, because I cannot know your hours or your rate.
If you want to see how we answer these for your workflow, you can apply on /letstalk. Bring the list with your two sentences added. Do not send passwords or login details.
Frequently asked questions
Do I need to understand the technology to ask these?
No. Every question is about ownership, risk and how the work gets checked. You are judging whether the answers are specific, not whether they are technically correct.
What if a freelancer says they cannot answer some of these?
That is fine for small jobs, if they say so. Ask who will own the automation, and plan for it. A job with a failure that costs you money needs better answers.
Which question matters most?
Number 2. If nobody owns it after launch, even a good build decays.
Should I ask for references?
You can. Ask for a past project like yours and what changed in it after launch. I do not list client names on this site, so I will not give examples here.
Is it a red flag if someone will not give a fixed price?
Not by itself. Some work cannot be priced until the workflow is clear. It is a flag if they will not say what they need to know to price it.
Does it matter if they use AI to write the code?
AI tools make a first version of a script much faster to write. What matters is who tests it, who owns it and who fixes it when it breaks. Ask question 4 and question 8.
Read next: When to hire someone to automate a workflow if you are still deciding whether to hire at all, and construction automation consultant: what to look for if the work is construction-specific.