50 Claude Prompts That Handle Support Work

You are a support operations manager who defines exactly when a ticket leaves tier one. <context> My agents either escalate everything or nothing, and both are expensive. I need a decision tree they can follow in ten seconds. </context> <inputs> - Our support tiers and who is in each: [STRUCTURE] - Escalation destinations: [TIER 2, ENGINEERING, BILLING, LEGAL, MANAGER] - Issue types we handle: [LIST] - Current escalation problems: [OVER, UNDER, WRONG DESTINATION] - SLA commitments by tier or plan: [SLAS] - Authority limits for tier one: [REFUND CAP, CREDIT CAP, POLICY EXCEPTIONS] </inputs> <task> Build the decision tree: the triggers that mandate escalation immediately, the triggers that mandate solving in tier one, the grey zone with the two questions that resolve it, the correct destination per trigger, the information package required at handoff, and the response time expectation at each destination. Add five worked examples using real-sounding tickets and the correct routing for each. </task> <constraints> - Every branch ends in a named destination or an explicit "solve here". - No branch may require judgement an agent lacks the authority to exercise. - Keep the tree shallow enough to hold in your head. </constraints> <format> The tree as nested numbered conditions, then a trigger-to-destination table, then the handoff information checklist, then the five worked examples. </format>

You are a support policy designer who makes refund decisions consistent and defensible. <context> Refund calls vary by whoever is on shift, which creates unfair outcomes and awkward escalations. I need a framework agents apply the same way. </context> <inputs> - Our refund policy as written: [POLICY] - Product type and billing model: [SUBSCRIPTION, ONE-OFF, USAGE] - Common refund request reasons: [LIST] - Agent authority limits: [AMOUNTS AND CONDITIONS] - Regional consumer law obligations: [REGIONS] - What matters more to us right now: [MARGIN OR RETENTION] </inputs> <task> Build the framework: the categories of refund request, the decision for each with the reasoning, where the law overrides our policy, the alternatives to a full refund ranked by cost including credit, extension, downgrade, and partial refund, the conditions that justify a goodwill exception, and the documentation required for every decision. Add a table showing the decision for ten realistic scenarios. </task> <constraints> - Statutory rights always win over internal policy; call those out explicitly. - Never make approval depend on how persistent the customer is. - Every exception must be logged with a reason code. </constraints> <format> Category decision table, legal override notes, alternatives ranked by cost, exception criteria, documentation rules, ten worked scenarios. </format>

You are a billing support specialist who confirms refunds so clearly that no follow-up ticket appears. <context> I am approving a refund and I want the message to remove every question the customer would otherwise ask next week. </context> <inputs> - Refund amount and currency: [AMOUNT] - What is being refunded and for which period: [SCOPE] - Original payment method and processing time: [METHOD AND DAYS] - What happens to their account and access: [CANCELLED, DOWNGRADED, UNCHANGED] - Reason for the refund: [REASON] - Any conditions or partial elements: [DETAILS] </inputs> <task> Write the confirmation: the approved amount and scope in the first line, the exact processing timeline and what they will see on their statement, what happens to their access and data, whether any part of the request was not refunded and why, and a closing that leaves the door open without inviting a new dispute. Then write the internal note with reason code and the pre-emptive answer to "it has not arrived yet". </task> <constraints> - State the amount and the timeline before anything else. - Name what will appear on the statement, including the merchant descriptor. - Do not add a retention pitch into a refund confirmation. </constraints> <format> Customer confirmation, internal note with reason code, and the "where is my refund" follow-up reply. </format>

You are a support specialist who denies a refund without triggering a chargeback. <context> A refund request falls outside our policy and the law does not require it. I need a reply that holds the line and still leaves the customer with something. </context> <inputs> - Their request and stated reason, pasted: [MESSAGE] - The policy section that applies: [POLICY TEXT] - Why the law does not require a refund here: [REASONING] - What I can offer instead: [CREDIT, EXTENSION, HELP, DOWNGRADE] - Their history and account value: [CONTEXT] - Chargeback risk level: [LOW, MEDIUM, HIGH] </inputs> <task> Write the denial: acknowledge their situation specifically, state the decision clearly in one sentence rather than burying it, cite the policy in plain language with the where and when, explain the reasoning so it does not feel arbitrary, offer the best alternative concretely, and give them the escalation path. Then list the three sentences most likely to trigger a chargeback and the safer phrasing. </task> <constraints> - Decision in the first three sentences; no long preamble. - Never quote policy without explaining it in plain language. - Always offer an escalation path and a real alternative. </constraints> <format> The reply, then the chargeback-risk phrasing notes, then a short internal note documenting the decision and the offer made. </format>

You are a payments dispute analyst who assembles chargeback responses that win. <context> A customer disputed a charge with their bank. I need to assemble the evidence and write the response before the deadline. </context> <inputs> - Dispute reason code and amount: [CODE AND AMOUNT] - What the customer bought and when: [PURCHASE DETAILS] - Evidence available: [LOGIN LOGS, USAGE DATA, EMAILS, IP, TERMS ACCEPTANCE, DELIVERY PROOF] - Support history with this customer: [SUMMARY] - Our terms and refund policy text: [RELEVANT SECTIONS] - Response deadline: [DATE] </inputs> <task> Assemble the response: a factual narrative of the transaction and the customer relationship in chronological order, the evidence list mapped to what each item proves against the specific reason code, the strongest three exhibits ranked, the gaps in our evidence and how to phrase around them honestly, and the compelling-evidence summary paragraph. Then say whether defending or accepting is the better call and why. </task> <constraints> - Facts and dates only in the narrative; no emotional language. - Map each exhibit to the reason code being disputed, not to a general story. - If the evidence is weak, recommend accepting rather than fighting. </constraints> <format> Chronological narrative, evidence-to-argument mapping table, top three exhibits, evidence gaps, summary paragraph, defend-or-accept recommendation. </format>

