30 Claude Prompts for Zendesk

You are a technical writer who converts resolved support tickets into Zendesk help centre articles. <context> A customer had a problem that took three back and forth replies to solve, and I suspect other customers hit the same issue without ever opening a ticket. </context> <inputs> - Full ticket thread, pasted: [PASTE TICKET THREAD] - Product area: [PRODUCT AREA] - Target reader's skill level: [BEGINNER OR ADVANCED] </inputs> <task> Write a standalone help centre article that solves this problem for someone who has never opened a ticket about it, including a clear title, a short intro stating the symptom, and numbered steps. </task> <constraints> Do not reference the original ticket, agent names, or customer names. Write steps a reader can follow without additional context. Keep the article under 400 words. Avoid vague step descriptions like adjust the settings as needed. </constraints> <format> Return the article with an H1 title, a one-sentence summary, and numbered steps in Markdown. </format>

You are a documentation editor who rewrites technical help centre content for non-technical end users. <context> Our help centre article for [FEATURE NAME] was written by an engineer and customers keep contacting support instead of using it, which tells me it is too technical. </context> <inputs> - Existing article text: [PASTE ARTICLE TEXT] - Typical reader (job title or role): [READER ROLE] - Jargon terms customers ask us to explain: [JARGON TERMS] </inputs> <task> Rewrite the article so a reader with no technical background can follow it, replacing or defining jargon terms the first time they appear. </task> <constraints> Keep every step and fact from the original, do not remove functionality coverage to simplify. Define jargon inline in parentheses rather than in a separate glossary. Keep sentences under 20 words on average. </constraints> <format> Return the rewritten article in Markdown with the same heading structure as the original, then a short list of terms you defined and how. </format>

You are a support content strategist auditing help centre coverage against real customer questions. <context> I have a help centre article that gets decent traffic but customers still ask questions in tickets that the article should be answering. </context> <inputs> - Existing article text: [PASTE ARTICLE TEXT] - List of recent related ticket questions: [PASTE LIST OF QUESTIONS] - Product area: [PRODUCT AREA] </inputs> <task> Compare the article against the list of real questions and identify which questions the article does not clearly answer, then draft new sections or edits to cover each gap. </task> <constraints> Only flag genuine gaps, not questions the article already answers in different words. Keep new sections consistent in tone and heading style with the existing article. Do not rewrite sections that already work. </constraints> <format> Return a Gaps Found list mapping each unanswered question to a proposed new section, then the proposed section text for each, ready to insert. </format>

You are a support knowledge base editor who writes internal Zendesk articles for agent use only, not customer-facing. <context> Agents keep escalating a specific issue to me directly instead of resolving it themselves, and I want an internal article that gives them the diagnostic steps. </context> <inputs> - Issue description: [ISSUE DESCRIPTION] - Diagnostic steps you currently walk agents through verbally: [DIAGNOSTIC STEPS] - Tools or admin panels involved: [TOOLS OR PANELS] - When to escalate instead of resolving directly: [ESCALATION CRITERIA] </inputs> <task> Write an internal troubleshooting article that lets a mid-level agent diagnose and resolve this issue without escalating, including a clear escalation trigger for when they still should. </task> <constraints> Assume the reader already knows the product but not this specific issue. Include the exact escalation criteria as a distinct callout, not buried in prose. Keep it scannable, use short numbered steps not long paragraphs. </constraints> <format> Return the article in Markdown with sections: Symptom, Diagnosis Steps, Resolution, When To Escalate. </format>

You are a technical writer who keeps help centre articles synced with product releases. <context> We just shipped changes to [FEATURE NAME] and the existing help centre article now describes outdated behaviour. </context> <inputs> - Release note text: [PASTE RELEASE NOTE] - Existing article text: [PASTE EXISTING ARTICLE] - Anything removed or deprecated in this release: [DEPRECATED ITEMS] </inputs> <task> Update the existing article to reflect the new behaviour, removing or clearly marking any steps that describe the old, deprecated behaviour. </task> <constraints> Do not silently delete deprecated steps if customers on older plans might still see them, mark them instead as For accounts on the previous version. Keep the rest of the article's structure unchanged. Flag anything you were not given enough information to update confidently. </constraints> <format> Return the updated article in Markdown, followed by an Open Questions list for anything you could not confirm from the inputs given. </format>

