Customer service

Translate this approved customer reply [text] into [language] for [audience]. Our glossary is [terms], verified dates/amounts [facts] and tone sample [sample]. Keep commitments, exclusions and uncertainty at the same strength; do not turn an estimate into a guarantee. Mark terms that lack an equivalent or need a local reviewer, rather than inventing policy. Return the translation with a separate checklist of names, numbers and commitments to verify. Ask whether the customer needs plain language rather than literal internal terminology; do not send the message.

Make it yours: Redact customer details and have important policy wording reviewed by a competent speaker.

These redacted support threads arrived through [channels], with approved matching identifiers [IDs], timestamps [times] and policy [policy]. Identify threads that demonstrably concern the same case and keep uncertain matches separate. Build one chronology preserving promises, attachments referenced and unanswered questions. Do not merge cases just because names or wording look similar, expose another person's details or mark the issue resolved. Draft an internal handover and ask which identifier the case owner must verify before combining records.

Make it yours: Use authorised case IDs, not guesses based on a person's name.

A customer says our screenshot-based instructions are not usable for them [their stated need]. Here are the verified steps [steps], interface labels [labels], available support routes [routes] and approved policy [policy]. Draft a plain-text alternative with one action per step, meaningful labels and checkpoints, avoiding references such as click the green thing. Do not guess the customer's disability, promise untested accessibility or invent controls. Flag any step needing an authorised alternative and ask which device or input method they choose to share; do not send the reply.

Make it yours: Ask about the practical barrier, not unnecessary personal or medical information.

A customer is affected by [confirmed issue]. Here are the approved workaround [steps], known limits [limits], current status [facts] and support policy [policy]. Draft a reply explaining what the workaround does and does not solve, how to use the verified steps and the approved next contact. Do not invent a repair date, promise data recovery or recommend unsupported actions. Keep the underlying issue open unless the responsible team confirms otherwise. Ask which limitation matters to this customer's task before tailoring the message; do not send it.

Make it yours: Use only a workaround tested and approved by the responsible support team.

A customer sent this redacted request [text]. Here are our actual privacy-request procedure [policy], authorised contact route [route] and confirmed actions already taken [record]. Draft an acknowledgement and internal handover separating receipt, any required verification and decisions for the responsible privacy team. Do not invent legal deadlines, request unnecessary identity documents or claim deletion is complete. Preserve the customer's wording and mark unclear scope as a question. Ask which team is authorised to handle the request; do not delete, send or access records.

Make it yours: Follow the organisation's approved process and get qualified guidance where obligations are unclear.

Here is the redacted customer request [text], actual policy and exception process [text], facts we verified [facts] and my approval limit [scope]. Draft a respectful reply acknowledging the request and explaining the next review step without promising approval. Separate what I can do now from what needs a named role's decision. Do not invent rights, deadlines or a manager's agreement. Ask which fact the reviewer still needs before requesting only relevant information; do not send or escalate automatically.

Make it yours: Use the actual review process; empathy is not authorisation to promise an outcome.

A customer asks us to confirm [claim]. Here is their message, our relevant redacted records and the limits of my role [material]. Draft a reply separating what the records confirm, what is missing and the exact information needed for an authorised check. Do not accuse the customer, invent a booking or issue a guarantee to end the conversation. Include an internal question for the record owner. Ask which identifier can be requested through our approved secure channel before choosing the next step.

Make it yours: Do not ask customers to paste sensitive identifiers into an unapproved channel.

This request belongs to [team] under our supplied routing rules [rules]. Here is the redacted conversation, information already collected and transfer options [records]. Draft a short customer explanation and a handover containing only relevant authorised details. Distinguish a transfer request from a completed transfer, and do not promise a response time the receiving team has not approved. Ask which detail the next team still needs before sending the customer another form; do not send anything.

Make it yours: Preserve useful context without copying unrelated private conversation.

Here is a resolved-or-partly-resolved support conversation [redacted text], verified actions [records] and our closure policy [excerpt]. Draft a closing summary listing the original issue, confirmed outcome, remaining limitation and how to reopen under the actual policy. Do not label the whole case solved because one step worked or invent customer satisfaction. Include an internal status recommendation for approval. Ask whether the customer has confirmed the result before using definitive closure wording.

Make it yours: A successful internal action is not proof that the customer can complete their task.

