How Do You Write Acceptance Tests for a Lead Routing Automation?

How do you write acceptance tests for a lead routing automation?

Write a table of example leads, each with the exact owner and next action sales expects, and get sales to sign it before you build. Each row is one test: given this lead, the automation must do this. Run every row before launch and again after every change. If a row fails, the automation is not done.

Lead routing is one of the most common automations in a B2B stack, and one of the most fragile. It sits between marketing and sales, it touches HubSpot or Salesforce properties that other people edit, and when it breaks, the cost is a buyer who never hears back. Yet most routing builds go live after someone submits a test form and sees it land somewhere plausible.

Acceptance tests fix that. This is how I write them, how I get sales to agree to them, and how they keep routing honest after launch.

What is an acceptance test in automation work?

An acceptance test is a written example that defines correct behavior from the business's point of view. For routing, it says: a lead with these field values should end up with this owner, this lifecycle stage, and this notification. It is not about how the automation works inside. It is about what sales needs to see.

The phrase comes from software development, where acceptance criteria describe what a feature must do before it counts as finished. The same idea works beautifully for automations, because routing logic is really a set of business rules. Writing those rules as concrete examples forces everyone to agree on what the rules actually are.

This is different from testing with fake data in general. Sending a handful of fake leads through a workflow, which I covered in how to test a Make scenario with fake leads, checks that the plumbing works. Acceptance tests define the expected answer for each case in advance, so you can say pass or fail without debating it.

Why does lead routing need written acceptance tests?

Because routing rules live in people's heads until someone writes them down. Sales leaders, SDR managers, and marketing ops often hold slightly different versions of the rules. The automation can only follow one version. Acceptance tests surface the disagreements before launch, when they are cheap, instead of after a missed deal.

The same conversation tends to play out in planning sessions. Someone says "enterprise leads go to Sam." Then someone asks what counts as enterprise, and three people give three answers: employee count, revenue, or whether the company is on a target account list. Without a test table, that ambiguity goes straight into the build.

Written tests also protect the builder. When a lead lands with the wrong owner six months later, you can check it against the signed table. If the table said that lead should go to Sam and it did, the rule needs changing, not the automation. That changes the conversation from blame to decisions.

What should each test case include?

Each row needs the input fields that matter for routing, the expected owner, the expected lifecycle stage or status, the expected notification, and a short note on why. Inputs are things like country, company size, source, and existing account owner. Expected outputs are what sales would check in the CRM afterward.

I build the table in a shared Google Sheet or Airtable base. Columns on the left hold inputs: country, employees, industry, lead source, whether the company already exists in the CRM, and who owns it. Columns on the right hold expected results: assigned owner, stage, Slack channel or email alert, and any task created. A final column records pass or fail for each test run.

The "why" column is easy to skip and worth keeping. "Existing customer, so route to account manager, not SDR" explains the rule in one line. When someone wants to change routing later, the reasons are right there, and they can see which other rows might be affected.

Which cases should the test table cover?

Cover the common path, every boundary, every exception, and the bad data cases. Common path means a typical lead for each segment. Boundaries are values right at the edge of a rule. Exceptions are existing customers, open deals, and named accounts. Bad data means missing fields, odd spellings, and duplicates.

Boundaries catch the most bugs. If enterprise means 1,000 employees or more, test 999, 1,000, and 1,001. If territories split by country, test a country that sits in no territory at all. If a lead source field drives routing, test a source value someone added last week that nobody told the automation about.

Bad data cases matter because real forms produce them constantly. Test a lead with no company size, a country typed as "U.S.A.", a personal email domain, and a contact who already exists under a different email. Decide with sales what should happen in each case, usually a fallback owner and a flag for review, and write it in the table.

How do you get sales to agree on the tests?

Walk through the table with the sales leader in one meeting, row by row, and ask them to confirm or correct each expected result. Do not send it as a document to review later. Live walkthroughs surface disagreements fast, and the sales leader's sign off becomes the definition of done for the build.

I bring the table half filled. The common cases are filled in based on what I learned in discovery, and the tricky cases are left blank with a question. People are usually quicker to correct a wrong answer than to invent rules from scratch, so giving a sales leader something to react to saves time.

When the meeting ends, the table is the spec. If someone wants a rule changed later, the change starts with a new or edited row in the table, signed off the same way. That keeps the table and the automation in sync, which is the whole point.

How do you run the tests before launch?

Create a test lead for each row, push it through the real automation in a sandbox or with a clear test flag, and record the actual result next to the expected one. Every row must pass before launch. Then delete or archive the test records so they never pollute reporting.

A sandbox is ideal if your CRM plan includes one, but many smaller teams do not have that option. In that case, I use a test flag property and a fake email domain the team agrees on, and I make sure reports and other automations exclude records with that flag. Check your CRM's docs for sandbox availability on your plan before you plan the test run around it.

For routing that includes an AI step, such as classifying free text intent, the acceptance tests still apply, but you need more examples per case because the output can vary. I described that extra layer in how to test an AI classification step before it routes leads.

How do acceptance tests help after launch?

They become your regression suite. Every time someone edits a routing rule, adds a territory, renames a property, or changes a form, you rerun the table. If an old row now fails, you caught a side effect before buyers did. The table turns every change into a quick, repeatable check.

A lot of routing breakage comes from changes outside the automation itself. A marketer adds a new value to the lead source dropdown. Sales ops renames a property. A new rep joins and an old one leaves. None of these touch the workflow directly, but all of them can change where leads land. Rerunning the table after each change catches them.

I schedule a full rerun every quarter even when nothing has changed, because something always has. It takes less than an hour with a well built table, and it is the cheapest insurance I know for an automation that touches every inbound lead.

What should you do next?

Open a sheet and write ten example leads with the owner and next action you expect for each. Include at least two boundary cases and two bad data cases. Walk through the table with your sales leader, fix any rows they disagree with, and run every row through your current routing.

My view is that a routing automation without acceptance tests is a guess that happens to be running in production. The table takes an afternoon to write, and it turns arguments about routing into quick, factual checks.

If you want help writing the test table, rebuilding routing so it passes, or setting up a regular regression check, reach out. Let's chat about where your leads should go and how to prove they get there.