Best Prompts for Customer Support

A support ticket can contain several jobs at once: identify the customer’s problem, judge urgency, collect missing details, find the relevant policy or product guidance, route the issue, and write a reply. Under pressure, teams may focus on the response and miss the classification or safety decision that should come first.

AI can help prepare a triage recommendation and draft, but it should not guess at product behavior or promise a resolution. The best prompt creates a clear boundary between what the ticket says, what approved sources establish, and what still needs investigation.

Why ordinary prompting fails

“Answer this support ticket” rewards fluency rather than accuracy. The model may assume the customer’s environment, invent troubleshooting steps, cite a policy that was not provided, or declare an incident without enough evidence. It may also overlook security, privacy, billing, or legal content that needs special handling.

A better prompt makes classification the first task, uses an approved knowledge set, and requires escalation when confidence is low or a sensitive condition appears.

Reusable prompt

Copy
ROLE
You are a support triage assistant. Analyze the supplied ticket, recommend routing and priority, and draft a response grounded only in approved materials. A human agent makes the final decision and sends the reply.

REQUIRED INPUTS
1. Ticket text, attachments transcribed where needed, and timestamp
2. Customer plan, product area, and relevant account context
3. Priority definitions and routing rules
4. Approved knowledge articles, product documentation, and policies with version dates
5. Known incidents and status information with timestamps
6. Troubleshooting actions already attempted
7. Escalation rules for security, privacy, safety, legal, billing, and vulnerable customers
8. Response tone and channel constraints

STEPS
1. Summarize the customer’s stated issue without adding assumptions.
2. Detect separate issues if the ticket contains more than one.
3. Check for sensitive or mandatory-escalation conditions before troubleshooting.
4. Recommend category, subcategory, priority, and destination queue. Cite the applicable rule.
5. List known facts, inferred details, and missing information separately.
6. Search only the supplied approved materials for relevant guidance.
7. Propose safe next steps in order. Do not repeat actions the customer already tried unless verification is necessary.
8. Draft a response that acknowledges the impact, states what is known, asks only necessary questions, and sets accurate expectations.
9. Add an internal note with routing rationale and follow-up requirements.

OUTPUT FORMAT
A. Issue summary
B. Sensitive-condition check
C. Triage: category | priority | queue | rule cited | confidence
D. Known facts, inferences, and missing details
E. Recommended next steps with source references
F. Customer response draft
G. Internal note
H. Escalation or approval required

EVIDENCE AND UNCERTAINTY RULES
- Never invent product behavior, incident status, policy, timelines, refunds, or fixes.
- Cite the title and version date of each approved source used.
- Label unsupported possibilities as hypotheses.
- If guidance is absent, say “No approved guidance supplied” and escalate.
- Do not request passwords, full payment details, authentication codes, or unnecessary personal data.
- Do not expose internal-only notes in the customer draft.
- Use exact timestamps for incident information and flag anything stale.

What to provide

Provide the full ticket thread, not just the latest message, along with actions already attempted. Add plan and product context only when it is relevant and appropriate to use. The model also needs your real priority definitions, queue rules, approved documentation, policy versions, known-incident updates, and escalation criteria.

Keep the knowledge set controlled. An outdated help article can produce a plausible but harmful answer. Label internal-only content clearly, remove secrets, and avoid including personal data that the task does not require. If screenshots matter, provide a safe transcription or an approved image-processing path.

How to review the output

Review the sensitive-condition check before reading the draft response. Confirm that the proposed priority and queue follow your rules, especially where several issues are present. Then verify each troubleshooting step against the cited source and current product behavior.

Read the customer draft as if you received it. Does it acknowledge the actual problem without overstating what happened? Does it ask for the minimum information needed? Does it avoid promises the team cannot keep? Confirm that internal notes, security details, and private account context have not leaked into the response. A qualified team member should approve any refund, legal, privacy, or security language.

Where it fails

The prompt cannot compensate for missing or stale documentation. It may misread sarcasm, incomplete technical descriptions, or details hidden in an attachment. Complex bugs often require logs and engineering investigation, while account actions may require identity verification outside the conversation.

It should not autonomously send replies or make high-impact account changes. Sensitive cases need established escalation paths. If priority depends on service-wide telemetry, use the real monitoring system rather than asking the model to infer impact from one ticket.

Practical takeaway

A useful support prompt treats the response draft as the final step, not the whole job. Classification, evidence checks, and safe escalation come first. That structure helps the team move faster without replacing the controls that protect customers.

Try this prompt in Agentic Workers with an approved knowledge pack, then require human review before the draft is sent or the ticket is rerouted.

<!-- X derivative: A strong support prompt triages first, checks sensitive conditions, cites approved guidance, and drafts only after it knows what remains uncertain. -->