You are a support engineer who writes handoff notes that never get sent back for more information. <context> I am escalating a technical ticket to tier two or engineering. Their first response is usually a request for details I should have included. </context> <inputs> - Customer issue in their words: [MESSAGE] - What I have already tried and the result: [TROUBLESHOOTING LOG] - Reproduction status: [REPRODUCED, NOT REPRODUCED, INTERMITTENT] - Environment details: [BROWSER, OS, VERSION, PLAN, REGION] - Account and impact: [SCOPE AND URGENCY] - Logs, IDs, or timestamps available: [DATA] </inputs> <task> Write the handoff note: a one-line summary an engineer can triage from, expected versus actual behaviour, numbered reproduction steps or an explicit statement that it could not be reproduced with what was tried, the environment block, the impact and urgency with the number of affected accounts, everything already ruled out so nobody repeats it, and the specific question I need answered. Then write the customer-facing holding message. </task> <constraints> - Separate observed facts from my hypothesis; label the hypothesis clearly. - Include exact timestamps with time zone and any request or trace IDs. - One specific ask, not "please look into this". </constraints> <format> Structured handoff note with headed sections, then the customer holding message, then a checklist of what to attach. </format>

You are a retention specialist working a support ticket that is really a cancellation signal. <context> A customer is frustrated and hinting at leaving. I need a save play that is honest rather than a discount reflex. </context> <inputs> - Their messages and the frustration trail: [HISTORY] - Root cause of the frustration: [DIAGNOSIS] - Their original goal in buying us: [JOB TO BE DONE] - Usage pattern: [ACTIVE AREAS AND UNUSED FEATURES] - What I can offer: [FIX, CREDIT, SUPPORT TIME, PLAN CHANGE, EARLY ACCESS] - Their value and renewal date: [CONTEXT] </inputs> <task> Build the save play: the diagnosis of what they actually need versus what they asked for, the reply that addresses the root cause first, the offer sequence starting with the non-discount options, the questions that reveal whether this is savable at all, the moment to stop trying and make leaving easy, and the internal handoff to account management if needed. Include a version for a customer who has already asked to cancel. </task> <constraints> - Never lead with a discount; a discount does not fix a broken workflow. - Do not obstruct cancellation or hide the path to it. - Be explicit about when the honest answer is that we are not the right tool. </constraints> <format> Diagnosis, reply copy, offer ladder with costs, savable-or-not questions, stop-trying signal, already-cancelling variant. </format>

You are an incident commander planning customer communications for a major failure. <context> We had a significant incident affecting many customers. I need the full comms timeline, not just a status page line. </context> <inputs> - What happened and confirmed impact: [DETAILS] - Duration and number of customers affected: [SCOPE] - Data loss or security implications: [YES OR NO WITH DETAILS] - What we fixed and what remains: [STATUS] - Contractual or regulatory notification duties: [OBLIGATIONS] - Audiences: [ALL CUSTOMERS, ENTERPRISE, AFFECTED ONLY, PUBLIC] </inputs> <task> Build the comms timeline: who hears what and when, from the first hour through the post-incident report, with a message for each audience and channel. Include the enterprise account manager briefing, the affected-customers email, the all-customers note if warranted, the support macro for inbound tickets, and the public post-incident summary covering cause, impact, fix, and prevention. Flag anything that needs legal or security review before sending. </task> <constraints> - Never state a cause before it is confirmed; use confirmed status language. - Match the level of detail to the audience and their contract. - Do not minimise impact; understating it costs more later. </constraints> <format> Timeline table with Time, Audience, Channel, Message purpose, Owner. Then the message drafts. Then the review flags. </format>

You are a support lead who responds to a legal threat without escalating it or admitting liability. <context> A customer has mentioned lawyers, regulators, or a public complaint. I need a measured holding reply while this goes to the right people internally. </context> <inputs> - Their message, pasted in full: [MESSAGE] - The underlying complaint: [SUMMARY] - What actually happened on our side: [FACTS] - Who internally must be looped in: [LEGAL, SECURITY, EXEC, DPO] - What I am authorised to say: [LIMITS] - Region and applicable regime: [JURISDICTION] </inputs> <task> Write the holding reply: acknowledge receipt and the seriousness without conceding anything, state that it is being reviewed by the right team, give a specific timeframe for a substantive response, provide the correct channel for formal correspondence, and avoid any sentence that could be read as an admission. Then write the internal escalation summary with the facts, the risk, and the recommended next step. List the phrases I must not use. </task> <constraints> - No admission of fault, no apology that implies liability, no speculation about cause. - Do not offer compensation without authorisation. - Nothing in the reply may contradict a fact in the internal summary. </constraints> <format> Customer holding reply, internal escalation summary, do-not-say phrase list. Note clearly that this is not legal advice and needs review. </format>

You are a customer recovery specialist who repairs a relationship after a badly handled ticket. <context> We handled something poorly, the customer escalated, and now the issue is fixed but trust is not. I need a make-good plan. </context> <inputs> - What went wrong, including our handling failures: [FULL HONEST ACCOUNT] - Impact on the customer: [BUSINESS IMPACT] - What we have already done: [ACTIONS TAKEN] - What I can offer as a make-good: [OPTIONS AND LIMITS] - Their relationship value and history: [CONTEXT] - Who should deliver the apology: [AGENT, MANAGER, EXEC] </inputs> <task> Build the recovery plan: the apology message that names our specific failures rather than apologising generically, the concrete make-good and why it fits the harm caused, the process change we are making so it does not recur stated as a commitment we can keep, the follow-up cadence over the next 60 days with owners, and the internal retro prompt for the team. Include the version delivered by phone or call. </task> <constraints> - Apologise for the specific failures, including the handling, not just the original issue. - Only commit to process changes that will actually happen. - The make-good should be proportionate to the harm, not to their contract size. </constraints> <format> Apology message, make-good with rationale, process commitment, 60-day follow-up plan with owners, call script version, internal retro prompt. </format>

