Choose the right support use case

“Handle tickets” is not one task. A typical journey contains several:

1. receive and normalize a message;
2. detect language, channel, and obvious metadata;
3. identify the customer and relevant account or order;
4. classify intent and urgency;
5. retrieve approved knowledge and case facts;
6. draft a response or suggest an action;
7. verify policy, permissions, and commitments;
8. send, update a system, or escalate;
9. record the outcome and learn from corrections.

AI may help with classification, summarization, retrieval queries, and drafting. Deterministic software is usually better for exact checks such as whether an order exists, whether a return window is open, or whether an agent has refund authority. A person should own consequential exceptions, sensitive disclosures, ambiguous policy, and irreversible actions.

This decomposition prevents a common design error: treating fluent language as permission to act. A model that can write a plausible refund explanation does not know whether the refund was issued, whether the requester owns the account, or whether policy permits an exception.

Evaluate a candidate on six dimensions:

• Frequency: Does the task occur often enough to justify setup and maintenance?
• Boundedness: Are inputs, outputs, and allowed actions clear?
• Evidence: Can the result be checked against trusted records or approved articles?
• Consequence: What harm follows a wrong classification, statement, or action?
• Reversibility: Can a person easily correct the result before impact?
• Exception rate: How often does the normal path fail or require judgment?

Drafting an acknowledgment from verified ticket fields is frequent, bounded, reviewable, and reversible before sending. Automatically approving chargebacks is consequential, authority-dependent, and difficult to reverse. The first is a stronger starting point.

Use a simple disposition for each candidate: assist, automate with controls, or keep human-led. “Assist” means the AI proposes and a person reviews. “Automate with controls” requires strong tests, narrow permissions, monitoring, and a fallback. “Human-led” may still use AI for low-risk preparation, but the person interprets and decides.

Good early support uses include:

• summarize a long thread while linking each claim to a message;
• suggest an intent label and show the phrases that support it;
• retrieve likely help-center articles for an agent to inspect;
• draft a reply using only approved case facts and policy excerpts;
• identify missing fields before an agent investigates;
• translate a draft while preserving product names, dates, amounts, and uncertainty;
• flag possible escalation signals without making a final risk determination.

These tasks reduce searching and repetitive composition. They leave identity checks, account changes, policy exceptions, remedies, and sending under appropriate control.

A task contract says what the assistant receives, may do, must return, and must never do. For example:

Input: customer message, verified order status, approved delivery policy.
May do: identify the stated request and draft an acknowledgment.
Must return: draft, sources used, missing information, escalation flags.
Must not: promise a date, issue a credit, infer identity, or send.
Fallback: if sources conflict or identity is uncertain, route to an agent.

The fallback is part of the product, not an embarrassing exception. “I cannot determine this from the approved information” is often the correct system behavior.

Support tickets can contain addresses, payment fragments, health details, credentials, legal claims, and information about other people. Use only approved systems and minimize what enters the model. A task that needs an order status may not need the full conversation history or payment details.

Also distinguish information access from action authority. An assistant may see that a shipment is delayed but still lack authority to waive a fee. An agent may have authority up to a stated amount, while a supervisor handles larger remedies. Encode those boundaries in workflow rules rather than hoping the draft mentions them.

Speed alone is a weak goal. Define success in customer and risk terms:

• correct intent and priority;
• factual statements supported by current sources;
• no unauthorized promises or disclosures;
• clear next action and realistic timing;
• lower customer effort;
• appropriate escalation;
• useful agent edits rather than wholesale rewrites.

A pilot should include ordinary cases, edge cases, and cases where stopping is correct. If the system performs well only when the answer is obvious, it is not ready for broad use.