What ticket routing means here
Routing is the step after a ticket lands: deciding who should own it, how fast it needs a response, and whether anyone besides the assigned rep needs to know about it right away.
HubSpot already has the mechanism for this: ticket-based workflows in Automation, which enroll tickets that match a set of criteria and then run a sequence of actions.
What is usually missing is not the automation tool, it is a reliable signal to route on. Rule-based routing on subject-line keywords catches the phrasing you thought of and misses everything else.
The signal has to exist as a property first
A workflow can only enroll and branch on something HubSpot can see, which means sentiment, category, and priority need to exist as ticket properties before any routing logic can use them.
This is why routing depends on the categorization and sentiment steps covered elsewhere: an AI app reads the ticket’s subject and description and writes these values back as custom ticket properties (or updates native ones like priority, where your process already relies on it), the same way any other property gets set.
Once they are properties, HubSpot does not treat them differently from anything else on the ticket. That is the entire point: no separate routing tool, no second system to keep in sync.
Building the workflow
In Automation, create a ticket-based workflow with an enrollment trigger of “ticket property is known” or “ticket property changed” for the sentiment, category, or priority property, depending on what you are routing on.
From there, branching (if/then logic) can split tickets by category into different owners or teams, and a second branch can check sentiment to escalate a negative ticket regardless of which category it fell into.
Typical actions once a ticket matches: assign to a specific owner or team, set or change the priority property, create a task for a manager to review, or send an internal notification (email or a connected Slack channel) so a negative, high-value ticket does not sit in a general queue unnoticed.
A realistic example
A billing ticket that scores negative on sentiment is a different problem than a billing ticket that scores neutral. Both get the “billing” category, but only one needs a manager to look at it before the standard queue gets to it.
A workflow that branches on category first, then checks sentiment inside the billing branch, can route the negative one to a senior rep or a manager while the neutral one goes to the standard billing queue. Neither ticket needed a human to make that first split-second decision.
What routing on AI-generated properties will not fix
Routing logic is only as good as the property values feeding it, so a ticket with almost no description will produce a low-confidence category and sentiment score, and routing on top of a weak signal just moves the ambiguity downstream faster.
Workflows do not undo bad enrollment criteria. If a workflow’s trigger is too broad, it will enroll tickets you did not intend to route that way, so it is worth testing a new routing workflow on a small pipeline or with a delay step before turning it loose on your main queue.
This does not replace escalation paths you already trust for genuinely urgent issues, such as outage reports; those should keep their existing fast path and simply also carry the AI-generated properties for reporting afterward.
Rolling it out
Start with one routing rule, most teams begin with “negative sentiment gets flagged to a manager”, confirm it fires correctly on real tickets for a week, and only then add category-based and priority-based branches on top.