HubSpot Ticket Tags

If you came from Zendesk looking for HubSpot ticket tags, you won't find them. HubSpot categorises tickets with properties, a better model with sharper edges.

HubSpot ticket tags: the honest answer first

HubSpot does not have a free-form tag field on tickets the way Zendesk does. There's no box where an agent types three words and they become searchable labels.

What you get instead is properties: structured fields with defined types and, for dropdowns, a fixed list of options. You categorise a ticket by setting a dropdown, not by adding a tag.

That difference is worth understanding rather than resenting. Free-form tags are fast to add and terrible to report on, because within a quarter you have "billing", "Billing", "billing-issue" and "bill" all meaning the same thing. Properties force the vocabulary decision up front, which is annoying on day one and correct by month six.

The property set that does the tagging job

Most teams need three, and I would push back hard on a fourth.

Category or topic. One dropdown, ten to fifteen options, required before close. This single property answers "what are we spending our time on", which is the question every support review opens with.
Resolution or outcome. Fixed, explained, escalated, no fault found, refunded, duplicate. Tells you what kind of work you did, not just how much.
Product area. Only if you genuinely have more than one product, and then keep it coarse.

A multi-checkbox property can approximate multi-tagging where a ticket honestly belongs to two categories. Use it knowingly, because multi-value fields count strangely in reports and someone will build a chart whose totals don't add up.

Designing the option list

This is the part that decides whether any of it works, and it takes an afternoon rather than a project.

Pull the list from real tickets. Read two hundred closed tickets, group them into piles, name the piles. Do not write the list in a meeting.
Ten to fifteen options. Below ten you learn nothing. Above twenty agents pick the first plausible one and your data becomes noise.
Name for the customer's problem, not the internal team. "Cannot log in" beats "Auth platform", because the agent knows what the customer said and may not know which team owns it.
One "other" bucket, and watch it. If other exceeds roughly fifteen percent of tickets, your list is wrong and the tickets in it are telling you the missing categories.
Mutually exclusive where you can. If agents have to think about which of two options applies, half will pick each one.

Discipline, or the whole thing is decorative

Categorisation fails for social reasons, not technical ones. The field exists, agents skip it, and a year later somebody asks for a report that can't be built.

Require it at close, not at create. Requiring it on arrival slows the queue and produces guesses, because nobody knows what a ticket is about in the first thirty seconds. Requiring it at close produces data, because by then the answer is known.
Set it automatically where you can. A form dropdown, a channel, a product context. The best categorisation is the kind nobody has to remember.
Show the team the report monthly. People fill in fields they see used. Nothing kills compliance faster than data that visibly goes nowhere.
Never let agents add options ad hoc. One owner of the list, reviewed quarterly. This is the entire difference between usable data and a mess.
A category field that's 60% complete is worse than none, because someone will build a strategy on the 60% without knowing which 40% is missing.

What good categorisation buys you

Three concrete things, all of which pay for the discipline.

Your knowledge base roadmap, ordered by volume rather than opinion. Your automation targets, because you can see which categories are large and repetitive enough to be worth a rule. And an honest input to headcount conversations, because "billing questions are 22% of our volume and rising" is an argument, while "we feel busy" is not.

It also surfaces duplicates, incidentally. A category that spikes for a day is usually one incident arriving as many tickets, and that pattern is invisible without the field.

FAQ

Frequently asked questions

How should you handle ticket categories without tags?

With a single-select property. HubSpot ticket tagging done as a free-text field becomes unreportable within a month, so HubSpot ticket categories belong in a controlled option list.

Does HubSpot have ticket tags?

Not as free-form tags. Tickets are categorised with properties, typically a dropdown for category and another for resolution. A multi-checkbox property is the closest equivalent to multi-tagging.

How many ticket categories should we have?

Ten to fifteen. Fewer teaches you nothing, more and agents pick whichever option they see first, which quietly ruins the data.

Should the category field be required?

Required at close, not at create. Nobody knows what a ticket is really about in the first minute, and forcing the choice then produces guesses.

Can we import tags from Zendesk into HubSpot?

You can import them into a property, but don't import them raw. Map the tags you actually use onto a designed option list first, or you'll recreate years of tag sprawl on day one.

The category that spikes for a day

When one incident arrives as forty tickets, categorisation shows it and doesn't fix it. Ticket Merger merges the copies automatically on Zendesk and Freshdesk today, and HubSpot support is on the roadmap.

Start free trial

14-day free trial. No credit card required.