You are a support operations analyst who designs Zendesk tagging systems. <context> Our ticket tags grew organically and now overlap and contradict each other, making reporting unreliable. </context> <inputs> - Sample of 20 to 30 recent ticket subjects and summaries: [PASTE TICKET SAMPLES] - Current tag list: [PASTE CURRENT TAGS] - Teams that route off these tags: [TEAM NAMES] </inputs> <task> Propose a clean tag taxonomy grouped into no more than 6 top-level categories, each with a short definition and 2 to 4 example tickets from the sample that belong there. </task> <constraints> Do not create a tag for anything that appears only once in the sample. Keep tag names lowercase with hyphens, matching Zendesk convention. Flag any current tag that should be retired and why. </constraints> <format> Return a table-style list of category, tag name, definition, example ticket, then a Retire section listing old tags to remove. </format>

You are a support team lead who writes triage playbooks for new hires. <context> Our shared Zendesk inbox gets a mix of billing, technical, and sales questions and new agents are not sure how to route them. </context> <inputs> - Team names that receive routed tickets: [TEAM NAMES] - Example ticket that was misrouted recently: [EXAMPLE MISROUTED TICKET] - Priority rule for angry or urgent-sounding customers: [PRIORITY RULE] </inputs> <task> Write a triage decision tree a new agent can follow in under 30 seconds per ticket, covering how to identify category, urgency, and correct routing destination. </task> <constraints> Use yes or no branching questions, not open-ended judgment calls. Cover the misrouted example explicitly so it would be caught next time. Keep the whole tree on one page, no more than 15 decision points. </constraints> <format> Return the decision tree as nested bullet points in Markdown, starting from Is this ticket about billing. </format>

You are a Zendesk administrator who translates business rules into trigger logic. <context> I need to set up a Zendesk trigger but I keep getting the condition logic wrong when I try to configure it directly in the admin panel. </context> <inputs> - What should happen: [DESIRED OUTCOME] - When it should happen: [TRIGGERING CONDITION IN PLAIN WORDS] - Fields available to check (priority, tag, form, group): [AVAILABLE FIELDS] - Exceptions where it should NOT fire: [EXCEPTIONS] </inputs> <task> Translate this into a plain-language specification of the trigger's conditions and actions, structured the way Zendesk's trigger builder expects (all of, any of, actions), including the exceptions as explicit exclusion conditions. </task> <constraints> Do not invent field names that were not given, ask for clarification in the Open Questions section instead. Keep conditions as simple as possible, prefer one trigger over one overly complex trigger with many branches. Note if this really needs two separate triggers. </constraints> <format> Return sections: Trigger Name, Conditions (All Of), Conditions (Any Of), Actions, Open Questions. </format>

You are a support queue manager who triages backlogs during high-volume periods. <context> We have a backlog of open tickets after a product outage and I need to decide what order agents should work through them in. </context> <inputs> - List of ticket subjects with age and customer plan tier: [PASTE TICKET LIST] - Number of agents available right now: [NUMBER OF AGENTS] - Any customers under a contractual SLA: [SLA CUSTOMERS] </inputs> <task> Sort the backlog into a worked order, grouping tickets that can likely be resolved with the same macro or answer so agents can batch them. </task> <constraints> SLA customers always come first regardless of age. Do not recommend closing or auto-replying to tickets you cannot confidently group. Explain the reasoning for the top 5 placements only, not every ticket. </constraints> <format> Return a numbered worked order list, then a Batching Opportunities section grouping similar tickets, then a short Reasoning section for the top 5. </format>

You are a support operations lead responsible for SLA compliance in Zendesk. <context> We keep breaching first-response SLA on a subset of tickets and I want a checklist agents follow the moment a ticket is close to breaching. </context> <inputs> - SLA target: [SLA TIME] - Escalation contact for breaches: [ESCALATION CONTACT] - Common reason tickets stall near breach: [COMMON STALL REASON] </inputs> <task> Write a short checklist an agent follows when a ticket hits 80 percent of its SLA window unanswered, covering what to check, who to notify, and what to tell the customer if a reply still is not ready. </task> <constraints> Keep the checklist to 5 steps or fewer. Include a customer-facing holding message as one of the steps, not just internal actions. Address the common stall reason directly as one checklist item. </constraints> <format> Return a numbered checklist, then a separate short block labelled Holding Message For Customer with the exact text to send. </format>

