Contact reason taxonomy for reporting sign-off

Build the taxonomy from real ticket language, then test whether two people can apply it the same way. This gives support operations analysts and customer service managers a proposal that reporting owners can approve, rather than a loose list of themes.

Your finished document should contain a small, usable set of contact reasons. Each reason needs a definition, exclusions, examples and a rule for ambiguous cases.

1. Prepare a representative ticket file

Start with a spreadsheet or CSV containing one row per conversation. Include these fields:

• Ticket ID: for tracing a proposed category back to source material.
• Subject: the customer’s own short description where available.
• Conversation summary: a concise account of the issue and requested help.
• Current tag or reason: include it if one exists, but do not treat it as correct.
• Product area, channel, market and status: keep these as comparison fields, not taxonomy labels.

Remove personal data, payment details, account identifiers and internal-only notes before sharing content with the model. Use summaries instead of full transcripts unless the wording in the transcript is essential to distinguish two reasons.

Choose a defined time period and include routine, unusual and high-impact contacts. Do not select only recently escalated cases or only one queue. A taxonomy built from exceptions will create reporting noise every week.

If your input options or file handling differ, check the current guidance in the xAI documentation overview.

2. Ask for clusters before asking for labels

Give the model a manageable batch of anonymised subjects and summaries. Ask it to group contacts by the customer’s primary intent, identify overlaps and preserve examples. Do not ask for a final taxonomy in the first pass.

Use a prompt structure such as:

You are reviewing support ticket subjects and summaries.

Group these records by the customer’s primary contact reason.
Do not group by channel, priority, customer segment, agent action or resolution.

For each group provide:
1. a short working label;
2. the shared customer need;
3. ticket IDs and short source examples;
4. likely overlaps with another group;
5. cases that cannot be classified confidently.

Do not invent reasons that are not supported by the records.

Records:
[Paste the batch here]

Review the clusters yourself. Combine labels only where the customer need and operational response are genuinely similar. For example, cannot reset password and password reset email not received may belong in one top-level access reason if they follow the same reporting path. Keep them separate if different teams, troubleshooting steps or product defects need to be tracked.

Run the same prompt on further batches. Keep a working comparison sheet with these columns:

Working label	Source ticket IDs	Keep, merge or split	Reason for decision
Access and sign-in	T-104, T-221	Keep	Same customer goal across several failure modes
Password reset email missing	T-308, T-410	Merge into access	A specific failure mode, not a separate reporting need
Suspected account takeover	T-119	Keep separate	Requires a distinct operational route

3. Convert clusters into taxonomy entries

Create the proposal in a document or spreadsheet table. Use plain labels that a new agent and a reporting analyst would interpret the same way. Avoid labels such as Other issue, General query or Miscellaneous except as a temporary review bucket.

For each contact reason, write five fields:

Field	What to write
Contact reason	A short noun phrase, such as Delivery tracking unavailable
Definition	The customer need that belongs here
Include when	The decisive signals or circumstances
Exclude when	Similar contacts that belong elsewhere
Examples	Two or three anonymised subjects or summary excerpts

Use the model to draft these fields from the retained examples. Give it the proposed label, source records and any known routing rule. Then ask it to identify boundary cases.

Draft one taxonomy entry from the evidence below.

Contact reason: [label]
Source examples: [examples]
Operational distinction: [if known]

Return these headings only:
Definition
Include when
Exclude when
Examples
Boundary case

Make the definition observable from a ticket summary. Do not claim a cause unless the customer report or investigation confirms it.

A useful definition says what the customer is trying to resolve. For example:

• Definition: The customer cannot see a usable delivery status for an order they expect to receive.
• Exclude when: The customer asks when an order will arrive but tracking is available. Classify that as delivery estimate.

The exclusion is doing important work. It stops similar sounding categories from absorbing one another.

4. Set a decision order for multi-issue tickets

Many conversations contain more than one issue. Your sign-off proposal must say whether reporting uses one primary reason, multiple reasons or a primary and secondary reason.

For most queue reporting, use one primary contact reason. Define it as the issue that first required support action or drove the main customer request. Record a secondary reason only if your reporting process can use it consistently.

Add a short decision order to the document:

1. Identify every customer need in the summary.
2. Select the need that drove the request for help.
3. If two needs are equally important, select the one requiring the first operational action.
4. If the summary lacks enough evidence, assign Needs taxonomy review, not a guessed reason.
5. Record the unclear wording that caused the review flag.

5. Test the proposal against fresh tickets

Do not validate the taxonomy using only the examples used to create it. Take a separate set of anonymised tickets from the same period, plus a small set from a different period if available.

Have two reviewers classify the tickets independently using only the taxonomy document. One can use the model to produce a suggested classification, but the reviewer should record the final choice and the reason. Compare the results row by row.

If you see this	Treat it as	What to change
Reviewers choose different labels	An unclear boundary	Strengthen exclusions or add a decision rule
Many tickets enter review	A missing or overly narrow reason	Add, merge or broaden a category based on evidence
One reason receives unrelated examples	A label that is too broad	Split it by customer need or operational path
A category has almost no valid examples	A weak reporting category	Merge it unless it is required for a defined operational route

The output is wrong when the definition cannot be applied from the available subject and summary, when exclusions conflict with examples, or when a category describes an agent action rather than the customer need. It is also wrong when a label hides a known operational distinction, such as a suspected security issue inside a general access category.

Record each disagreement in a change log. Include the ticket ID, both choices, the final decision and the wording changed. This becomes the evidence for operations sign-off.

6. Submit a controlled proposal for sign-off

Send one document containing:

• the taxonomy table and decision order;
• the source period and fields reviewed;
• the validation sample and disagreement log;
• unresolved Needs taxonomy review patterns;
• the owner for future changes;
• the date and trigger for the next review.

Ask sign-off owners to approve the definitions and boundaries, not just the labels. Reporting, queue management and knowledge owners may each spot a different problem.

When the taxonomy does not work, do not rename categories repeatedly to make them sound clearer. Return to the source tickets. Find the exact summaries causing disagreement, decide whether the problem is missing information, an overlap or a missing reason, then revise one rule and test it again on fresh tickets.