AI Prompts for Customer Support: 15 That Hold Up in Production

Why support is the hardest place to use a generic prompt

Support is the function where AI adoption is fastest and where a bad output costs the most. A marketing draft that misses is a wasted hour. A support reply that misses is a customer who was told the wrong thing by your company, in writing, with a timestamp.

The specific failure is almost always the same one. The model does not know your refund window, your data retention policy, your SLA tiers or which plan includes SSO — so it produces the industry-average answer, phrased with total confidence. Thirty days, because most companies are thirty days. Business hours support, because that is the modal answer. It reads perfectly and it is wrong for your product.

Everything below is built around closing that gap. The prompts supply policy as input rather than relying on the model to recall it, and they instruct the model to flag a gap instead of filling it. That single discipline is the difference between a support assistant that saves your team hours and one that generates work.

The three-part structure every support prompt needs

Before individual prompts, the shape they all share. A support prompt that works has three blocks, and the order matters because the model weights early instructions more heavily when they establish constraints.

First, the role and the boundary: who the model is writing as, and what it is not allowed to do. Second, the ground truth: the policy text, the plan matrix, the ticket history, the account state — everything the answer must be derived from. Third, the task and the output shape: what to produce, in what tone, at what length, in what format.

Leave out the second block and you get confident invention. Leave out the third and you get a wall of prose the agent has to edit into a reply anyway, which erases the time saving. Most teams write the first block and skip the other two, then conclude AI is not useful for support.

• Block 1 — Role and boundary: "You are drafting a reply for a support agent at [COMPANY], a [PRODUCT DESCRIPTION]. You never state a policy, price, timeline or entitlement that is not in the reference material below. If the answer is not there, write [NEEDS AGENT INPUT: what is missing] inline and continue."
• Block 2 — Ground truth: paste the relevant policy sections, the plan comparison, the ticket thread, and any account facts the agent can see.
• Block 3 — Task and shape: "Draft a reply. Under 150 words. Acknowledge the specific problem in the first sentence without apologising twice. State what happens next and when. No filler openings."

Prompt 1 — Draft a reply from a ticket and your policy

This is the workhorse. It replaces the blank-reply-box stare that eats the first two minutes of every non-trivial ticket, and because the policy is pasted in, the draft is anchored to what is actually true at your company.

The instruction to mark gaps rather than fill them is the load-bearing part. Agents learn very quickly to scan for the bracketed markers, and a draft with three markers is still faster than writing from scratch — while a draft with three confident inventions is slower, because now the agent has to fact-check every sentence.

• Prompt: "You are drafting a reply for a support agent at [COMPANY]. Rules: use only the reference material below; never state a policy, date, price or entitlement that is not in it; where information is missing write [NEEDS AGENT INPUT: what is missing] inline rather than guessing. Reference material: [PASTE POLICY / DOCS]. Customer ticket: [PASTE]. Draft a reply under 150 words that (1) names the specific problem in the first sentence, (2) states what we are doing about it, (3) gives a concrete next step and timeframe if one exists in the reference material. Tone: direct and warm. Do not apologise more than once. Do not open with 'Thank you for reaching out'."

Prompt 2 — Summarise a long thread before you touch it

Escalated tickets and reopened threads arrive with twenty messages of history. Reading all of it costs five minutes; reading a bad summary costs a customer who has to repeat themselves for the fourth time, which is the single most reliable way to turn an annoyed customer into a churned one.

Ask for the summary in a fixed shape so it is scannable at a glance and so what is missing is obvious. The "what the customer has already been told" line is the one that prevents contradicting a colleague — the most damaging thing a second agent can do.

• Prompt: "Summarise this support thread for an agent picking it up cold. Output exactly these labelled lines: PROBLEM (one sentence, in the customer's terms); IMPACT (what it is blocking for them); ALREADY TRIED (what we have asked them to do and the result); ALREADY PROMISED (anything we have committed to, with dates); OPEN QUESTION (what the customer is waiting on right now); SENTIMENT (one word). If any line has no information in the thread, write 'none in thread'. Thread: [PASTE]"

Prompt 3 — Turn a customer conversation into a bug report

Engineering rejects support-filed bugs for predictable reasons: no reproduction steps, no environment, no distinction between what the customer observed and what they concluded. That last one causes more wasted engineering hours than anything else — "the export is broken" is a conclusion, "the CSV downloads with 0 bytes on Safari 17" is an observation.

