Questions to Ask Before Hiring an Automation Agency

The sales call is not where the real information lives. It is where it gets hidden.

An agency that skips discovery will still show you a polished demo. One that has no maintenance plan will still give you a confident answer about post-launch support. One that will bill every field rename as a change order will still tell you the relationship is collaborative. These things only surface when you ask the right questions directly.

Seven questions. Each one is designed to expose how a provider thinks about workflow clarity, ongoing ownership, and what happens when things break. The answers reveal more about fit than anything else in the sales process.

The Demo Is Not the Test

Most buyers evaluate automation agencies on three things: the demo, the case studies, and the price. None of those tell you what you need to know.

The demo shows you what they built for someone else. The case studies are curated. The price is the number they're willing to say out loud before they know your workflow.

What you actually need to know: do they map before they build, who owns the system after it's live, how do they price changes, and what happens when an API breaks at 2am on a Tuesday. None of that appears in the deck.

The questions below are the test. Work through them before any provider conversation, including ours.

If an agency can tell you exactly what they'll build after a 30-minute sales call, they haven't asked enough yet.

What gets evaluated vs. what determines the outcome

What the sales process shows	What actually determines the outcome
The demo of a system built for someone else	Whether they map your workflow before they build
Curated case studies	Who owns the system once it's live
A price quoted before they know your workflow	How changes get priced after the build closes
A confident answer about support	What happens when an API breaks at 2am

Seven Questions Worth Asking

1. "Walk me through your discovery process before anything gets built."

A staffing firm evaluated three agencies for automating candidate intake. Two led with slide decks about their tech stack. The third asked to spend 45 minutes mapping how candidates actually moved through the process. The firm hired the fastest quote.

The system was rebuilt six months later. It didn't match how intake actually worked.

The agency that gave the fast quote was selling a predetermined solution. Discovery looked like a formality. It was.

Mapping is not a delay before the work starts. It is the work. A provider who can scope and quote your project confidently after one call has assumed a lot. Ask what artifact the discovery process produces. Ask to see an example.

The fix If they skip mapping, they are selling you a solution they designed before understanding your problem. Speed to quote is a warning sign, not a selling point.

2. "What happens when an API changes or a connected tool gets updated?"

A property management company's lease-renewal automation broke silently. The e-signature provider deprecated a webhook format eight months after launch. The engagement had ended. The internal contact had changed roles. Three weeks passed before anyone noticed.

"Delivered and done" treats automation as a static artifact. It is not. It is a live operational dependency. Every third-party integration is a dependency on someone else's roadmap. Things change. APIs update. Vendors get acquired. Required fields appear.

Ask specifically: who monitors for errors, who gets alerted when something breaks, what it costs after the project closes. "You'd just reach out to us" is not a plan.

The fix The maintenance question is not about support tickets. It is about who owns the system as a live asset once the build is done.

3. "Who is my point of contact after the build is live?"

A professional services firm's responsive sales contact handed off to a support queue after signing. The SLA was three to five business days. A CRM field rename sat nine days. Four proposals generated incorrect pricing in the interim.

Agencies often separate the selling relationship from the operating relationship. The person who closes the deal is not the person who handles the system afterward. That is not inherently a problem. The problem is when you find out after signing.

Ask directly: is the person who built it still reachable post-launch, and how does knowledge transfer work if that person moves on.

The fix Know the operating relationship before you agree to the project relationship. They are not the same thing.

4. "Can you show me a working artifact from a recent discovery session?"

One agency showed a polished swim-lane diagram. Clean, symmetric, clearly made after the fact. Another showed a messy annotated map with exception branches, informal steps surfaced in interviews, and open questions still unresolved.

The messy one would have caught the buyer's actual problems.

Clean diagrams often mean superficial discovery. Real workflow maps are messy because real workflows are messy. Exceptions, informal approval steps, workarounds nobody wrote down. Those are the things that break automation. If discovery didn't find them, the build doesn't account for them.

The fix Ask for a working artifact, not a polished deliverable. A real map has unresolved questions on it.

5. "How do you price ongoing changes: included, hourly, or new project scopes?"

A recruiting firm's fixed-fee agency quoted a new referral channel at roughly 60 percent of the original build fee and billed every field rename as a change order. By month twelve, the client had paid more in change orders than the original build. The relationship was adversarial.

Every pricing model is legitimate. Flat fee, hourly, project-by-project. What matters is knowing which one you are buying before you sign. Fixed-project pricing optimizes for clean contract closure. The agency gets paid when the project ends. Changes after that point cost extra. The incentives point in opposite directions once the scope is set.

