7 Questions to Ask Before Hiring a B2B Automation Agency

The B2B automation agency market is fragmented and uneven. Some shops ship working CRM enrichment workflows in 2 weeks. Others sell 12-week discovery engagements that produce a strategy document and a recommendation to start a second phase. Both call themselves automation agencies. The difference is invisible until the engagement is underway — unless you know which questions to ask during evaluation.

This checklist does not tell you which agency to hire. It tells you how to structure the evaluation so the right agency reveals itself and the wrong one disqualifies itself. Seven questions, each with an explanation of what a good answer sounds like and what the red flags look like.

Question 1: "What does the first two weeks look like?"

This question tests for operational concreteness. An agency that sells outcomes will describe day-by-day: "Day 1, we access your CRM sandbox. Days 2–3, we map the enrichment fields and set up the API connection. Days 4–5, we build the routing logic. Week 2, we test on a sample batch and you review the results."

An agency that sells consulting hours will describe process: "We start with stakeholder interviews to understand your workflows and identify automation opportunities across the revenue organization."

What a good answer sounds like: The agency can name specific tasks, specific days, and specific outputs. They ask about your CRM version and enrichment provider before they describe the timeline — because the timeline depends on the technical surface area, not on the engagement scope.

Red flags: The answer is process-oriented rather than task-oriented. The agency describes what they will learn rather than what they will build. The timeline is expressed in weeks or phases rather than days and milestones. "Discovery" appears in the first two weeks of the answer.

Question 2: "Which parts of our current stack stay and which get replaced?"

Automation agencies have a tool bias. Some default to building everything in a specific middleware platform. Others default to custom code on a cloud provider. Neither default is wrong if it matches your team's operational reality. It is wrong if the agency recommends replacing tools without a justification stronger than familiarity.

This question tests whether the agency designs automation around your stack or redesigns your stack around their preferred tooling. A platform migration is not an automation engagement — it is a replatforming project with automation as a feature. Know which one you are buying.

What a good answer sounds like: The agency asks which tools your team actually uses — not which tools are in your contract, but which ones reps open every day. They design automation to surface in those tools. If a tool replacement is necessary, they can name the specific capability gap that makes the current tool inadequate and the specific capability in the replacement that fills it.

Red flags: The agency proposes replacing your CRM, enrichment provider, or middleware as step one. The justification is "our preferred stack" rather than a capability gap. The agency cannot name what your current tools do well before recommending replacements.

Question 3: "Who on our team needs to be involved and for how many hours per week?"

Automation engagements fail when client-side involvement is underestimated. The agency builds workflows that make assumptions about territory definitions, scoring criteria, and pipeline stages. If nobody on your team validates those assumptions, the automation ships wrong. The agency moves on. Your team is left with a system that routes leads to the wrong people.

This question tests whether the agency is honest about client-side effort. An honest answer specifies names and hours: "We need your RevOps lead for 3 hours in week 1 to define routing rules, your sales manager for 2 hours in week 2 to validate the scoring thresholds, and one rep for 1 hour per week to test output quality."

What a good answer sounds like: The agency can name specific roles and a weekly hour commitment for each. They distinguish between input hours (defining requirements) and review hours (validating output). They specify that review hours are non-negotiable because automation decisions without client validation ship errors that are harder to fix than decisions made with input.

Red flags: The agency says "we handle everything — your team just reviews the final deliverable." The agency cannot name which specific person on your team holds the authority to approve territory definitions and scoring rules. The agency underestimates client involvement, typically describing it as "light touch" or "minimal lift."

Question 4: "What happens when a workflow breaks six months after launch?"

Every automation workflow breaks eventually. A CRM field gets renamed during a platform update. An enrichment API changes its response schema. A territory is reorganized and the routing rules no longer map to the new structure. The question is not whether the automation will break. It is whether your team can fix it or whether every fix requires a new engagement.

What a good answer sounds like: The agency describes a monitoring system that surfaces breakages before your team notices — failed enrichment calls, routing errors, trigger sequences that stopped firing. They describe a handoff where your team receives documentation that maps every automation path, every dependency, and every failure mode with remediation steps. They offer a support retainer with a defined response SLA.

Red flags: The agency describes the automation as "set and forget." They cannot name the most common failure modes for the specific workflows they are proposing. They do not have a standard monitoring and alerting module. They describe support as "just email us if something goes wrong."