This prompt does the separation mechanically, and marks what is still missing so the agent knows exactly what to ask the customer before filing.

• Prompt: "Convert this support conversation into a bug report for engineering. Sections: TITLE (one line, observable behaviour not diagnosis); ENVIRONMENT (platform, browser, app version, plan — only what is stated); STEPS TO REPRODUCE (numbered, only steps the customer actually described); EXPECTED; ACTUAL; CUSTOMER IMPACT (who is blocked and from what); EVIDENCE (quote the exact error text and IDs). Strictly separate what the customer observed from what they concluded — put conclusions under a final HYPOTHESIS section and label them as unverified. End with MISSING INFO: a bullet list of what engineering will ask for that we do not have. Conversation: [PASTE]"

Prompt 4 — Rewrite a reply that is technically correct and badly received

Every support team has replies that are accurate and land like a slap. Usually the cause is structural rather than tonal: the refusal arrives before the acknowledgement, the policy is quoted without a reason, or the customer is told what they cannot have without being told what they can.

This prompt is more useful than a generic "make this friendlier", which typically just adds exclamation marks and the word "absolutely" to the same cold answer.

• Prompt: "Rewrite this support reply. Keep every factual statement and every policy outcome exactly as they are — do not soften a refusal into a maybe. Change only the structure and wording: acknowledge the specific problem before any refusal, give the reason behind the policy in one clause, and end with the best thing we can actually do rather than what we cannot. Remove corporate filler and any sentence that says nothing. Keep it under [N] words. Reply: [PASTE]"

Prompt 5 — Triage an inbound ticket

Triage is cheap to automate and expensive to get wrong in one direction only: under-prioritising an outage is costly, over-prioritising a question is merely noisy. Build that asymmetry into the prompt explicitly rather than hoping the model shares your risk tolerance.

• Prompt: "Triage this ticket. Output: CATEGORY (one of: [YOUR CATEGORIES]); PRIORITY (P1 blocking / P2 degraded / P3 question / P4 feedback); ROUTE_TO (one of: [YOUR TEAMS]); FIRST_ACTION (one sentence). Rules: anything reporting data loss, a security concern, a billing charge the customer disputes, or a total inability to use the product is P1. When you are between two priorities, choose the higher one. If the category is unclear, output UNCLEAR rather than guessing. Ticket: [PASTE]"

Prompt 6 — Draft the macro, not the reply

The highest-leverage support prompt is not one that writes a reply — it is one that writes the template you will send four hundred times. A macro is worth roughly four hundred times whatever a single reply is worth, and it gets reviewed properly because everyone knows it will be reused.

Ask for variants rather than one draft. Support macros fail at the edges — the customer who is angry, the customer who has asked twice, the customer on the enterprise plan — and generating those variants up front is far cheaper than discovering them one bad interaction at a time.

• Prompt: "Write a reusable support macro for this situation: [SITUATION]. Constraints: [POLICY FACTS]. Produce three versions — (a) standard, (b) for a customer who has already contacted us about this, (c) for a customer who is visibly frustrated. All three must contain the same factual content and the same outcome. Mark every place that needs personalising with [BRACKETS]. Keep each under 120 words. Then list the three situations where this macro should NOT be used."

Prompt 7 — Explain a technical cause in customer language

When engineering supplies the root cause, it arrives in engineering language: a race condition in the webhook consumer, a stale cache key, a migration that ran long. Sent as-is it is meaningless; over-simplified it sounds evasive. The middle path is a short explanation that names a real mechanism without requiring the customer to know your architecture.

• Prompt: "Rewrite this technical explanation for a customer who is not an engineer but is not stupid. Two or three sentences. Name the actual mechanism in plain terms — do not reduce it to 'a technical issue'. Do not use these words: leverage, robust, seamless, unfortunately, glitch. State clearly whether their data was affected. State whether it can happen again and what we changed. Explanation: [PASTE]"

Prompt 8 — The refund and exception decision helper

This is the prompt teams most want and most often build wrong. The instinct is to have the model decide. Do not. The model has no accountability, cannot see the commercial relationship, and will happily approve or deny based on the emotional temperature of the customer's message rather than your policy.

What it can do usefully is lay out the decision. Which policy clauses apply, which facts are present, which facts are missing, and what the arguments are on each side. The agent still decides, but from an organised picture rather than a wall of thread.

