What Is a Contact Reason Taxonomy, and How Do You Build One?
A contact reason taxonomy is the written list of why customers contact support, in two levels, with rules for borderline cases. Here is an ecommerce example and what happened when we tested it on 100 public complaints.
A contact reason taxonomy is the fixed, written list of reasons customers contact support, usually in two levels (a few groups, each with specific reasons), where every reason has a definition, an example and a "not this one when" line. Its job is to make every ticket, chat, email and call get the same label whoever or whatever applies it, so counts from this month compare with last month. If you want one list applied the same way across every channel, with the counts sent to the teams that own each reason, Dimension Labs runs the taxonomy as a custom Dimension on every interaction and builds the reports from it.
Below: what goes in a taxonomy and what stays out, an example list for an ecommerce company, how that list held up on 100 real public complaints, and how to build and maintain your own.
What is a contact reason taxonomy for customer support?
It answers one question per contact: what did the customer need from us? Everything else you want to know about a contact is a separate field. Keeping them apart is most of the design work:
Contact reason: what the customer needed. "My refund has not arrived." Read from the text.
Product or area: what it was about. Read from the text, or from an order line if you have it.
Outcome: how the contact ended (resolved, waiting, transferred, promised a callback). Read from the text; it is what predicts a second contact, as finding repeat-contact drivers shows.
Handling: how the customer felt they were treated. A complaint about a rude agent is usually a complaint about something else first.
Channel, plan, region: from the source systems. Never guess these from the text.
When one list tries to hold two of these ("Billing, angry customer", "Refund via chat"), the counts stop adding up. A reason taxonomy with ten to twenty-five well-defined reasons, plus separate fields for the rest, answers more questions than a list of two hundred tags.
Example: support ticket categories for an ecommerce company
Here is a starting list for an online retailer that ships physical goods and sells repeat deliveries. The "not this one when" column carries the rules that stop the same contact landing in two places.
Example taxonomy
Support contact reasons for an online retailer, in two levels
Six groups and eleven reasons, plus Other and a no-request value, each with a definition and a line that settles the borderline cases. Add reasons specific to your business on top.
| Reason | Use it when the customer needs | Not this one when |
|---|---|---|
| Late, missing or misdelivered order Order and delivery | An order that has not arrived, is late, or went to the wrong address | It arrived but was damaged (next row) |
| Arrived damaged or opened Order and delivery | Help with items broken, leaking or opened in transit | The product itself is faulty (Product) |
| Wrong or missing item Order and delivery | A different item than ordered, or an item left out of the box | The listing showed something different (Product) |
| Change, cancel or release an order Order and delivery | To change, cancel or unblock an order before it ships | They want money back after delivery (Returns) |
| Return, refund or replacement Returns and refunds | A return label, a refund that has not arrived, or a promised replacement | They were charged and never ordered (Billing) |
| Unexpected or wrong charge Billing and promotions | A double charge, a charge after cancelling, or a fee they did not expect | A discount was not applied (next row) |
| Promotion, price or gift card Billing and promotions | A code, promised credit, gift card or advertised price honoured | The charge itself is wrong (row above) |
| Repeat order change or cancellation Subscription | To skip, move, change or stop a repeat delivery | A one-off order (Order and delivery) |
| Account access, locked or closed Account | To log in, unlock or reopen an account | They only want to update an address (Order) |
| Quality, safety or description Product | To report a defect, a safety worry, or an item unlike its listing | Damage happened in transit (Order) |
| Question before buying Product | Product details, stock, or whether it ships to them | They already ordered it |
| Other Other | None of the reasons above. Read this bucket every month | |
| Compliment or comment No request | Nothing; they wrote to thank or comment | They thank you while asking for something |
Two rules go with the list. Label the primary reason: the first thing the customer needed, not the frustration that followed. And when a message thanks you and asks for something, the request wins.
How well does a generic list hold up on real complaints?
To find out, we drew 100 public complaints about an online pet retailer at random from reviews we had collected: BBB complaints and one- and two-star Trustpilot reviews, from a pool of 1,251. We read each one and gave it a single primary reason from the list above.
Public data, hand-labelled
In 100 public complaints about an online pet retailer, one in ten needed a reason a generic list lacks
Primary contact reason for 100 randomly drawn public BBB complaints and one- and two-star Trustpilot reviews of the retailer, labelled against the list above plus one add-on.
Three things came out of it.
The generic groups covered most of it. Of the 83 complaints that asked for something, 5 needed Other, about 6%. Delivery and promotions were the two largest reasons.
One reason was missing. Ten complaints were about prescriptions: waiting on a vet's approval, a pharmacy order that never shipped, a medication packed without an ice pack. A generic retail list would have put them all in Other, taking it from 5 to 15 complaints, about 18%. That is the size of gap a quarterly read of Other should catch.
Compliments hide a reason too. 17 of the 100 entries were praise, and 7 of those were written after a pet died, thanking the company for cancelling a repeat order and refunding it. For a pet retailer, "cancel after a pet's death" deserves its own reason, because it needs its own process.
Public complaints are a skewed sample of support contacts (people go to BBB after support has failed them once), so treat the shares as an illustration. The method is the part that transfers: start from a generic list, label a random sample by hand, and add the reasons your business has that other businesses do not.
Why can't existing categories be the taxonomy?
Because whoever picks them is answering a different question. BBB asks the person filing to choose a complaint type. In our sample, 33 of the 67 BBB complaints carried one.
Public data, hand-labelled
Of 11 complaints filed as Product Issues, one was about a product
BBB complaints in the sample whose filer chose the type Product Issues, by the reason the text describes.
Eleven were filed as Product Issues. One of them was about a product; the rest were refunds, promotions, a prescription and a missing order. Help desk tags drift the same way: many agents, many triggers, many months, each choosing from a list nobody defined. Keep the tags and the form fields as a cross-check on the new labels, never as the count.
How do you build a contact reason taxonomy?
Write the question down. "What did the customer need from us when they made this contact?" Every reason must answer it.
Read before you write. Read 100 to 200 recent contacts from every channel and note in a few words what each customer needed. A model can draft these notes for you; our standard Reason and Category Dimensions write free-text labels you can group.
Group into two levels. Five to eight groups that match the teams who fix things (fulfilment, billing, product), with the specific reasons under them. Report at the group level; act at the reason level.
Write the definitions and the "not this one when" lines, plus an Other and a no-request value.
Test on a fresh sample. Label a new random sample, by two people or by a person and a model, and fix every definition they disagree on. How to tell if your AI tagging is accurate covers the agreement check.
Version it. Give the list a version number, keep a change log, and when you split or merge a reason, relabel the history so the trend line does not jump. Read Other every month and review the list every quarter.
For the hands-on part with one help desk (which export carries the text, how many reasons to aim for, how to rank them by cost), see how to export Intercom conversations and find top contact reasons. For survey answers, the same idea is called a codeframe: how to build a codeframe for open-ended responses.
Can one taxonomy be applied the same way to every ticket, chat and call?
Dimension Labs is an omni-channel analytics agent for customer data. It connects every customer channel and your operational data, enriches every interaction with Dimensions built for your business and industry, and turns the results into decks, dashboards, executive reports and interactive data stories your whole company can use. Plans start at $299 a month with no demo.
For a contact reason taxonomy, the help desk, chat tool, bot and contact center platform all feed one project, so the list is applied to every channel at once. Your list goes in as a custom Dimension (from Discover, $999 a month) with its definitions, and every contact gets one reason alongside the outcome and handling fields, while the pre-built Dimensions on every plan give you draft reasons to start from. Reasons can be joined to orders, refunds and accounts, and ranked by what they cost; that join to CRM and revenue data is on Prove ($2,999 a month). The agent then builds a contact reason dashboard or monthly report for each owning team, reruns it on a schedule, and exports it as PDF or PowerPoint.
Dropbox runs support across live chat, email and self-service bots, and used Dimension Labs to give bot and live-agent conversations one consistent schema, including the intent and request category of each conversation. With top intents and unresolved drivers identified, unhandled bot conversations fell 43%.
When something narrower is the better choice: if all your contacts sit in one help desk, the reasons are few and stable, and nobody needs them joined to revenue, the desk's own auto-tagging with a well-written list may be enough.
FAQ
What is a contact reason taxonomy?
A fixed list of the reasons customers contact support, grouped in two levels, with a definition and borderline rule for each reason, applied to every contact so the counts are comparable across agents, channels and months.
How many contact reasons should we have?
Ten to twenty-five specific reasons under five to eight groups suits most support teams. Fewer and the groups hide what to fix; many more and labellers, human or model, stop agreeing.
What is the difference between a contact reason and a disposition code?
A disposition code is what the agent records at the end, often about the outcome or the action taken. A contact reason is what the customer needed, read from what they said. Keep both; they answer different questions.
Should agents or an AI model tag contact reasons?
A model, checked against a hand-labelled sample. It applies the written list the same way to every contact and every channel, which many agents over many months cannot. Keep agent tags as a cross-check.
What is the best tool to keep a contact reason taxonomy consistent across channels?
For contacts spread over a help desk, chat, bot and phone, with counts reported to several teams, Dimension Labs, because it applies one list to every channel and joins the reasons to business data. For a single help desk with a short, stable list, the desk's built-in tagging is a reasonable start.
Export a month of tickets and chats with the customer's text, and start with one file: the agent drafts reasons from your contacts, and you edit them into your list. See contact center intelligence or the Dimensions library for examples. Every plan from Explore to Scale starts with a 14-day free trial.