You are a technical writer who converts solved tickets into help center articles. <context> I just solved a ticket that keeps recurring. I want it turned into a proper article instead of re-explaining it next week. </context> <inputs> - The full ticket thread, pasted: [THREAD] - The final solution: [WHAT WORKED] - Product area and plan tiers affected: [SCOPE] - Related existing articles: [TITLES OR LINKS] - Search terms customers would use: [PHRASES] - Reading level and audience: [LEVEL] </inputs> <task> Write the article: a title using the customer search phrasing, a one-line summary of what the article solves, who it applies to including plan limits, numbered steps with the expected result after each, a troubleshooting section for the two most likely failure points, what to do if it still does not work, and related links. Then give three alternate titles for search and the metadata description. </task> <constraints> - Title in the customer words, not our internal feature name. - Every step must state what the reader should see when it worked. - No screenshots referenced; steps must stand alone as text. </constraints> <format> The article in clean markdown headings, then alternate titles, then the meta description, then the macro version for agents to send. </format>

You are a support content designer who writes troubleshooting guides that actually deflect tickets. <context> One problem generates tickets with many different causes. I need a decision-based guide that gets customers to the right fix themselves. </context> <inputs> - The symptom customers report: [SYMPTOM IN THEIR WORDS] - Known causes with rough frequency: [CAUSES AND PERCENTAGES] - Diagnostic checks a customer can run: [CHECKS] - Fix for each cause: [FIXES] - When they must contact us: [ESCALATION CONDITIONS] - Environments affected: [PLATFORMS AND VERSIONS] </inputs> <task> Write the guide as a decision path: start with the fastest diagnostic that splits the causes, order branches by frequency so most readers finish in two steps, give each branch a clear fix with numbered actions and a verification step, and end every dead-end branch with what to send us so the ticket arrives complete. Add a "before you start" checklist and a "what to include if you contact us" block. </task> <constraints> - Order by frequency, not by technical elegance. - Each diagnostic must be something a non-technical customer can perform. - No branch may end without either a fix or a contact instruction. </constraints> <format> Before-you-start checklist, then the decision path with numbered branches and verification steps, then the contact-us information block. </format>

You are a support content strategist who builds FAQ pages from data rather than guesses. <context> I have ticket data and want an FAQ page that answers what people actually ask, in the order they ask it. </context> <inputs> - Top ticket subjects with volume: [DATA] - Search queries from our help center: [DATA IF AVAILABLE] - Pre-sale versus post-sale question split: [NOTES] - Answers as we currently give them: [CURRENT REPLIES] - Plan or region differences that change answers: [RULES] - Where the FAQ will live: [WEBSITE, HELP CENTER, IN-APP] </inputs> <task> Build the FAQ: questions phrased exactly as customers ask them, ordered by volume, each answered in under 80 words with the direct answer first, grouped into three or four sections, with a link target for the longer article where one is needed. Then list the five questions where the answer reveals a product or policy problem worth fixing instead of documenting, and the questions to leave off the page and why. </task> <constraints> - Answer first, context second, in every entry. - Use customer phrasing verbatim in the questions. - Flag any question where the honest answer would hurt us, and say what to fix. </constraints> <format> Grouped FAQ with questions and answers, then the fix-do-not-document list, then the leave-off list with reasons. </format>

You are a support operations lead who designs a macro library that stays maintainable. <context> Our macros are a mess of duplicates and outdated text. I want a clean library built from scratch around our real ticket mix. </context> <inputs> - Ticket reasons with volume: [DATA] - Current macros, pasted or listed: [EXISTING] - Helpdesk tool and variable syntax: [TOOL] - Naming convention preference: [CONVENTION] - Team size and agent experience mix: [CONTEXT] - Channels: [EMAIL, CHAT, SOCIAL] </inputs> <task> Design the library: a category structure mapped to ticket reasons, the macro list per category with a name following one convention, the text for the top 15 macros by volume, the variables each uses, which are safe for a new agent versus which need judgement, the duplicates in my current set to merge or delete, and a quarterly review process with an owner. </task> <constraints> - One macro per intent; no near-duplicates. - Every macro must be editable by the agent, never a locked send-as-is block. - Name macros so they are findable by typing what the customer asked. </constraints> <format> Category structure, macro inventory table with Name, Intent, Channel, Variables, New-agent safe, then the 15 macro texts, then the merge and delete list, then the review process. </format>

You are a conversation designer who writes bot content that hands off gracefully. <context> We are setting up an automated first-line assistant and I need intents, answers, and clean escalation paths written properly. </context> <inputs> - Top ticket intents with volume: [DATA] - Real customer phrasings per intent: [EXAMPLES] - Answers and the data the bot can access: [WHAT IT KNOWS] - What the bot must never attempt: [RESTRICTED TOPICS] - Handoff options and hours: [HUMAN AVAILABILITY] - Brand voice: [DESCRIPTION] </inputs> <task> For each intent, write the intent name, 8 to 12 training phrases covering real variation including typos and short forms, the answer under 60 words, the follow-up question that confirms resolution, and the handoff trigger with the message that hands over including the context it passes to the agent. Then write the fallback message for unrecognised input and the honest "I am an assistant" disclosure. </task> <constraints> - The bot must never guess about billing, security, or account access; those hand off immediately. - Every answer needs an escape hatch to a human in one tap. - Disclose that it is automated up front. </constraints> <format> One block per intent with Name, Training phrases, Answer, Confirmation, Handoff trigger and message. Then fallback and disclosure copy, then a list of intents to leave out of automation. </format>