• Prompt: "Do not make a decision. Lay out this refund request for the agent who will. Output: WHAT IS BEING ASKED FOR; POLICY CLAUSES THAT APPLY (quote them verbatim from the policy below, with no paraphrase); FACTS PRESENT IN THE THREAD that bear on those clauses; FACTS MISSING that the agent needs before deciding; ARGUMENT FOR approving; ARGUMENT AGAINST. Do not recommend an outcome. Policy: [PASTE]. Thread: [PASTE]"

Prompt 9 — Mine last month's tickets for the fix that removes them

Support volume is a product signal that most teams never read. The single highest-return use of AI in support is not answering tickets faster; it is finding the twenty tickets that share a cause and getting that cause fixed so the next two hundred never arrive.

Paste in a batch of ticket subjects and first messages — anonymised — and ask for clusters by underlying cause rather than by wording, because the same root problem arrives phrased fifteen different ways.

• Prompt: "Below are [N] support tickets. Cluster them by underlying cause, not by wording — tickets phrased differently with the same root cause belong in one cluster. For each cluster output: CAUSE (one sentence); TICKET COUNT; REPRESENTATIVE QUOTE; WHERE IT ORIGINATES (product bug / unclear UI / missing documentation / expectation set by marketing / genuine feature gap); CHEAPEST FIX. Order clusters by ticket count. Ignore clusters with fewer than three tickets. Tickets: [PASTE]"

Prompt 10 — The apology that is not a liability

Outage and incident notes are where support writing gets legally and reputationally sensitive. Two failure modes: the note that admits fault in terms that create obligations nobody approved, and the note so hedged that it reads as a refusal to acknowledge anything happened.

Constrain both directions in the prompt, and route anything touching a security or data incident through whoever owns that at your company before it goes out. That is not a prompt engineering problem.

• Prompt: "Write a service incident note to affected customers. Facts, and only these facts: [WHAT HAPPENED], [WHO WAS AFFECTED], [DURATION], [WHAT WE HAVE FIXED], [WHAT WE ARE CHANGING]. Rules: acknowledge the impact in the first sentence in concrete terms; do not use 'may have been affected' if we know they were; do not promise compensation, credits or timelines that are not in the facts above; do not use the words unprecedented, unfortunately, or inconvenience; state plainly whether customer data was accessed or lost. Under 200 words."

Prompt 11 — Detect the churn signal in a routine ticket

Cancellation rarely arrives as a cancellation ticket. It arrives as the third question about exporting data, or a question about how billing works on annual plans, or a suddenly clipped tone from a customer who used to be chatty.

A model reading a thread with a clear brief will surface those signals reasonably well — not as a prediction to act on automatically, but as a flag for a human to look at.

• Prompt: "Read this support thread and flag any signals that this customer is at risk of leaving. Look for: questions about data export or migration, questions about contract or cancellation terms, comparisons to a competitor, a drop in tone warmth compared to earlier in the thread, repeated contact about the same unresolved issue, mention of an internal champion leaving. For each signal, quote the exact line and rate confidence low/medium/high. If there are no signals, say 'no signals'. Do not speculate beyond what is in the text. Thread: [PASTE]"

Prompt 12 — Turn a resolved ticket into a help article

Every hard ticket that got solved contains a help article nobody wrote. The gap is friction: writing the article is a twenty-minute job that never beats the next ticket in the queue. Reducing it to a two-minute review job is what actually gets the knowledge base populated.

• Prompt: "Turn this resolved ticket into a help centre article. Structure: a title phrased as the customer would search for it, not as we describe the feature; a one-sentence answer at the top; the steps that actually resolved it, numbered; a short section on how to tell it worked; a short section on what to do if it did not. Strip every customer-identifying detail and all thread-specific context. Where the resolution depended on something an agent did that a customer cannot do themselves, say so explicitly. Ticket: [PASTE]"

Prompt 13 — Quality-review a sample of replies against your own standard

QA in support is usually either unscaled — a lead reads four tickets a week — or reduced to a CSAT number that tells you a customer was unhappy without telling you why. A model can read fifty replies against a written standard in a minute, which is not a substitute for a human reviewer but is a good way to decide which fifty they should read.

The key is supplying your standard. Without it you get generic advice about empathy. With it you get findings about your actual bar.