You are a customer support quality coach who reviews agent replies before they are sent to frustrated customers. <context> An agent drafted a reply that is factually correct but reads as blunt or dismissive, and I want it softened without changing the actual answer. </context> <inputs> - Draft reply text: [PASTE DRAFT REPLY] - Customer's tone in their last message: [CUSTOMER TONE] - Fact that cannot change: [FACT THAT CANNOT CHANGE] </inputs> <task> Rewrite the reply so it acknowledges the customer's frustration and softens the delivery, while keeping the exact same factual answer and outcome. </task> <constraints> Do not add false hope or promise anything the original did not promise. Do not over-apologise, one acknowledgement is enough. Keep length close to the original, do not pad it out. </constraints> <format> Return the rewritten reply only, then a one-line note on what specifically was softened. </format>

You are a brand voice editor who reviews Zendesk replies for consistency with a written style guide. <context> We have a documented tone of voice guide but replies from different agents still read inconsistently, and I want a quick way to check individual replies against it. </context> <inputs> - Draft reply text: [PASTE DRAFT REPLY] - Tone of voice guide, key points: [PASTE TONE GUIDE SUMMARY] - Words or phrases we specifically avoid: [AVOIDED WORDS] </inputs> <task> Check the reply against the guide, flag specific phrases that violate it, and suggest a replacement for each flagged phrase. </task> <constraints> Only flag actual violations of the stated guide, not general writing preferences. If the reply already matches the guide well, say so plainly instead of inventing issues. Keep suggested replacements close in meaning to the original. </constraints> <format> Return a Verdict line (matches guide or needs edits), then a table-style list of flagged phrase, why it violates the guide, suggested replacement. </format>

You are a support communications specialist who adapts replies for clarity across language backgrounds. <context> Our customer's first messages suggest English is not their first language, and I want our reply to be as clear as possible without sounding condescending. </context> <inputs> - Draft reply text: [PASTE DRAFT REPLY] - Signal that English may not be first language: [SIGNAL] - Core instruction the customer needs to follow: [CORE INSTRUCTION] </inputs> <task> Rewrite the reply using shorter sentences, common vocabulary, and explicit step numbering where instructions are involved, while keeping a warm and respectful tone. </task> <constraints> Do not use idioms or figurative language. Do not mention or reference the customer's language ability anywhere in the reply. Avoid words with multiple common meanings where a simpler synonym exists. </constraints> <format> Return the rewritten reply only, in plain text ready to send. </format>

You are an enterprise support lead who tailors communication for high-value accounts. <context> This reply is going to one of our largest accounts and the standard macro tone feels too generic for the relationship we have with them. </context> <inputs> - Draft reply based on standard macro: [PASTE DRAFT REPLY] - Account context (contract size, history, dedicated contact): [ACCOUNT CONTEXT] - Named contact at the account, if any: [CONTACT NAME] </inputs> <task> Rewrite the reply to feel personally written for this account, referencing relevant context naturally, while keeping the same core answer and any policy details unchanged. </task> <constraints> Do not fabricate history or details not given in the account context. Do not offer concessions or exceptions unless explicitly instructed to. Keep it professional, not overly familiar. </constraints> <format> Return the rewritten reply only, ready to send, with the contact's name used naturally in the opening line. </format>

You are a support quality lead who coaches agents out of over-apologising in written replies. <context> One of our agents apologises multiple times in almost every reply, even when the issue is minor, and it is making our team sound unsure of itself. </context> <inputs> - Draft reply text with repeated apologies: [PASTE DRAFT REPLY] - Actual severity of the issue: [ISSUE SEVERITY] - One apology to keep, if any is warranted: [WHICH APOLOGY TO KEEP OR NONE] </inputs> <task> Rewrite the reply keeping at most one acknowledgement of the issue, removing redundant apologies, and replacing them with confident, direct statements of what will happen next. </task> <constraints> Do not remove all empathy, keep exactly the one acknowledgement specified. Do not make the tone cold or robotic in the process of removing apologies. Keep the same factual content and next steps. </constraints> <format> Return the rewritten reply only, then a count comparing apology phrases in the original versus the rewrite. </format>

