HubSpot Ticket Routing

HubSpot ticket routing gets the right ticket to the right person through three mechanisms that overlap, and one limitation that shapes everything.

HubSpot ticket routing: three mechanisms, one queue

Routing in HubSpot isn't one feature. It's three, and they run in a rough order.

Channel routing. Set on the connected inbox or chat channel. Everything from this address goes to this team, optionally rotated between its members. Runs first, at the moment the conversation arrives.
Workflow assignment. A ticket-based workflow reads properties and sets the owner. This is where topic, product, language and account-tier routing belong. Runs after creation, once the properties exist.
Manual pickup. Someone works the unassigned view. Not a fallback to be embarrassed about, it's the correct handler for anything your rules did not anticipate.

Design them as a chain rather than as competitors. Channel routing gets a name on every ticket immediately so nothing is orphaned. Workflows then correct that name based on what the ticket turns out to be about. Humans clean up the rest.

Round robin and what it ignores

HubSpot can rotate ownership between the members of a team, both on channels and through a workflow action that rotates the record owner. It's available on paid seats, it's easy to set up, and it does exactly one thing: it shares tickets out evenly by count.

Which is the limitation. Counting isn't the same as balancing.

It doesn't know that Sam already has eleven open tickets and Alex has three.
It doesn't know that the last three tickets Sam received were complex escalations and the last three Alex received were password resets.
It doesn't know that someone is on a two hour call.

Availability status helps on the conversations side, where you can restrict assignment to users marked available, and that solves the holiday problem rather than the workload problem. If you need capacity-aware distribution, where a rule reads how much open work someone is carrying before it assigns more, HubSpot doesn't have it and you'll be approximating with team size and manual rebalancing.

Skill-based routing

Skill-based routing arrived alongside the help desk workspace and sits on the higher tiers. The idea is straightforward: tag agents with skills such as language, product or tier, tag the ticket with what it needs, and route to someone who has the skill.

It works, and it's deliberately simple compared to a specialist helpdesk. Treat it as a filter on who is eligible rather than as a full proficiency model with weights, fallbacks and overflow rules. Confirm tier availability before you promise it to anyone, because this is one of the features most likely to be shown in a demo on a tier above the one you're quoted.

It also depends entirely on the ticket knowing what skill it needs, at creation. Which puts you straight back to ticket properties set by the form or the channel, rather than by an agent during triage.

The rules worth building first

Four rules cover most of what routing is for. Build these before anything clever.

Route by topic to a team, not a person. People take holidays. Teams don't.
Escalate on silence. No first reply within your target, notify the team channel. This catches the ticket that was routed perfectly to someone who never opened it.
Route by account value where it matters. A ticket from a customer with a renewal inside ninety days can go to the account owner. This is the rule only a CRM-native helpdesk makes easy, and it's the best argument for running support inside HubSpot.
Catch the unroutable. Anything that matched no rule lands in one named view that a real person checks twice a day. Every routing system needs a floor.

Limits to design around

Say these out loud during planning and you avoid three months of confusion.

Workflows read one record at a time. No rule can consider the state of the rest of the queue, so nothing routes based on queue depth, and nothing can notice that this ticket is a copy of an open one.
Timing isn't instant. Workflow enrolment happens shortly after creation, not in the same instant, so an agent watching the unassigned view may see a ticket briefly before the rule catches it.
Round robin is blind to workload. Covered above, and worth repeating because it's the assumption teams most often get wrong.
Reassignment is manual. If the first routing decision was wrong, a human fixes it. There is no automatic reroute on a stalled ticket unless you build the notification and someone acts on it.
FAQ

Frequently asked questions

Does HubSpot do skill based routing?

HubSpot skill based routing exists on the higher tiers and matches tickets to owners by skill rather than availability alone. To assign tickets in HubSpot at lower tiers you use round robin in workflows or the inbox routing rules.

Does HubSpot support round robin ticket assignment?

Yes, on paid seats, both on connected channels and through a workflow action that rotates the record owner. It distributes by count, not by current workload.

Can HubSpot route tickets by skill?

On the higher tiers, yes, using skills attached to users and to tickets. It's a simpler model than a dedicated helpdesk offers, so check your tier and test it.

Why are my routing workflows not firing?

Usually because the property the rule reads is empty at creation. If a human fills the field during triage, the rule has already run and found nothing.

Should tickets be routed to a person or a team?

A team, then a person. Team-first routing survives holidays, sickness and staff changes without anyone editing a workflow.

Routing the same ticket twice

When one problem arrives as two tickets, good routing sends both to different people. Ticket Merger stops that on Zendesk and Freshdesk today, and HubSpot support is on the way.

Start free trial

14-day free trial. No credit card required.