Complaint trend brief for corrective action

Use a fixed case sample and a fixed brief template each reporting cycle. This gives service owners a short list of recurring complaint themes, the evidence behind each one, and the team that must respond.

This method is for customer experience managers and service owners who need an action brief, not a long summary of tickets. The model groups and drafts. You decide whether the evidence supports the conclusion.

1. Set the reporting question and case boundary

Start with one question that can lead to action. Avoid broad requests such as What are customers unhappy about? Use a question tied to a service, journey and period.

For example: Which recurring complaints in delivery support cases need corrective action this month?

Write the boundary at the top of your working document:

• Reporting period: the start and end date.
• Case population: queues, tags, products or customer journeys included.
• Exclusions: duplicate contacts, spam, test cases, or cases without sufficient notes.
• Unit of analysis: one case, not every message in a thread.
• Decision required: what service owners need to approve, investigate or assign.

Choose a sample you can check properly. If the volume is manageable, use all eligible cases. If it is not, take a repeatable sample, such as the first eligible cases from each week or a set number from each queue. Record the method so next month's result is comparable.

Remove direct identifiers before sharing records with the model. Keep the case ID only if it is needed for your internal reviewers to retrieve the source record.

2. Build a case evidence sheet

Export the fields that establish what happened. Do not send a raw conversation dump if a structured extract will do. Create a table with one row per case and these columns:

Field	Put in the field	Do not put in the field
case_id	Internal reference	Customer name or email
opened_date	Date the case began	A guessed incident date
customer_report	What the customer says happened	Your explanation of why
system_or_policy_evidence	Status, timestamp, policy result or confirmed event	Unverified agent recollection
agent_action	What support did	Whether it fixed the root cause
outcome	Resolved, pending, refunded or escalated	A claim that the customer is satisfied
proposed_theme	A short provisional label	A final root-cause finding

Read a small set of cases yourself before using the model. This tells you whether the export is usable and gives you the language customers use. Correct missing timestamps, ambiguous status labels and obvious duplicate records first.

For current handling requirements and product behaviour that may differ by version, check the xAI documentation overview before loading data.

3. Classify cases with a constrained prompt

Give the model the evidence sheet in manageable batches. Ask it to classify, not diagnose. Use the same prompt and output fields for every batch.

Use this prompt, replacing the bracketed text:

You are analysing customer support case records for a corrective-action brief.

For each case, return one row with:
- case_id
- primary complaint theme, using a short consistent label
- reported facts, copied or closely paraphrased from the record
- confirmed operational facts, only where a system event or policy result is present
- assumptions or possible causes, marked clearly as unconfirmed
- affected customer journey
- team that should investigate or respond
- confidence: high, medium or low
- evidence gaps

Rules:
1. Do not infer a root cause from a customer statement alone.
2. Do not invent missing dates, events, policy decisions or team ownership.
3. If two themes apply, select one primary theme and list the other under evidence gaps.
4. Use `unknown` where the record does not support a field.
5. Keep reported facts and assumptions in separate fields.

Case records:
[PASTE THE CASE EVIDENCE SHEET]

Keep the returned rows with the original case IDs. They are the audit trail for the final brief.

4. Consolidate themes into an action list

Combine the classified batches and ask the model to group only the existing primary theme labels. Do not ask it to calculate precise rates unless your source sheet has reliable denominators.

Use this consolidation prompt:

Using the classified case rows below, produce a corrective-action brief.

For each recurring theme include:
- theme name
- case IDs and number of distinct cases
- reported facts, stated without interpretation
- confirmed operational facts
- unconfirmed assumptions or hypotheses
- customer impact described in the records
- owner team or teams to respond
- requested next action
- evidence needed to confirm or reject the hypothesis

Rank themes by repeat occurrence and customer impact in the records.
Do not call an assumption a root cause. Do not merge distinct problems merely because they involve the same team.

Classified rows:
[PASTE CLASSIFIED OUTPUT]

Use this brief structure in your service review:

1. Scope and method: period, queues, case count, exclusions and sampling method.
2. Priority themes: no more than the number leaders can discuss and assign in one meeting.
3. Evidence by theme: reported facts, confirmed facts and assumptions as separate subsections.
4. Required response: accountable team, named action owner, due date and evidence requested.
5. Open questions: missing logs, policy interpretation, product investigation or data needed.

Assign the team that can investigate the next missing fact, not necessarily the team that received the complaint. A billing question may need Finance Operations. A failed status update may need the product or engineering owner. An unclear agent explanation may need Support Operations.

5. Check the brief before it goes to owners

Review every theme that is being escalated. Check the highest-impact examples first, then a random selection from the remaining themes. Ask a second reviewer to read the brief alongside the source cases where possible.

If you see this	Treat it as	What to do
“Customers were charged twice” with no payment record	Reported fact	Say customers reported duplicate charges. Request payment investigation.
Payment records show two captured transactions	Confirmed operational fact	State the record and assign the investigation.
“The new checkout caused the issue”	Assumption	Keep it as a hypothesis unless evidence links the cases.
Several cases with different underlying failures	Over-grouping risk	Split the theme and recount distinct cases.

The output is wrong when it upgrades a customer claim into a confirmed event, gives ownership to a team without a reason, or groups cases by similar wording rather than the same failure. It is also wrong if a theme has no case IDs, because nobody can inspect the evidence.

6. Make the brief a recurring operating habit

Run the same process on the same cadence as your service review. Keep a theme register with the approved label, definition, owner team and examples that qualify or do not qualify. Update it only after the service owner agrees a label has changed.

At the next review, reopen each prior action and record one of these outcomes:

• action completed, with evidence
• investigation still open, with the next evidence date
• theme reduced, based on the same case boundary
• theme persists, requiring a revised action
• theme was misclassified, with the reason recorded

This prevents the brief becoming a list of complaints that nobody closes.

When the method does not work

If the model produces vague themes, tighten the case fields and provide a small approved theme register. If it repeatedly assumes causes, remove narrative notes that mix fact and opinion, then restate the classification rules. If owners dispute the findings, return to the case IDs and split the disputed statement into reported fact, confirmed record and unconfirmed hypothesis.

If the case export lacks timestamps, outcomes or system evidence, do not compensate with stronger prompting. Ask the team that owns the case system to add or expose the missing field. A narrower brief with traceable evidence is more useful than a confident-looking report built on incomplete records.