You are a product communicator who writes release notes customers read to the end. <context> Engineering gave me a changelog full of internal language. I need customer-facing release notes that drive adoption and pre-empt confusion tickets. </context> <inputs> - The raw changelog, pasted: [CHANGELOG] - Audience: [ALL USERS, ADMINS, DEVELOPERS] - Which changes are visible to customers: [LIST] - Breaking changes or removed behaviour: [LIST] - Plan availability per change: [TIER RULES] - Where this publishes: [EMAIL, IN-APP, DOCS, BLOG] </inputs> <task> Write the release notes: a headline change stated as a customer outcome, the other improvements grouped as New, Improved, and Fixed with each entry saying what changed and why it matters, breaking changes called out at the top with the action required and a date, plan availability marked per item, and a short link list to relevant docs. Then write the in-app announcement and the two-sentence email version. </task> <constraints> - No internal component names, ticket numbers, or refactor notes. - Lead with the change that affects the most customers, not the biggest engineering effort. - Breaking changes appear above the good news, never buried below it. </constraints> <format> Full release notes, then the in-app announcement, then the email version. Then flag the two changes most likely to generate tickets and the pre-emptive macro for each. </format>

You are an instructional designer scripting short support videos. <context> One workflow is hard to explain in text and generates repeat tickets. I want a script for a short screen recording. </context> <inputs> - The workflow to demonstrate: [TASK] - Where users get stuck: [FRICTION POINTS] - Target length: [SECONDS OR MINUTES] - Audience familiarity: [NEW USER OR EXPERIENCED] - Product screens involved: [SCREEN LIST] - Accessibility requirements: [CAPTIONS, NO AUDIO CUES] </inputs> <task> Write the script: a hook in the first 8 seconds that names the outcome, the numbered on-screen actions with the exact narration for each, the moment to slow down at each known friction point, the on-screen text callouts to overlay, a closing that states what to do if it did not work, and the full caption file text. Add a shot list a non-editor can follow and the thumbnail text. </task> <constraints> - Narration must never say "simply" or "just". - Every click must be narrated in the same order it happens on screen. - Keep it inside the target length; cut scope rather than speeding up. </constraints> <format> Two-column script with Screen action and Narration, then callout text list, then caption text, then shot list and thumbnail copy. </format>

You are an information architect restructuring a help center around customer tasks. <context> Our help center is organised by product menu, so customers cannot find anything and tickets keep coming. I need a task-based structure. </context> <inputs> - Current category structure: [LIST] - Article inventory with traffic: [DATA] - Top search queries and zero-result searches: [DATA] - Top ticket reasons: [DATA] - Customer segments and their goals: [SEGMENTS] - Platform constraints: [TOOL LIMITS] </inputs> <task> Design the new structure: top-level categories named after customer tasks, subcategories with the articles that belong in each, the articles to merge, retire, or rewrite based on traffic and ticket data, the missing articles the zero-result searches reveal, the navigation labels in customer language, and a redirect plan for changed URLs. Then rank the migration in phases by impact. </task> <constraints> - Categories must reflect what customers are trying to do, not our product menu. - Every existing URL needs a redirect target; nothing 404s. - Maximum three clicks from home to any article. </constraints> <format> Proposed structure as a nested tree with article assignments, then the merge and retire list, then the content gap list from zero-result searches, then the redirect map and phased migration plan. </format>

You are a plain-language editor who rewrites help articles people currently give up on. <context> We have an article that gets traffic but still generates tickets on the same topic, which means it is not doing its job. </context> <inputs> - The article, pasted in full: [ARTICLE] - Ticket volume on this topic despite the article: [DATA] - What customers still ask after reading it: [QUESTIONS] - Target reading level: [LEVEL] - Audience technical ability: [LEVEL] - Constraints: [LEGAL WORDING, PRODUCT TERMS THAT MUST STAY] </inputs> <task> Diagnose why the article fails, quoting the specific passages: buried answer, assumed knowledge, missing prerequisite, ambiguous step, or unstated failure case. Then rewrite it with the answer first, prerequisites stated up front, numbered steps each with a verification result, and a troubleshooting section covering the questions people still ask. Report the reading level before and after and confirm the required wording survived. </task> <constraints> - Do not change any factual instruction; if a step is wrong, flag it instead of guessing. - Keep required legal and product wording exactly. - Cut length wherever it does not cost clarity. </constraints> <format> Diagnosis with quotes, the full rewrite, before and after reading level and word count, and the list of still-asked questions the rewrite now answers. </format>

You are a support quality lead auditing saved replies for accuracy and tone drift. <context> Our saved replies have not been reviewed in a long time. Some are wrong, some are stale, and some sound nothing like us anymore. </context> <inputs> - All current macros or saved replies, pasted: [CONTENT] - Usage counts per macro if available: [DATA] - Product changes since they were written: [CHANGES] - Current voice guide: [GUIDE OR DESCRIPTION] - Policy changes since last review: [CHANGES] - Customer complaints about our replies: [EXAMPLES] </inputs> <task> Audit every reply. For each, state whether it is accurate, stale, tone-drifted, duplicated, or should be deleted, with the specific reason and quoted evidence. Rank fixes by usage volume times severity so the most-sent broken macro gets fixed first. Rewrite the top five worst offenders in full. Then define the review cadence, the owner, and the trigger events that force an out-of-cycle review. </task> <constraints> - Judge accuracy against the product changes I listed, not against assumptions. - Prioritise by how often a macro is actually sent. - Recommend deletion where a macro has near-zero use and a duplicate exists. </constraints> <format> Audit table with Macro, Verdict, Evidence, Priority. Then the five full rewrites. Then the review cadence with owner and triggers. </format>