Ask what model applies to small changes. Ask for an example of something that would and would not trigger a new scope.

The fix "It depends on scope" is not an answer. Each model has tradeoffs. Know which tradeoffs you are accepting.

6. "What is the smallest thing you could build first to prove this works?"

A food distributor chose a full-scope single engagement over a phased proposal that started with just order routing, deliverable in three weeks. The full-scope project ran five months over because upstream exception assumptions were wrong.

Large upfront scopes optimize for contract size. Smallest-first optimizes for proving the approach. Those are different objectives.

A good answer to this question is a concrete, narrow first deliverable with a clear success criterion. Not "we'd start with an intake form," but "we'd automate the order routing step, it would be live in three weeks, and success looks like X orders processed without manual intervention in the first thirty days."

The fix The first deliverable should be specific enough that you could evaluate it. Vague phasing is scope that hasn't been thought through yet.

7. "What would make us a bad fit for your model?"

Three of four agencies gave non-answers. One gave an honest disqualifying list: clients who want full codebase ownership, engagements where fewer than three people are willing to map the workflow, and operations where workflows are still changing weekly.

That answer is worth more than any case study.

An agency that can't say who it's wrong for hasn't thought about its model, or it won't disqualify a prospect. Either answer is useful information. The honest disqualifying list helps you self-qualify. The non-answer tells you how they will handle misalignment later.

The fix A specific, candid answer here beats any case study. A non-answer is data.

What Good Answers Look Like

You are not looking for perfect answers. You are looking for evidence that the agency has thought about these things.

On discovery: they should be able to name what they produce and show you an example. If they can't, the process may exist in name only.

On maintenance: they should have a specific answer about monitoring, alerting, and cost. "We're always available" and "we're a Slack message away" are not answers.

On pricing: the model should be named. Included, hourly, or project-by-project. Ambiguity here gets resolved in their favor after signing.

On fit: they should be able to name at least two kinds of clients or situations where their model does not work well. Candor here is a green flag.

The sales conversation is the only point where the maintenance model, the change pricing, and the discovery process are still negotiable. Once the build is underway, the contract is signed.

The Honest Case for Not Hiring an Agency

Two situations where an ongoing agency relationship is the wrong answer.

If the workflow is genuinely one-time, won't evolve, has no third-party dependencies, and you have a capable internal operator who can own it after delivery, a one-off build with a clean handoff can cost less over twelve months than an ongoing relationship. A flat operated model is built for workflows that evolve, break, and integrate. Not every workflow is that.

If automation is a core daily concern across multiple teams at significant volume, a dedicated internal hire who lives inside the business may serve better than any external operator. Someone embedded in your operation, managing your stack full-time, on your payroll. That comparison is worth working through honestly. We have a direct breakdown if that is the question on the table.

The questions above are useful before any provider conversation. They are also useful for evaluating whether an agency is the right category of solution at all. So is an honest look at whether your business is ready to automate in the first place.

How This Connects to Why Projects Fail

Most of what goes wrong in automation projects was already decided before the first workflow was written. Wrong scope. No named owner. Untested edge cases. Discovery skipped.

The questions above are designed to surface the same failure modes before money changes hands. If you want the longer version of what those failure modes look like in production, the piece on why automation projects fail covers all seven with specifics.

The pattern is consistent: the project failed because of something upstream of the build. These questions are the upstream check.

Before the Next Sales Call

Six things to confirm before signing with any automation provider.

1. Discovery process and artifact. Ask what it produces and to see an example from a recent engagement. A real artifact has unresolved questions and informal steps on it.
2. What happens when a connected tool updates, and who pays. Not "you'd reach out to us." A specific answer about monitoring, alerts, and cost after the project closes.
3. How ongoing changes are priced. Named model: included, hourly, or project. Not "depends on scope."
4. Post-launch point of contact. Name and role. Not the sales contact's general availability.
5. Smallest first deliverable with a concrete success criterion. Specific enough that you could evaluate it in thirty days.
6. Who they are a bad fit for. A list with at least two specific disqualifying conditions.

Before you sign

• Discovery process & artifact
• Tool-change plan & who pays
• How changes are priced
• Post-launch point of contact
• Smallest first deliverable
• Who they're a bad fit for

Common Questions

A Note on the Workflow Audit

These questions are useful before any provider conversation, including ours. If we can't answer them well, that is useful information.

A reader who has worked through the list and wants to see how a real mapping session operates can book the audit. It is a working session, not a pitch. We map what you have, identify where it breaks, and tell you exactly what we would build first. If the honest answer is that our model is not the right fit, we say so.

That is question seven, applied to us.