Tagging conversations and tickets: how to build categories that last a year

Almost every tag set begins in the same way: with good intentions and an empty list. Somebody adds ‘complaint’, somebody else adds ‘return’, and a month later the list has ‘returns’, ‘urgent’, ‘check’ and ‘Smith’. After a year it contains fifty entries, ten of which account for most uses, while the rest exist only to make people scroll through a dropdown when closing a case. The tool is not the problem—the problem is that nobody decided why the list was created in the first place.

Why tag at all? One question your tags should answer

Tags are not there to describe a conversation. They are there to quantify something about which you want to make a decision. That distinction may sound minor, but it is the entire difference between a set that still works after a year and one that must be rebuilt.

Before adding the first tag, complete this sentence: we want to know how many conversations concern…—and choose one thing. Three options are usually useful: what the case concerns, what caused it on your side, or which product or service it concerns. Each informs a different decision, so each deserves a separate set rather than being thrown into one bucket.

• A tag that changes nothingIf you cannot say which decision you would make after seeing a hundred such conversations, the tag is decoration.
• A tag that duplicates a status‘In progress’ and ‘waiting for customer’ are case states, not categories. That information already exists.
• A tag that describes a mood‘Difficult customer’ says more about the operator’s day than about anything you can usefully count.
• A tag that is somebody’s surnameAssignment already tells you who handled the case. Duplicating it with a tag muddies the report.

Separate tagging from case management from the start. A case number, status and thread owner answer ‘what is happening with this case now?’, while tags answer ‘what are our cases about over the course of a month?’. We describe the first layer in the guide to customer service ticketing systems. If you do not have that layer, tags will be used to patch a hole they were not designed to fill.

How many tags are enough, and why less is more

The practical limit comes not from the system’s capacity but from the operator’s memory. If the list fits on one screen and can be scanned at a glance, the choice is deliberate. If it requires scrolling or searching, the choice becomes random: a person clicks the first tag that looks close enough and returns to the conversation.

That is why you design the set from the top down, not the bottom up. Instead of adding a tag whenever a new case appears, list the dozen or so most common cases from the past month and ask how many buckets they fit into. There are usually fewer than the team expected, and an ‘other’ bucket stops being embarrassing—it becomes a signal that something new may be ready for a category of its own.

• A set contains only as many tags as an operator can scan without scrolling.
• Create a new tag only when ‘other’ contains a recurring case, not after the first occurrence.
• Every tag has a one-sentence description explaining when to use it—and when not to.
• One person is responsible for adding tags, even if the whole team submits suggestions.
• A tag unused for a full quarter is a candidate for removal, not a permanent part of the list.
• The ‘other’ bucket exists deliberately and is reviewed rather than treated as a failure.

There is no universally correct number of tags—it depends on the variety of cases you handle. The only reliable test is the usage count in your own account after several weeks: if half the tags have only one use, the set is too large regardless of the total number of entries.

One dimension or several: topic, cause and product

The most common taxonomy mistake is not having too many tags, but putting three different classification systems into one flat list. ‘Return’, ‘missing delivery information’ and ‘winter boots’ can all apply to the same conversation, but they answer three different questions: what the case is about, what caused it and which product it concerns.

The consequences become visible only in reports. When dimensions are mixed, percentages no longer add up meaningfully: one conversation gets three tags from three systems and another gets one, while the summary suggests that topics overlap even though the tags measure different things. Nobody trusts such a chart, and after two presentations nobody shows it again.

↔ Scroll the table sideways to see all columns.

The final row is a trap of its own. The conversation already records the channel, time, device and status, so a tag merely duplicates the data and corrupts the statistics. Use tags only for information the system cannot know by itself.

If your tool has one shared tag list, you can separate dimensions with simple measures: a prefix in the name and one colour for each family. ‘topic: product return’, ‘cause: missing delivery information’, ‘product: annual subscription’—the names sort themselves, the colour tells the operator which pool they are choosing from, and reports can be filtered by prefix with no additional configuration.

You do not need to introduce every dimension immediately. Start with case topics because they answer the most questions, and add causes only when the team begins asking why a given topic keeps returning. A product dimension is useful mainly when the offer is broad and differences between products genuinely change how the case is handled.

Who tags, when they do it and how to make choices consistent

Tagging during a conversation is tempting because the context is fresh, but it has a drawback: halfway through, you often do not yet know what the case is really about. A question about an invoice turns out to be a complaint, while a request for a quote is merely a question about a specification. A tag added too early remains in the data forever because nobody returns to correct closed cases.

Closing the case should therefore be the default moment for tagging. Reserve tagging during a conversation for operational cases—tags that need to trigger a specific action before the conversation ends. Two purposes, two moments, no conflict.

1. During the conversation.Operational tags only: those that route the case or trigger an automation.
2. When closing.Classify the full topic and cause once you know what the case really concerned.
3. One tag per dimension.Use one topic and one cause by default. Three tags from the same pool signal overlapping categories.
4. A description instead of intuition.Every tag has a sentence beginning ‘use when…’. It settles disputes instead of relying on the longest-serving person’s memory.
5. Calibrate every quarter.Have several people tag the same twenty closed conversations. Differences reveal which names are unclear.

Calibration sounds like an unnecessary ritual until you see the result. Usually, two people disagree not across thirty tags but on two or three whose names are too broad. Fixing those few names achieves more than any manual and works better than adding more paragraphs to an internal policy.

Maintenance: reviewing, merging and removing dead tags

A tag set behaves like any configuration: it grows by itself and shrinks only when somebody has scheduled the work. Quarterly is a good rhythm—rare enough not to become a burden and frequent enough to stop the list from becoming bloated.

• A tag used once a quarter disappears or is absorbed into a broader category.
• Always merge two tags that describe the same thing—never leave both ‘for now’.
• Tell the team when a name changes, because a silent change disrupts data more than the old name.
• Tags used by automations say so in their description, preventing accidental deletion.
• Before deleting a tag, check that it is not the only trace of something you still want to measure.
• After the review, record what changed and why in one sentence.

The fourth point deserves special attention because it is the most common cause of a silent failure. A tag can be more than a label; it can also be a trigger. An automation may react when the tag is added or removed, and it may add or remove tags itself. Deleting such a tag looks harmless but disables a rule nobody remembers. We cover how to design these rules in the article about live chat automation.

What to do with the data: from report to improvement list

A tag report changes nothing by itself. What makes it useful is the question you ask at the end: which of these cases should never have reached us? Tags measure the work you performed; the most interesting part is the work you could have avoided. In an online shop, contacts per 100 orders broken down by reason show that avoidable work clearly.

1. Take the three most common topics.Not the whole list. Choose the three entries responsible for the largest share of the month’s conversations.
2. Ask about the cause.For each one, find the cause that recurs most often. This is where the second dimension helps.
3. Assign the improvement to a location.The website, offer, message copy or process. Every recurring topic has somewhere it can be fixed.
4. Check again after a month.Run the same report using the same tag set. A fall in the share is the only reliable confirmation.

The outcome can be very concrete. A recurring question about delivery time usually means one piece of information is missing from a visible location—a candidate for a website knowledge base and FAQ or a content change. Repeated questions about dimensions, materials or compatibility indicate that these details are missing from the online shop product page. That is when tags stop being an archive and become a task list.

One final note about expectations. A manually maintained tag set will not achieve perfect accuracy, and it does not need to. It is enough for the set to distinguish between the things you make decisions about and for two people to categorise the same case consistently. The taxonomy that lasts a year is not the most detailed one; it is the one somebody cleans up regularly.