You are a customer experience manager who follows up personally on low satisfaction scores. <context> A customer left a low CSAT score after their ticket was closed, and I want to reach out without sounding defensive or scripted. </context> <inputs> - CSAT score and any comment left: [SCORE AND COMMENT] - Summary of what happened in the original ticket: [TICKET SUMMARY] - What we can offer to make it right, if anything: [OFFER OR NONE AVAILABLE] </inputs> <task> Draft a short personal follow-up message that acknowledges the specific comment left, asks one clarifying question if the comment is vague, and states clearly what we are doing in response. </task> <constraints> Do not use the phrase we are sorry to hear more than once across the whole message. Do not promise a fix timeline you were not given. If no offer is available, say so honestly rather than dodging the question. </constraints> <format> Return the follow-up message only, under 120 words, ready to send from a named support lead. </format>

You are a customer insights analyst who reads through open-ended CSAT comments to find patterns. <context> We collect a written comment alongside every CSAT score and I have a stack of them from the last month that nobody has read closely. </context> <inputs> - Pasted list of CSAT comments with scores: [PASTE COMMENTS AND SCORES] - Product area these tickets relate to: [PRODUCT AREA] - Time period covered: [TIME PERIOD] </inputs> <task> Group the comments into recurring themes, count how many comments fall into each theme, and pull one representative quote per theme. </task> <constraints> Do not force a comment into a theme if it does not clearly fit, put it in a Miscellaneous group instead. Keep quotes verbatim, do not paraphrase them. Order themes by comment count, highest first. </constraints> <format> Return a ranked list of theme name, comment count, representative quote, then a short Miscellaneous section for anything that did not fit. </format>

You are a customer experience specialist who follows up on strong positive feedback, not just negative feedback. <context> A customer left a high CSAT score with a specific compliment about the agent who helped them, and I want to close the loop with both the customer and the agent. </context> <inputs> - CSAT score and comment: [SCORE AND COMMENT] - Agent name who handled the ticket: [AGENT NAME] - Anything specific the customer praised: [WHAT WAS PRAISED] </inputs> <task> Write two short messages, one thanking the customer briefly for the feedback, and one internal note to the agent's manager highlighting the specific praise for recognition. </task> <constraints> Keep the customer message brief, under 50 words, this is a light touch, not a sales pitch. Do not ask the customer for anything else, like a review or referral, in this message. Make the internal note specific enough to be useful in a performance review. </constraints> <format> Return two labelled sections, Customer Message and Internal Recognition Note. </format>

You are a customer experience program manager designing a lightweight CSAT follow-up sequence in Zendesk. <context> Right now low CSAT scores get no automated follow-up at all, and I want a simple sequence before building anything more complex. </context> <inputs> - Score threshold considered low: [SCORE THRESHOLD] - Team responsible for follow-up: [TEAM NAME] - Current time to first follow-up, if any: [CURRENT RESPONSE TIME OR NONE] </inputs> <task> Design a 3-step follow-up sequence for scores under the threshold, specifying what happens at each step, who owns it, and the timing between steps. </task> <constraints> Keep the sequence to exactly 3 steps, do not over-engineer it into a long workflow. The first step must happen within 24 hours. Specify what stops the sequence early, such as the customer replying. </constraints> <format> Return a numbered sequence of Step, Timing, Owner, Action, then one line stating the stop condition. </format>

You are a support team lead preparing a briefing for a manager about a customer who has left multiple low CSAT scores. <context> One account has left three low CSAT scores over the past two months and I need to brief my manager before we reach out directly. </context> <inputs> - List of the three tickets with scores and comments: [PASTE TICKET LIST] - Account name and plan tier: [ACCOUNT NAME AND TIER] - Any pattern you have already noticed: [PATTERN NOTICED OR NONE YET] </inputs> <task> Write a short briefing summarising the pattern across the three tickets, whether the same root cause shows up each time, and a recommended next action. </task> <constraints> Do not speculate about root cause beyond what the ticket comments actually support. Keep the briefing under 200 words. State the recommended action as one clear sentence, not a list of options. </constraints> <format> Return sections: Summary, Pattern Observed, Recommended Action. </format>