You are a support quality manager who designs QA scorecards agents accept as fair. <context> Our QA reviews feel arbitrary and agents dispute the scores. I need a scorecard with criteria and anchors everyone can agree on. </context> <inputs> - Channels we review: [EMAIL, CHAT, PHONE] - What we care about most: [ACCURACY, TONE, EFFICIENCY, COMPLIANCE, RESOLUTION] - Current QA process and score disputes: [CONTEXT] - Team experience mix: [CONTEXT] - Compliance requirements: [MANDATORY ELEMENTS] - Review volume per agent per month: [NUMBER] </inputs> <task> Build the scorecard: five to seven criteria with weights, each scored with written anchors describing what full, partial, and no credit look like, an auto-fail list for compliance breaches, a rule for when a criterion does not apply, a target score with the reasoning, and the coaching note template a reviewer fills in. Add three worked examples showing a strong, average, and weak ticket with scores and justification. </task> <constraints> - Anchors must describe observable behaviour in the ticket, not reviewer impressions. - Weights must total 100 and reflect what actually matters to customers. - Every score below full credit requires a quoted example from the ticket. </constraints> <format> Weighted criteria table with anchors, auto-fail list, not-applicable rule, coaching note template, three worked examples. </format>

You are a QA reviewer who gives feedback agents can act on tomorrow. <context> I need to review a real support conversation against our scorecard and write coaching feedback that is specific rather than deflating. </context> <inputs> - The full conversation, pasted: [TRANSCRIPT] - Our QA scorecard criteria and weights: [SCORECARD] - Agent experience level: [TENURE] - Ticket outcome: [RESOLVED, ESCALATED, ABANDONED] - Any customer feedback received: [CSAT OR COMMENT] - Context the agent had at the time: [WHAT THEY KNEW] </inputs> <task> Review it: score each criterion with a quoted justification, identify the single highest-impact improvement rather than listing everything, note what the agent did well with specific quotes, rewrite the two weakest messages showing the better version, and write the coaching note as feedback to the agent in under 150 words. Then say whether the outcome was a process failure rather than an agent failure. </task> <constraints> - Judge the agent on what they knew at the time, not on hindsight. - One primary improvement, not a list of eight. - Separate process failures from agent performance explicitly. </constraints> <format> Scores with quoted justification, strengths, two rewritten messages, coaching note to the agent, process-versus-agent verdict. </format>

You are a support data architect who designs tag taxonomies that survive contact with a real team. <context> Our tags are a free-for-all so our reporting is useless. I need a taxonomy that is small enough to be used correctly and useful enough to drive decisions. </context> <inputs> - Current tags, pasted: [TAG LIST] - Questions we want the data to answer: [QUESTIONS] - Product areas and features: [STRUCTURE] - Who tags and when: [PROCESS] - Helpdesk tagging capabilities: [SINGLE, MULTI, HIERARCHICAL] - Team size: [NUMBER] </inputs> <task> Design the taxonomy: dimensions with the values in each, for example contact reason, product area, root cause, and resolution type, keeping each dimension short enough to pick from a dropdown. Map every current tag to a new value or to delete. State the mandatory dimension at close time and the optional ones. Show how each dimension answers one of my questions, and write the one-page tagging guide with five worked examples. </task> <constraints> - Maximum 15 values per dimension; if you exceed that, the dimension is wrong. - Every dimension must answer a question I listed, or it does not exist. - Values must be mutually exclusive within a dimension. </constraints> <format> Dimension tables with values and definitions, old-tag migration map, mandatory-versus-optional rules, question-to-dimension mapping, tagging guide with examples. </format>

You are a support automation analyst who writes classification rules from real ticket language. <context> Manual tagging is inconsistent. I want rules that classify tickets from their text so my reporting stops depending on agent discipline. </context> <inputs> - Sample tickets with their correct tags, pasted: [SAMPLES] - Target taxonomy: [DIMENSIONS AND VALUES] - Automation capability: [KEYWORD RULES, REGEX, AI CLASSIFIER] - Volume per day: [NUMBER] - Cost of a wrong tag: [LOW OR HIGH] - Languages in scope: [LIST] </inputs> <task> Write the rules: for each tag, the trigger phrases and patterns drawn from my real samples, the negative conditions that prevent false positives, the precedence order when several rules match, the confidence threshold below which a ticket stays untagged for human review, and the ambiguous cases automation should never attempt. Then propose a test plan using held-back samples and the accuracy bar to hit before going live. </task> <constraints> - Derive triggers from my actual samples, not from generic assumptions. - Prefer leaving a ticket untagged over applying a wrong tag when the cost is high. - Note every rule likely to misfire and the phrase that will cause it. </constraints> <format> Rule table with Tag, Triggers, Negative conditions, Precedence, Confidence note. Then the leave-to-humans list, then the test plan with accuracy bar. </format>

You are a customer insights analyst who turns raw support text into a report other teams act on. <context> I have a pile of tickets, reviews, and survey comments. Leadership wants themes, not anecdotes, and product wants something specific enough to build against. </context> <inputs> - The raw text, pasted or summarised: [DATA] - Time period and volume: [PERIOD AND COUNT] - Segments to compare: [PLAN, REGION, TENURE] - Business questions to answer: [QUESTIONS] - What changed in the product this period: [RELEASES] - Audience for the report: [EXEC, PRODUCT, SUPPORT] </inputs> <task> Produce the report: five to eight themes ranked by frequency and severity, each with a plain-language description, representative verbatim quotes, the segments it concentrates in, the likely root cause, and the owning team. Then give the three themes worth acting on this quarter with the reasoning, the themes that are noise, and what changed versus the previous period. State clearly where the sample is too small to conclude. </task> <constraints> - Rank by frequency times severity, not by how loudly it was said. - Use real verbatim quotes; never invent a quote. - Label any conclusion drawn from fewer than ten mentions as directional only. </constraints> <format> Theme table with Frequency, Severity, Segment, Root cause, Owner. Then verbatim quotes per theme, then the act-on-three, the noise list, and the period comparison. </format>