Question 5: "Show me a workflow you built for a company like ours — and tell me what went wrong."

Every agency can show you case studies where everything went right. What you need to see is a case study where something went wrong and the agency describes honestly what happened and how they fixed it. An agency that cannot or will not describe a project that hit complications is either inexperienced or dishonest.

What a good answer sounds like: The agency describes a specific project: the company, the workflow, the complication, the moment they discovered it, the steps they took to fix it, and the operational change they made so it would not happen again. The story should include a detail that makes it real — a specific error message, a specific conversation, a specific timeline adjustment.

Red flags: The agency says "our projects don't go wrong" or "we have a process that prevents complications." Every automation project hits complications — API limits, data quality issues, field mapping mismatches. An agency that denies this is either too new to have encountered problems or too evasive to describe them. The agency shifts blame — "the client's data was bad" — without describing their own response to the situation.

Question 6: "What is the handoff process — specifically, who owns the workflow logic after you leave?"

This is the question that separates automation agencies from automation dependencies. If the agency builds workflows in a proprietary tool or a custom codebase your team cannot access or modify, you own the output but not the logic. Every modification requires a new statement of work. The automation becomes an ongoing cost center rather than a one-time investment.

What a good answer sounds like: The agency builds on tools your team can access and modify. If the workflow uses a middleware platform, your team has admin access. If it uses custom code, the code lives in a repository your team controls with documentation that describes every decision point. The handoff includes a walkthrough where your team modifies one workflow rule under observation — proving they can maintain the system without the agency present.

Red flags: The agency builds on a proprietary platform that only they can access. The agency describes the handoff as "a training session" rather than "your team making a modification while we watch." The documentation is described as "comprehensive documentation" without specifics about what it covers. Ownership of the logic is ambiguous in the contract language.

Question 7: "If we reduce scope by half, what ships first and what gets cut?"

This question tests whether the agency can prioritize by impact rather than by architecture dependency. Most automation engagements bundle multiple workflows into a single scope. When budget or timeline pressure forces a cut, you need to know which workflows deliver the most value independently — not which ones the agency prefers to build.

What a good answer sounds like: The agency can rank each workflow by standalone value. "Enrichment ships first because it makes every downstream workflow better — the data quality improvement compounds. Routing ships second. Trigger sequences ship third because they depend on clean data and correct routing to function properly." The ranking is based on your team's specific pain points, not on a generic template.

Red flags: The agency says "we need to build the full system for it to work" or "the workflows are interdependent." Some workflows are sequential — enrichment before routing makes sense. But enrichment should still deliver value on its own if routing does not ship. An agency that presents the full scope as indivisible is protecting their revenue, not your outcome.

The Red Flags Summary

Across all seven questions, five patterns distinguish the wrong agency from the right one before you sign:

1. Process language over task language. "We will interview stakeholders" instead of "on day 3 we will have the field mapping complete." One describes consulting. The other describes building.
2. Discovery as a paid phase. A short discovery period — 1 week or less — is reasonable. A 6-week paid discovery before any build commitment means you are buying time, not output.
3. No named person on the agency side. You should know who will build your workflows — their name, their background, and their specific experience with your CRM and enrichment stack. An agency that cannot name the person is assigning project staffing after the contract is signed.
4. Handoff as an afterthought. If the proposal describes the build in detail and the handoff in one paragraph, the agency's incentive is to keep you dependent. A good handoff takes design effort equal to the build.
5. Full-stack replacement as step one. Replacing your CRM or core tools should be the last resort, not the first recommendation. An agency that defaults to replacement is selling a platform migration, not an automation engagement.

Key Takeaways

1. Ask about the first two weeks. The agency's description of the first two weeks reveals whether they are builders or consultants. Builders describe tasks and tools. Consultants describe processes and interviews. Know which you are buying.
2. Handoff is the test. If your team cannot modify the automation after the agency leaves, you bought a dependency, not an asset. Require a handoff where your team makes a live modification under observation.
3. Require a named person. You should know who will build your workflows before you sign. Staffing assigned after contract signing is a signal the agency sells first and staffs second.
4. Beware of the "full system" pitch. An agency that cannot rank workflows by standalone value is protecting revenue, not prioritizing your outcome. Every workflow should deliver value independently.
5. Ask about what went wrong. An agency that cannot describe a project that hit complications is either inexperienced or dishonest. The story of how they recovered from a problem tells you more than every success story combined.