Hiring an Automation Partner: 12 Questions to Ask First

The Bad Outcome Is Not a Failed Project

When a business owner tells us their last automation project went wrong, the story is seldom that nothing got built. Something got built. It worked for four months. Then a tool updated its API, the workflow broke, the person who built it had moved on, and nobody inside the company knew how it worked or where it lived.

That business paid $18,000 for something that now costs them money to remove. The build quality was fine. The terms were the problem.

These twelve questions cover the things that decide whether you end up with an asset or a dependency. Ask them before you sign, and pay attention to which ones make the vendor uncomfortable.

Ownership and Access

1. Who owns the automations after we pay you?

The answer you want is "you do, in writing, in the contract." Some agencies build inside their own accounts and license access back to you. That means the day you leave, the work stops.

Ask for the specific clause. If they say ownership transfers on final payment, get that in the signed agreement rather than in an email.

2. Whose accounts will this run in?

Everything should be built in accounts your business owns and pays for: your Zapier or Make workspace, your cloud hosting, your API keys under your billing. The agency gets invited as a collaborator and you remove them when the relationship ends.

If a vendor wants to host your automations in their infrastructure, the price of leaving becomes a full rebuild. Some will offer a discount for it. The discount is smaller than the exit cost.

3. What do we get handed over at the end?

A complete handover is a written description of each workflow, a diagram or list of what triggers what, credentials stored in your password manager, an inventory of every account and subscription created, and a short video walkthrough of the important pieces.

Ask to see a sample handover package from a past client with the names removed. Vendors who do this well have one ready. Vendors who do not will describe it in general terms.

What Happens When It Breaks

4. What is your response time when something stops working?

You want a number, in the contract, tied to severity. Something that stops orders or invoices from processing should have a response inside four business hours. A cosmetic issue can wait two days.

Also ask what "response" means to them. An acknowledgment of your email is different from someone working on the problem.

5. How will we know something broke before a customer tells us?

Every workflow they build should have error alerting attached: a message to a Slack channel or an email to a named person, with enough detail to act on. Ask them to show you what one of those alerts looks like.

A vendor who has not thought about failure alerting has not run automations in production for long.

6. Who fixes it when a vendor changes their API?

This happens two or three times a year across a typical stack. Establish who is responsible, whether it counts as warranty work or billable maintenance, and how fast they act.

A reasonable arrangement includes a warranty period of 30 to 90 days after delivery where breakage is fixed at no cost, followed by an optional maintenance retainer.

Money

7. How do you charge, and what triggers extra fees?

Three models are common. Fixed price per project gives you cost certainty and pushes scope disputes to the front. Hourly gives flexibility and no ceiling. Monthly retainer buys ongoing capacity.

For a first project, fixed price with a clear scope protects you best. You learn whether the vendor is good before you commit to a retainer.

8. What will the software cost us every month once this is running?

Automation platforms charge by volume. A workflow that looks cheap at 500 runs a month costs four times as much at 5,000. Ask for a written estimate of monthly software cost at your current volume and at double your current volume.

Vendors who skip this conversation are the ones whose clients get a surprise Zapier bill in month three.

9. What happens to the price if the scope changes?

Scope changes on every project. Ask how they handle it: a written change order with a price before work starts, or an invoice at the end that you find out about later. Only one of those is acceptable.

Competence and Fit

10. Show me something you built for a business like mine.

Ask for a specific example, with a screen share of the live workflow if they will do it. You want to hear what the client's problem was, what got built, how long it took, and what it saved. Vague case studies with percentage improvements and no detail mean the vendor either did not build it or cannot explain it.

Then ask for two references from clients who have been live for more than a year. Recent clients are still in the honeymoon phase. Year-old clients know how the vendor behaves when something breaks.

11. What would you tell us not to automate?

This is the most revealing question on the list. A good partner has opinions about where automation makes things worse and will name examples: complaint handling, high-value negotiations, anything where the process changes every month.

A vendor who says everything is automatable is selling hours.

12. How do we measure whether this worked?

Agree on the metric before the build starts, and get the current number written down. Hours per week on a task, days from signature to start, invoices sent within 48 hours of completion, whatever fits the project.

Without a baseline, everyone argues about results from memory, and the vendor always remembers it going better than you do.

The vendor who gives you a straight answer on ownership and failure has been on the wrong side of both before.

Reading the Proposal Itself

A proposal tells you how the vendor thinks. Three things to check before you look at the price.

Does it describe your business back to you, with your numbers and your process? A proposal that could be sent to any company in your industry was written before the call. Does it name the specific tools and platforms, or does it say "automation platform" and leave itself room? Vague tooling means either they have not decided or they want the option to use whatever is cheapest for them.

And does it list deliverables you can point at, with dates? "Discovery and design" is not a deliverable. "Workflow that creates a QuickBooks customer and invoice from a closed HubSpot deal, tested with 20 records, delivered week three" is a deliverable. You can tell whether it happened.

If the proposal is one page with a total at the bottom, ask for a breakdown before you respond to the number. How they react to that request tells you a lot about the next four months.

Warning Signs

A Sensible Way to Start

Do not hand a new vendor your whole operation. Buy one small project first, fixed price, four to six weeks, one workflow that matters but will not stop the business if it goes sideways.

You learn how they communicate, whether they hit dates, what their documentation looks like, and how they behave when something goes wrong. That costs you $3,000 to $8,000 and it is the cheapest due diligence available.

If it goes well, expand. If it does not, you own what got built and you walk away with a lesson instead of a rebuild.