Route on skill and ownership, not on who happens to be free

List what makes tickets different in your business. Typical candidates are the product area, the customer tier, the language and the complexity. Choose the two or three that change who should answer. More than three makes the rules hard to maintain.

Skip anything that does not change the answer. If every agent can handle every language, do not route on language.

Open a sheet and write one row per ticket type, with columns for the trigger, the owner or pool, a backup and the target first reply time. For example:

• Billing question: goes to the billing owner, backup is the account manager.
• Technical fault, any customer: goes to the technical pool, backup is the team lead.
• Enterprise account, any topic: goes to the named account owner first.

If two rules could match, decide the order. Named account ownership usually beats topic, and topic beats the general pool.

Where several people can do the same work, create a pool or team and route to the pool. Round-robin inside a qualified pool is fine. Round-robin across everybody is not, because it sends a billing question to someone who has never seen the billing system.

Pools also survive holidays and leavers. You change a membership list rather than rewriting rules.

In HubSpot you can set ticket routing with workflows that assign the ticket owner when a ticket is created, based on properties such as category or company owner. Check which assignment options your plan includes before you plan the design. Other tools, such as Zendesk, Freshdesk by Freshworks and Help Scout, offer comparable rules and team assignment.

Start with the stages and categories from Set up ticket pipelines and routing, then add the ownership logic described here.

An agent holding fifteen open tickets should not receive the sixteenth because it is their turn. Set a cap on open tickets per person. Start at a number your team agrees feels fair, say ten, and tune it after two weeks.

When the pool is full, route to an overflow person or leave the ticket in a visible queue for the team lead. Never let it silently pile up on one person.

Once a ticket has an owner, leave it with that person. A customer in the middle of a conversation should not be passed to someone who has to read the whole thread again. Build a rule that assigns once and then holds.

Allow reassignment only for defined cases: the owner is absent, the ticket needs escalation, or the topic has changed. A reason in the ticket makes the handoff clean.

Tell the tool when people are away. If your system has an availability or out-of-office setting, use it, and pair each owner with a backup in the routing table. A ticket sent to someone on leave is worse than a slow queue.

Take the last thirty tickets and run them through the table by hand. Count how many land on the owner you would have chosen. If fewer than 26 of 30 match, the rules are wrong or the table has a gap. Fix those before switching them on for live tickets.

• Routing by availability. The person who is free is not always the person who can answer.
• Too many rules. If nobody can explain the rule order in a minute, simplify it.
• No backup owner. Holidays will expose this within a month.
• Reshuffling tickets. Each reassignment resets the customer's patience.
• Ignoring the account owner. Customers with an owner expect to speak to that person.

No ticket sits unassigned during working hours. Fewer than one ticket in ten is reassigned after the first assignment. Repeat contacts from the same customer land with the same person. Ask your team once a month which tickets felt wrongly routed, and adjust the table with their answers.

Over time the first reply becomes more useful, because the right person is writing it. Satisfaction scores for each pool, covered in Measure resolution and satisfaction, not the vanity metrics that reward the wrong behaviour, should rise first where routing was weakest.