• Prompt: "Here is our support quality standard: [PASTE STANDARD]. Below are [N] agent replies. For each: score it against every criterion in the standard as met / partly met / not met, quote the specific line that determined each not-met, and give one concrete rewrite for the weakest sentence. Do not comment on anything the standard does not cover. End with the two criteria most frequently missed across the whole sample. Replies: [PASTE]"

Prompt 14 — The multilingual reply that keeps the meaning

Translation of support replies fails at the edges that matter: a policy sentence that becomes vague, a level of formality that reads as rude in the target language, or a product term translated into a word your interface does not use.

Handle those three things explicitly. The instruction to leave interface strings untranslated is the one non-native-speaking agents thank you for, because a customer cannot find a button labelled with a word that does not appear on it.

• Prompt: "Translate this support reply into [LANGUAGE] for a [COUNTRY] customer. Rules: keep every product name, menu label and interface string in English exactly as written — do not translate anything the customer will see in the UI; match the level of formality normal for customer service in [COUNTRY], not a literal rendering of the English register; keep policy statements exactly as precise as the original — if a phrase cannot be rendered precisely, flag it rather than approximating. After the translation, list any phrase you were unsure about with a literal back-translation. Reply: [PASTE]"

Prompt 15 — The pre-send check

The cheapest safety net available to a support team is a second prompt that reads the draft before a human sends it. It costs a few seconds and catches the category of mistake that is most embarrassing: a number that does not match policy, a promise nobody can keep, a name from the wrong ticket.

• Prompt: "Check this draft reply before it goes to a customer. Report only problems, as a list — if there are none, reply 'clear'. Check for: any factual claim, date, price or policy statement not supported by the reference material; any commitment we have not actually made; any name, order number or detail that does not appear in this ticket; any sentence that could be read as admitting legal fault; any placeholder or bracket left unfilled. Reference material: [PASTE]. Ticket: [PASTE]. Draft: [PASTE]"

What to automate fully, and what never to

The line is not about difficulty; it is about what happens when the output is wrong. Anything where a wrong answer costs a customer a few seconds of confusion can run unsupervised. Anything where a wrong answer costs money, trust or a legal position cannot, no matter how good the drafts look in testing.

Teams tend to discover this line by crossing it. The pattern is consistent: full automation goes live, works well for weeks on the easy majority, and then produces one confident wrong answer on an edge case that becomes a support escalation, a refund, and a screenshot on social media. The measured version — draft automatically, review always — captures most of the time saving with almost none of the risk.

• Safe unsupervised: ticket triage and routing, thread summarisation for internal use, drafting suggestions shown only to agents, clustering tickets for analysis, translating an internal note.
• Draft, human sends: every customer-facing reply, every macro, every incident note, every help article.
• Never delegate the decision: refunds and exceptions, account termination, anything touching a security or data incident, anything with a legal or contractual dimension, anything where the customer is threatening escalation.
• The test: if the output being confidently wrong would cost more than the time it saves, a human reads it first.

Measuring whether any of this worked

Support teams adopting AI usually measure the wrong number. Handle time drops immediately because drafting is faster, and that gets reported as a win — while reopen rate quietly rises because drafts are shipping with subtly wrong information that generates a second ticket.

Watch four numbers together, and treat any handle-time improvement paired with a rising reopen rate as a regression rather than a success. A reply that is written in half the time and answered again a day later has made things worse, not better.

• Reopen rate — the honest measure of whether drafts are actually correct. It should hold flat or fall.
• Time to first response — where the drafting prompts pay off most visibly.
• Escalation rate — if it rises, your triage prompt is under-routing.
• Ticket volume by cluster — the only number that shows whether you are fixing causes rather than answering symptoms faster.
• Sample twenty AI-drafted replies a week and read them against your standard by hand. Metrics tell you something changed; reading tells you what.

Turning these into a support prompt library

Fifteen prompts pasted from an article are a demo. What makes them an asset is turning them into your team's versions, stored where an agent can reach them in the ten seconds they have between tickets.

The conversion is small. Replace [COMPANY] and [PRODUCT DESCRIPTION] once. Paste your real policy into the reference blocks. Replace the category and team lists in the triage prompt with your actual ones. Add your own banned-words line — every support team has phrases that make their customers wince, and a standing exclusion list improves output more than any other single edit.

Then version them. When a prompt produces a bad draft, the fix belongs in the stored prompt, not in one agent's head. A support prompt library that improves every time someone catches a failure becomes, within a quarter, considerably better than anything you could have written on day one — and considerably better than what your competitors are pasting out of an article.

Related articles