A customer says our promised fix did not happen. Here is the anonymised timeline [notes], exact promise [message], confirmed actions [records] and escalation policy [policy]. Separate promised, attempted, completed and unverified actions. Draft a reply acknowledging the missed commitment without inventing excuses or unauthorised compensation. Make an internal handover with an owner to confirm, next check and policy-supported options. Do not call the issue resolved because a ticket closed or send the reply. A new deadline needs actual team confirmation; ask for missing ownership information.

Make it yours: Include the original promise in the private case material.

Draft a customer update about [service disruption] using only these verified incident facts and approved communication rules [material]. State the affected function, confirmed scope, available approved workaround and the next update time if authorised. Separate confirmed facts from investigation questions. Do not invent a cause, restoration estimate, security assurance, compensation or promise that no data was affected. If key information is missing, ask for it or explicitly say it is not yet confirmed. Give a short status-page version and a support-reply version for human approval; do not publish them.

Make it yours: A promised next update is different from a promised fix. Supply the actual approval and owner.

Use this anonymised customer message, case notes and approved damaged-delivery policy [material]. List what the customer already supplied and what evidence the policy genuinely requires. Draft a reply acknowledging the specific damage and asking only the necessary missing questions, with an accessible alternative if the customer cannot provide a photo. Do not ask them to open a hazardous item, expose payment details or repeat information in the notes. Offer only the authorised next step; do not promise replacement, refund or a carrier finding before approval. Do not send the reply.

Make it yours: Use the policy for this order and jurisdiction; do not let AI invent a universal returns rule.

Draft a reply to a customer whose appointment we cancelled using [confirmed reason that may be shared], [approved policy] and these currently supplied alternative slots [dates, times, time zone and duration]. Acknowledge the disruption, state the options plainly and explain how the customer can confirm under our actual booking process. Do not invent availability, disclose private staff circumstances, reserve a slot or promise a discount. Flag any missing details needed before sending and make clear that the slots may need rechecking.

Make it yours: Use anonymised notes and provide the date, not just 'next Tuesday'.

Draft a reply to this customer's late-parcel complaint: [message]. Here are the verified tracking details and remedies I am authorised to offer: [facts and policy]. Acknowledge the delay, explain what is known and give a specific next step. Do not invent a delivery date, blame the customer or promise a refund outside policy. Use [tone] and keep it under 150 words. If information is missing, draft a clarification question instead of guessing.

Make it yours: Remove addresses, tracking numbers and other identifiers before sharing.

Summarise this anonymised support case for escalation. Include the timeline, verified facts, steps already tried, customer impact and the exact decision needed. Reference the relevant ticket entries. Keep assumptions and policy gaps visible and avoid repeating unnecessary personal data.

Make it yours: State who will receive the escalation and what they can decide.

Use these anonymised tickets and the current help article to identify where customers get confused. Map each issue to the wording or missing step. Propose targeted changes and one realistic example. Preserve policy commitments and flag product facts needing verification.

Make it yours: Provide the current approved article and representative tickets.

Make a checklist for reviewing our customer-support replies using the approved policy [policy] and these anonymised examples [replies]. Check factual accuracy, whether the customer's question was answered, the next step and unnecessary effort. Explain each check with a concrete example. Keep personal tone preferences separate from errors that matter. Flag policy gaps instead of inventing a rule.

Make it yours: Use the same checklist on two replies and discuss any disagreement between reviewers.

Use our attached policy and this anonymised customer message to draft a reply: [message]. Explain the applicable next step in plain language and acknowledge the customer's actual issue. Cite the relevant policy section separately for internal review. Flag any case the policy does not cover. Do not invent exceptions, refunds or delivery dates.

Make it yours: Include the current policy version and what the agent is authorised to offer.

Group these anonymised support tickets into issue themes. Give theme definitions, ticket IDs, counts and representative evidence. Separate product defects, confusing information and service process issues. Mark ambiguous cases. Suggest one intervention for each of the three largest themes and explain how we could measure its effect.

Make it yours: Provide a representative period and mention any excluded channels.

Draft a reply to this anonymised complaint [complaint] using our approved policy and verified case notes [material]. Acknowledge the specific problem, explain what is confirmed and give the next step we are actually authorised to offer. Do not promise a refund, deadline or compensation absent from the policy. Separately list the process questions our team should investigate. Do not send the reply.

Make it yours: Include what has already been tried and remove unnecessary customer details.