You are a support operations analyst who kills recurring tickets at the source. <context> The same issue keeps coming back and we keep answering it individually. I want the analysis that gets it fixed upstream. </context> <inputs> - The recurring issue and monthly volume: [ISSUE AND COUNT] - Sample tickets, pasted: [SAMPLES] - Average handle time on these tickets: [MINUTES] - What we currently tell customers: [CURRENT REPLY] - Where in the product or journey it originates: [SUSPECTED SOURCE] - Who owns that area: [TEAM] </inputs> <task> Run the analysis: the actual trigger sequence that produces this ticket, why our current answer does not stop it recurring, the cost in agent hours per month and per year, three upstream fixes ranked by cost of implementation against tickets eliminated, the interim deflection to apply this week, and the one-paragraph business case to hand to the owning team with the numbers in it. </task> <constraints> - Quantify the cost in hours and money using the handle time I gave you. - Separate a documentation fix from a product fix; they have different owners. - Give one interim action that can ship this week without engineering. </constraints> <format> Trigger sequence, why current answer fails, cost model, ranked fixes with effort, interim deflection, business case paragraph. </format>

You are a support analyst who reads every survey comment so your manager does not have to. <context> We collect CSAT and nobody reads the comments beyond the score. I want a digest that explains the number and points at fixes. </context> <inputs> - All comments with scores, pasted: [DATA] - Period and response count: [DETAILS] - Score by agent, channel, or queue: [BREAKDOWN] - Score trend versus last period: [DATA] - Known incidents during the period: [EVENTS] - Survey question wording: [QUESTION] </inputs> <task> Write the digest: the score with the honest explanation of what moved it, the drivers of low scores ranked with the count and representative quotes, the drivers of high scores so we know what to protect, the comments that are about the product rather than the support interaction separated out, the agents or queues that need coaching versus those with a structural problem, and the three actions for next period. Note any response bias in the sample. </task> <constraints> - Separate support-quality drivers from product-quality drivers; they get different owners. - Do not treat a low score with no comment as evidence of anything specific. - Flag survey timing or wording effects that distort the result. </constraints> <format> Score explanation, low-score drivers table with counts and quotes, high-score drivers, product-versus-support split, coaching versus structural list, three actions, bias note. </format>

You are a support insights lead who writes product briefs that get onto a roadmap. <context> I keep sending product a list of complaints and nothing happens. I need a brief written the way product teams make decisions. </context> <inputs> - The problem area and evidence: [TICKETS, QUOTES, COUNTS] - Affected customers and segments: [WHO AND HOW MANY] - Revenue exposure: [ARR AT RISK OR BLOCKED DEALS] - Support cost of the status quo: [HOURS OR TICKETS PER MONTH] - Current workaround and its limits: [WORKAROUND] - Product team priorities this quarter: [KNOWN PRIORITIES] </inputs> <task> Write the brief: the problem in one sentence from the customer point of view, the evidence with counts and verbatim quotes, the segments and revenue affected, the current cost to support and to customers, what customers currently do instead, the smallest change that would remove most of the pain, and how this connects to a priority the product team already owns. End with the one decision I am asking for. </task> <constraints> - Quantify everything you can; label estimates as estimates. - Propose the smallest viable change, not a feature wish list. - Connect to their existing priority rather than competing with it. </constraints> <format> Problem statement, evidence with counts and quotes, impact by segment and revenue, cost of status quo, current workaround, smallest fix, priority connection, the one ask. </format>

You are a support strategy analyst who finds which tickets should never have been tickets. <context> My volume is growing faster than my team. I need to know where self-service or product changes could remove contacts entirely. </context> <inputs> - Ticket volume by reason: [DATA] - Average handle time by reason: [DATA] - Existing help content per reason: [WHAT EXISTS] - Help center traffic and search data: [DATA IF AVAILABLE] - Product surfaces where the question arises: [SCREENS OR FLOWS] - Team capacity and cost per ticket: [NUMBERS] </inputs> <task> Analyse deflection potential: for each high-volume reason, whether it is deflectable by content, by product change, by proactive messaging, or not at all, with the reason. Estimate the deflectable share and the hours saved. Rank the opportunities by hours saved against effort. Name the tickets that must stay human and why. Then give the top three actions with owners and the measurement plan to prove deflection actually happened. </task> <constraints> - Do not claim deflection for issues where the customer needs a decision or an account action. - Estimate conservatively and state the assumption behind every percentage. - Measurement must be volume per reason, not help center pageviews. </constraints> <format> Opportunity table with Reason, Volume, Handle time, Deflection method, Estimated share, Hours saved, Effort. Then the must-stay-human list, the top three actions, and the measurement plan. </format>

You are a support manager who turns QA data into a coaching plan an agent can follow. <context> An agent has QA scores below target and I need a plan that improves the specific behaviour rather than a general talk about doing better. </context> <inputs> - Their QA scores by criterion over recent months: [DATA] - Two or three example tickets with issues, pasted: [TICKETS] - Their strengths: [WHAT THEY DO WELL] - Tenure and previous coaching: [HISTORY] - Their own view of the problem: [THEIR WORDS] - Team target and timeline: [TARGETS] </inputs> <task> Build a 30-day coaching plan: the one or two behaviours to change, chosen by impact rather than by lowest score, the evidence from their real tickets, what the better version looks like written out, the weekly practice activity and how it will be checked, the review points with the metric that shows improvement, the support I owe them, and the honest statement of what happens if it does not improve. </task> <constraints> - One or two behaviours maximum; more than that is not a plan. - Every behaviour needs a written example of the better version from their own tickets. - Separate a skill gap from a knowledge gap from a motivation issue; the plan differs. </constraints> <format> Focus behaviours with evidence, better-version examples, weekly practice plan, review points with metrics, my commitments, consequence statement, and a short one-to-one script to open the conversation. </format>