You are a senior support agent who escalates tickets to engineering or a specialist team. <context> I need to escalate a ticket to another team and I want the handoff note to save them time instead of making them re-read the whole thread. </context> <inputs> - Full ticket thread or summary: [PASTE TICKET THREAD] - Team receiving the escalation: [RECEIVING TEAM] - What has already been tried: [WHAT WAS ALREADY TRIED] - Customer's business impact, if known: [BUSINESS IMPACT] </inputs> <task> Write a handoff note that states the problem, what has already been ruled out, and exactly what you need from the receiving team. </task> <constraints> Do not repeat the full thread verbatim, summarise it. Be explicit about what you need, a fix, a workaround, or just confirmation of a bug. Keep it under 150 words so a busy engineer will actually read it. </constraints> <format> Return sections: Problem, Already Ruled Out, What I Need, Business Impact. </format>

You are a support agent who files bug reports for engineering based on customer tickets. <context> A customer described a bug in their own words and I need to turn that into a structured bug report engineering can act on. </context> <inputs> - Customer's description of the issue, in their words: [PASTE CUSTOMER DESCRIPTION] - Steps you took to try to reproduce it: [REPRODUCTION STEPS TRIED] - Browser, app version, or environment details given: [ENVIRONMENT DETAILS] - Whether you could reproduce it yourself: [COULD REPRODUCE, YES OR NO] </inputs> <task> Write a structured bug report with a clear title, expected versus actual behaviour, and reproduction steps, translating the customer's informal description into precise technical language. </task> <constraints> Do not guess at a root cause, describe symptoms only. Mark clearly if reproduction failed or was not attempted. Keep the title under 10 words and specific enough to search for later. </constraints> <format> Return sections: Title, Expected Behaviour, Actual Behaviour, Steps To Reproduce, Environment, Reproduced By Agent (Yes or No). </format>

You are a support agent managing a customer whose issue is stuck waiting on an engineering fix. <context> A customer has been waiting several days for an engineering fix and I need to send an update even though there is no resolution yet. </context> <inputs> - Days the customer has been waiting: [NUMBER] days - What engineering has told you so far: [ENGINEERING UPDATE] - Whether there is a workaround available: [WORKAROUND OR NONE] </inputs> <task> Write a status update that is honest about the lack of resolution, states what is actually known, and offers the workaround if one exists. </task> <constraints> Do not invent a timeline that engineering did not give you. Do not use vague filler like we are working hard on this without saying what that means. If no workaround exists, say so plainly rather than avoiding the topic. </constraints> <format> Return the update message only, under 100 words, ready to send. </format>

You are a support agent handing a difficult ticket to your manager because the customer has asked to speak to someone more senior. <context> A customer asked to escalate to a manager and I need to brief my manager quickly before they respond. </context> <inputs> - Full ticket thread or summary: [PASTE TICKET THREAD] - Why the customer escalated, in their words: [REASON FOR ESCALATION] - What you have already offered: [WHAT WAS OFFERED] </inputs> <task> Write a brief manager briefing covering the core issue, what has already been offered and declined, and your honest read on what the customer actually wants. </task> <constraints> Be honest even if it reflects on your own handling of the ticket, do not omit a mistake to look better. Keep it under 120 words. State your read on what the customer wants as one sentence, not a hedge. </constraints> <format> Return sections: Core Issue, Already Offered, My Read. </format>

You are a support operations lead writing a customer-facing summary after an incident affecting multiple accounts. <context> We had an incident that affected a number of customer accounts and I need to send a clear summary once it is resolved. </context> <inputs> - What happened, internal summary: [PASTE INTERNAL INCIDENT SUMMARY] - Duration of the incident: [DURATION] - What was done to fix it and prevent recurrence: [FIX AND PREVENTION STEPS] </inputs> <task> Write a customer-facing summary explaining what happened, how long it lasted, and what is being done to prevent it happening again, without exposing internal system details that are not relevant to customers. </task> <constraints> Do not use internal codenames, ticket numbers, or system names customers would not recognise. Be specific about duration and impact, do not round it down. Avoid defensive language that minimises what happened. </constraints> <format> Return the summary as a message ready to send or post, under 200 words, with a heading What Happened. </format>