TL;DR:
Use a small set of tags with one-line definitions, and apply one main tag per ticket.
Count tickets per tag each month and divide by the month's total to see what is growing.
Review the tag list every quarter: merge tags that overlap and split any that grows too big.
At the end of the month someone asks, "What are customers writing to us about?" If your tags are billing, Billing, bill, payments and money, the answer is a shrug. Tags only pay off in reports when they are few, clearly defined and applied the same way by everyone.
When tagging is worth the effort
Tag once you have more than a few dozen tickets a month and someone, whether product, billing or you, would act on the counts. If nobody will read a report, a long tag list is wasted work.
What to set up
A single shared list of tags, in a document everyone can see.
A one-line definition for each tag, plus an example.
A rule: one main tag per ticket, chosen by the customer's main need.
A spreadsheet for monthly counts.
Step by step
Read last month's tickets and group them by hand: Skim 30 to 50 and note the natural topics. Start from reality, not from a template.
Cut the list to between five and ten tags: Merge near-duplicates. Add "other" for the leftovers and keep it small.
Write a definition and an example for each: The definition decides edge cases in advance.
Tag every ticket with one main tag: Choose by what the customer wants fixed or answered, not by which feature is mentioned.
Count monthly and compare to the total: Counts tell you volume; shares tell you mix.
Read the counts with a question in mind: Which tag grew? Which one could a help article or a product fix remove?
Worked example: a tag list for a product team
The product and numbers are invented. A small product has six tags, each with a definition:
Tag | Definition |
|---|---|
billing | Charges, invoices, refunds, plan changes |
login | Cannot sign in, password, account access |
checkout-bug | Ordering or payment flow does not work as intended |
feature-request | Asking for something that does not exist yet |
how-to | Asking how to do something that does exist |
other | Anything that fits none of the above |
In a month with 120 tickets, the counts are:
Tag | Tickets | Share of total |
|---|---|---|
billing | 30 | 30 ÷ 120 = 25% |
login | 24 | 24 ÷ 120 = 20% |
checkout-bug | 18 | 18 ÷ 120 = 15% |
feature-request | 22 | 22 ÷ 120 = 18.3% |
how-to | 20 | 20 ÷ 120 = 16.7% |
other | 6 | 6 ÷ 120 = 5% |
Check that it adds up. Tickets: 30 + 24 + 18 + 22 + 20 + 6 = 120. Shares: 25 + 20 + 15 + 18.3 + 16.7 + 5 = 100. In a spreadsheet with tags in A2:A7 and counts in B2:B7, a share column and a total look like this:
B8: =SUM(B2:B7) (total, returns 120)
C2: =B2/B$8 (share for billing, returns 0.25)
C2:C7 formatted as percent (fill C2 down to C7)And if the ticket list has one tag per row in column D (rows 2 to 121), you can get each count with =COUNTIF(D$2:D$121,A2) rather than counting by eye.
What do these numbers tell the product team? Billing is the biggest topic at 30 of 120, so reading those tickets is the best first step. Login at 24 may be removed with a clearer reset page. The 6 other tickets are small enough to read in full each month. Finally, compare next month's counts. Two months of data show a change; one month only shows a level.
Notice the rule that settled a likely argument: a customer who cannot pay because the page spins is tagged checkout-bug, because the main need is that the flow is broken, not billing. The definition handles the edge case ahead of time.
Agree on one more thing before you start: who may add a tag. If anyone can, the list drifts within weeks. A simple rule works, such as proposing changes in the shared document and updating the list once a quarter.
When you share the report, write one sentence next to each number saying what you think it means and what you will do. A table of counts without a sentence is easy to ignore; a table with "billing is the largest group, so I will read those 30 tickets this week" gets acted on.
Mistakes to avoid
Too many tags. Past ten, people stop choosing carefully and counts become unreliable.
No definitions. Without them two people tag the same ticket differently.
Multiple tags that double count. If you must use two, report the main tag only, or the totals will exceed the ticket count.
A huge "other". If it keeps growing, read its tickets and add a tag for the pattern you find.
Retagging history every month. Change the list on a schedule, such as quarterly, and note when you changed it so comparisons stay honest.
Doing it faster
Make tagging part of the first pass through the inbox rather than a separate chore, so each ticket is read once. A small monthly sheet with the COUNTIF formula above builds the report in minutes. If you want to ask questions about a chart while looking at it, DuckyHelper sees your screen and answers out loud, but the interpretation is for you and your team.
Frequently asked questions
Should customers be able to see the tags?
Usually these are internal labels. Keep them for your own reports and use clear wording in anything customers read.
What if a ticket has two problems?
Tag its main need, or split it into two tickets if your tool allows. Do not tag it twice and count it twice.
Get started