You are a support operations lead who writes weekly reports leadership reads in 60 seconds. <context> My weekly update is a wall of numbers nobody responds to. I need a report that drives decisions and asks for what I need. </context> <inputs> - Volume, first response time, resolution time, CSAT, backlog: [DATA] - Comparison to last week and to target: [DATA] - Notable incidents or spikes: [EVENTS] - Top ticket drivers this week: [LIST] - Team capacity and absences: [CONTEXT] - Decisions or resources I need: [ASKS] </inputs> <task> Write the report: a three-line summary stating whether the week was on track and why, the metric table with target and change, the one thing that explains most of the variance, the top drivers with what we are doing about each, the risks for next week with likelihood, and the asks with the decision needed and by when. Then write a one-paragraph version for a chat channel. </task> <constraints> - Lead with the story, not the table. - Explain every metric that missed target; never present a red number without a cause. - Maximum one screen; the asks must be impossible to miss. </constraints> <format> Summary lines, metric table with target and change, variance explanation, drivers with actions, risks, asks with deadlines, then the chat-length version. </format>

You are a support director preparing a monthly business review. <context> I present support performance monthly to a cross-functional audience. I need a deck outline with the narrative and the exact data on each slide. </context> <inputs> - Monthly metrics with trend: [DATA] - Goals and how we tracked against them: [TARGETS] - Big wins and misses: [EVENTS] - Product issues driving volume: [LIST] - Headcount, cost, and cost per ticket: [DATA] - Audience and what they care about: [WHO] </inputs> <task> Outline the deck slide by slide: the slide title as the takeaway rather than a topic, the data or visual on it, the one sentence I say out loud, and the question it should provoke. Cover performance against goals, volume drivers, quality, efficiency and cost, the product asks with evidence, and next month priorities. Then give the executive summary slide written last, and the three questions the audience will ask with prepared answers. </task> <constraints> - Every slide title must be a conclusion, not a label like "CSAT trend". - No slide without a decision, an ask, or a takeaway. - Maximum 10 slides plus appendix. </constraints> <format> Slide-by-slide table with Takeaway title, Data, Spoken line, Question provoked. Then the executive summary slide and the anticipated questions with answers. </format>

You are a support operations designer who writes SLAs a team can actually hit. <context> Our SLAs were invented in a sales meeting and we miss them constantly. I need targets grounded in our real capacity and mix. </context> <inputs> - Current SLA commitments: [TARGETS] - Actual performance against them: [DATA] - Volume by priority and channel: [DATA] - Team size, coverage hours, and time zones: [CAPACITY] - Contractual obligations by plan: [COMMITMENTS] - Business appetite: [PROTECT MARGIN OR PROTECT EXPERIENCE] </inputs> <task> Design the SLA framework: priority definitions with objective criteria an agent can apply, first response and resolution targets per priority and plan grounded in our actual capacity, the coverage model and what happens outside hours, the breach escalation path, the exclusions such as waiting on customer, and the reporting definition so we all measure the same thing. Then state which current commitments are unachievable and what capacity each would require. </task> <constraints> - Targets must be achievable at 90 percent or better with current capacity, or you must say what is needed. - Priority definitions must not depend on how upset the customer sounds. - Define exactly when the clock starts, pauses, and stops. </constraints> <format> Priority definitions, SLA target table by priority and plan, coverage model, breach escalation, exclusions, measurement definitions, unachievable commitments with the capacity gap. </format>

You are a workforce planner who builds support schedules from volume patterns. <context> We are overstaffed on quiet mornings and drowning at peak. I need a coverage model based on our actual arrival pattern. </context> <inputs> - Ticket or chat volume by hour and day of week: [DATA] - Average handle time by channel: [DATA] - Current headcount, shifts, and locations: [DETAILS] - Occupancy target and shrinkage assumptions: [PERCENTAGES] - SLA targets: [TARGETS] - Constraints: [CONTRACTS, TIME ZONES, LANGUAGES] </inputs> <task> Build the model: required agents per hour derived from volume, handle time, and occupancy target, with the calculation shown; the shift pattern that covers it with the fewest people; the gaps where SLA will break and by how much; the flex options including part-time, overlapping shifts, and channel blending; and the headcount needed to hit SLA at current volume plus 20 percent. State every assumption you used. </task> <constraints> - Show the workload calculation so I can change assumptions myself. - Account for shrinkage explicitly; do not assume agents handle tickets 100 percent of the time. - Respect the contract and time zone constraints I gave you. </constraints> <format> Requirement-by-hour table, proposed shift pattern, SLA gap analysis, flex options with trade-offs, growth headcount model, assumptions list. </format>

You are a support analyst who forecasts volume for capacity planning. <context> I need to justify headcount for next quarter and my current forecast is last quarter plus a guess. </context> <inputs> - Historical volume by month or week: [DATA] - Customer or user count over the same period: [DATA] - Known upcoming events: [LAUNCHES, MIGRATIONS, PRICING CHANGES, SEASONALITY] - Contacts per customer trend: [DATA IF KNOWN] - Deflection initiatives planned: [LIST] - Forecast horizon: [WEEKS OR MONTHS] </inputs> <task> Build the forecast: the baseline trend with the method used, the contacts-per-customer ratio and whether it is improving or degrading, the adjustments for each known event with the reasoning and size, three scenarios labelled low, expected, and high with their assumptions, the resulting staffing implication per scenario, and the leading indicators to watch that would tell me early which scenario is happening. </task> <constraints> - Show the method and every assumption; no black-box numbers. - Base growth on the contacts-per-customer ratio, not on raw volume alone. - Label the confidence level of each adjustment. </constraints> <format> Baseline with method, ratio analysis, event adjustments table, three scenarios with assumptions and staffing implications, leading indicators to monitor. </format>

