How to Route Demo Requests by Company Size in HubSpot

How do you route HubSpot demo requests to different reps by company size?

Store company size as a clean select property, enroll demo requests in a workflow, branch on that property, and add a Rotate record to owner action inside each branch. Small companies go to one team, mid-market to another, enterprise to a third, and anything unclassified goes to a fallback owner who sorts it by hand.

This is one of the most common routing requests I get from B2B software teams. The founder or head of sales wants enterprise demo requests in front of senior reps, and smaller accounts handled by a faster, higher-volume team. Doing it by hand works for a while, then a big lead sits unassigned over a weekend and everyone agrees it needs automating.

This tutorial walks through the setup in HubSpot, step by step, for a team that already uses HubSpot workflows and has paid sales seats. I will flag the plan requirements and the edge cases that HubSpot's own documentation calls out, because those are where routing usually breaks.

What do you need in place before you start?

You need a HubSpot subscription that includes the Rotate record to owner action, reps with the right paid seats, a demo request form, and agreed size bands with an owner team for each. HubSpot lists the action under Sales Hub and Service Hub at Professional or Enterprise. Check your account before you build.

The seat requirement is easy to miss. HubSpot's documentation says the rotate action assigns records to paid sales and service users, and that users need an active Sales Hub or Service Hub Professional or Enterprise seat. Users on core or view-only seats show up greyed out. If a rep you expect to route to is missing from the list, check their seat first.

Agree the bands with sales before touching HubSpot. A common split is small, mid-market, and enterprise, defined by employee count. The exact cutoffs matter less than everyone agreeing on them in writing, because routing rules become arguments the moment a rep feels a lead went to the wrong person.

Why should company size live in a select property instead of a number?

Because a select property gives you one clean value per band, which makes branching simple and reporting readable. A raw employee number invites messy ranges and edge cases at every boundary. Convert the number to a band once, store the band, and let the workflow branch on that single value.

Create a custom select property, something like "Company size band," with one option per band plus an "Unknown" option. HubSpot's knowledge base covers the exact steps for creating custom properties, and the screens change from time to time, so follow the current guide there. Keep the option labels short and identical to the words sales uses.

The "Unknown" option is not a throwaway. Every routing system needs a place for records it cannot classify. Without it, unclassified leads either fall through or get forced into the wrong band, and both are worse than sending them to a person who can decide.

How do you fill the company size band on each demo request?

Either ask for it on the form or derive it from enrichment, and ideally both. A required dropdown on the demo form gives you a self-reported band instantly. Enrichment from a tool like Clay, Apollo, or HubSpot's own data features can confirm or correct it. Pick one source of truth when they disagree.

My preference for most teams is a short dropdown on the form with plain ranges, mapped directly to the band property. It costs one field and gives you a usable answer on day one. If your form is already long, enrichment is the better route, so you do not add friction to the highest-intent form on your site.

When both sources exist, I let enrichment win for known companies and the form win for everything else. Whatever you choose, write the rule down. If the band can be set by three different automations, nobody will be able to explain a misroute later.

How do you build the workflow and enrollment trigger?

Create a contact-based workflow that enrolls contacts when they submit your demo request form. Keep enrollment narrow so only real demo requests enter, and exclude existing customers if they have a separate path. The workflow should do one job, routing, so it stays easy to test and easy to explain to sales.

The exact trigger options in HubSpot depend on your workflow type and account, so pick the form submission trigger that matches your demo form in the current workflow editor. If the band is set by enrichment, add a short delay or a check that the band property is known before the branch, so the record is not routed before the data arrives.

Existing customers asking for a demo of a new feature should not land in the new business queue. I covered that case in my tutorial on how to build an existing customer check for inbound demo requests. Put that check before the size branch so the routing logic stays clean.

How do you set up the company size branch?

Add a branch action and choose the "One property or action output (value equals)" type, then pick your company size band property. HubSpot describes this branch type as a way to automatically configure multiple branches based on a single property. You get one path per band, plus a None met path for records that match nothing.

If your rules are more complex, for example enterprise only when the band is large and the country is in a covered region, use the AND/OR logic branch type instead. It lets you build each path by hand with multiple conditions. I start with the simple value-equals branch and only move to AND/OR logic when sales asks for it.

HubSpot's documentation states that a record which does not meet any branch criteria follows the None met path. Treat that path as a feature. Route it to a named fallback owner, usually a sales manager or the ops lead, with a task to classify the lead by hand.

How do you add round robin inside each branch?

Inside each branch, add a Rotate record to owner action and select the team or the specific reps for that band. HubSpot lets you choose the user property to set, whether to overwrite an existing owner, and whether to rotate between specific users or a team. By default, records are spread evenly across the selection.

I usually rotate between a HubSpot team rather than named users. When a rep joins or leaves, you update the team once and every workflow that uses it stays correct. Rotating between named users works, but it means editing workflows every time the sales roster changes.

The overwrite setting deserves a real decision. If a contact already has an owner, for example from a previous conversation, overwriting can take a relationship away from a rep. For demo requests, I usually do not overwrite, and I add a separate notification to the existing owner instead. If you also route by region, my round robin routing by territory tutorial for HubSpot shows how to layer the two.

What edge cases break company size routing?

The big three are changed data, missing data, and seat changes. HubSpot's documentation says a record whose details change after the branch is not automatically rerouted, so a corrected band will not move the lead. Missing bands go to None met. Reps without a qualifying paid seat cannot receive rotated records.

Changed data is the sneaky one. If enrichment updates a contact from mid-market to enterprise an hour after routing, the lead stays with the original rep. Moving it would take a deliberate second pass through the workflow. Decide whether you want that, and if you do, build a separate, deliberate re-routing step rather than letting it happen by accident.

Seat changes break routing quietly. A rep moves to a core seat or leaves the company, and suddenly their share of leads goes nowhere useful. A monthly check of the rotation team against your active sales roster takes two minutes and prevents most of this.

How do you test the routing before turning it on?

Create a small set of test contacts, one per band plus one with no band, and run them through the workflow before it touches real leads. Confirm each lands with the right team, the None met record reaches the fallback owner, and no existing owner is overwritten. Then turn the workflow on and watch the first week.

Use clearly fake but realistic test records, and delete or archive them afterwards so they do not pollute reports. I keep a reusable set for every client CRM, and I explained how in how to build a test contact set for CRM automation QA.

During the first week, check every routed demo request against the band and the owner it received. It is tedious, but it is the only way to catch a mapping error before sales does. Once a week of real leads routes correctly, move to a weekly spot check.

What should you do next?

Agree the bands and owner teams with sales, create the band property with an Unknown option, decide how it gets filled, then build the workflow with a value-equals branch and a rotate action per band. Test with fake contacts, route None met to a named person, and review the first week by hand.

I build lead routing and CRM automations for B2B teams, including HubSpot work for clients like Kismet Health, where HubSpot connects to other tools through Zapier. The pattern that holds up best is always the same: clean data first, simple branches second, and a human fallback for anything the rules cannot decide.

If you want help designing routing rules your sales team will actually trust, or a second look at a HubSpot workflow that keeps misrouting leads, reach out through pravinkumar.co. Let's chat.