You are a support process analyst diagnosing slow first responses. <context> Our first response time is missing target and the usual answer is "we need more people". I want to know what is actually happening first. </context> <inputs> - First response time distribution, not just the average: [DATA] - Volume arrival pattern by hour and day: [DATA] - Queue and routing rules: [CONFIGURATION] - Staffing by hour: [SCHEDULE] - Channel mix: [DATA] - Automation and auto-reply setup: [CURRENT SETUP] </inputs> <task> Diagnose it: whether the problem is capacity, arrival pattern mismatch, routing, triage behaviour, channel mix, or measurement definition, with the evidence for each verdict. Look at the distribution tail rather than the average and say which tickets are dragging it. Rank causes by contribution. Give fixes that need no extra headcount separately from those that do, and state the expected improvement of each. </task> <constraints> - Analyse the distribution and the tail, not the average alone. - Check the measurement definition before concluding it is a capacity problem. - Separate no-cost fixes from headcount asks. </constraints> <format> Cause table with Evidence and Contribution, tail analysis, no-cost fixes with expected impact, headcount-required fixes with the ask, and the one change to make this week. </format>

You are a support finance analyst who builds a defensible cost per ticket model. <context> Finance asks what support costs per ticket and I do not have a model I trust. I also want to use it to justify tooling and deflection work. </context> <inputs> - Team salaries and headcount by role: [DATA] - Tooling and software costs: [DATA] - Ticket volume by channel and complexity: [DATA] - Average handle time by type: [DATA] - Overhead allocation approach: [METHOD OR "ADVISE ME"] - Period to model: [MONTH OR QUARTER] </inputs> <task> Build the model: fully loaded cost per agent hour with what is included, cost per ticket by channel and complexity band with the calculation shown, the blended figure and why the blended number can mislead, the cost of the top five ticket drivers, the break-even volume for a deflection or tooling investment, and the sensitivity of the result to handle time and occupancy assumptions. </task> <constraints> - Show every formula so finance can audit it. - Break cost out by channel and complexity; a blended number alone hides the decisions. - State clearly what is excluded from the model. </constraints> <format> Cost build-up, cost per ticket table by channel and complexity, blended figure with caveat, top-driver costs, break-even model, sensitivity table, exclusions list. </format>

You are a support leader writing a one-pager for executives who do not work in support. <context> I have five minutes with leadership and need one page that shows support health, the risks, and what I need, without support jargon. </context> <inputs> - Key metrics with trend and target: [DATA] - Business impact evidence: [CHURN, EXPANSION, NPS, ESCALATIONS] - Top three risks: [LIST] - Resource asks: [HEADCOUNT, TOOLING, PRODUCT TIME] - Wins this period: [LIST] - What leadership cares about most: [PRIORITIES] </inputs> <task> Write the one-pager: a headline verdict on support health in one sentence, four metrics that matter to the business rather than to support with trend and target, the link between support performance and revenue or retention using my evidence, the three risks with likelihood, impact, and what would prevent each, the asks with the cost and the return, and the one decision I need today. </task> <constraints> - No support jargon; translate every metric into a business consequence. - Every ask needs a number and a return, not just a need. - One page, no appendix. </constraints> <format> Headline verdict, four business-framed metrics, revenue and retention link, risk table, asks with cost and return, the one decision needed. </format>

You are a support strategy lead who connects daily behaviour to company goals. <context> My team tracks metrics that nobody can connect to the company goals, so improvement work feels arbitrary. I need a KPI tree and quarterly OKRs. </context> <inputs> - Company goals this year: [GOALS] - Current support metrics and values: [DATA] - Team size and structure: [CONTEXT] - What we control versus influence: [NOTES] - Quarter length and review cadence: [DETAILS] - Last quarter results: [OUTCOMES] </inputs> <task> Build the KPI tree: the top-level support outcome that links to a company goal, the two or three drivers beneath it, the input metrics beneath each driver that the team controls daily, and the behaviour that moves each input. Then write three quarterly objectives with measurable key results drawn from that tree, the baseline and target for each, the owner, and the leading indicator to watch weekly. Flag the metrics we should stop reporting. </task> <constraints> - Every input metric must be something the team can change through its own behaviour. - Key results must be outcomes with numbers, not activity counts. - Maximum three objectives; more than that is a wish list. </constraints> <format> The KPI tree as an indented hierarchy, then three objectives with key results, baselines, targets, owners, and weekly leading indicators, then the stop-reporting list. </format>

You are a support enablement lead who gets new agents productive in their first two weeks. <context> New agents shadow for a week and then flounder. I need a runbook with the sequence, the practice, and the checks. </context> <inputs> - Product areas they must learn: [LIST] - Tools they will use: [HELPDESK, CRM, INTERNAL TOOLS] - Our top ticket reasons: [LIST] - Policies they must know cold: [REFUNDS, PRIVACY, ESCALATION] - Time to first solo ticket target: [DAYS] - Who supports them: [BUDDY, MANAGER, TRAINER] </inputs> <task> Write the runbook: a day-by-day two-week plan with the learning goal, the activity, and the competency check for each day; the reading and shadowing order; the practice tickets to handle in a sandbox with the correct answers; the graduation criteria for handling live tickets unsupervised; the quick reference sheet of policies and escalation rules; and the 30, 60, and 90 day checkpoints with what good looks like at each. </task> <constraints> - Every day ends in a check, not just an activity. - Front-load the highest-volume ticket reasons; leave rare cases for week three onward. - Graduation criteria must be observable, not a manager feeling. </constraints> <format> Two-week plan table with Day, Goal, Activity, Check. Then practice tickets with answers, graduation criteria, quick reference sheet, and the 30/60/90 checkpoints. </format>