The prompt
Score 10 of 10, Excellent
Use it when You need agents to know the symptoms, workaround, what to say and when to escalate.
- {{issue_notes}}
- {{approved_messaging}}
- {{ticket_tagging}}
- {{escalation_path}}
- {{allowed_offers}}
- {{next_update}}
Full prompt and why it works
Prompt
Write an internal brief for our support team about a known issue, so every agent can recognize it, help the customer and handle it the same way. Agents will read it between tickets, so it must be scannable in under two minutes. Notes from engineering or the incident lead: """ {{issue_notes}} """ Approved to tell customers: {{approved_messaging}} How to tag or link tickets: {{ticket_tagging}} When and how to escalate, and to whom: {{escalation_path}} What we may offer affected customers, per policy: {{allowed_offers}} When this brief will next be updated: {{next_update}} Use these sections, with headings, in under 400 words before the saved reply: 1. What's happening: two sentences describing what customers see, not internal system names. 2. Who is affected: plans, platforms, regions or features, as far as the notes say. 3. How to spot it: the phrases customers use and the checks that confirm a ticket is this issue, for example a specific error message or screen. 4. Workaround: numbered steps, or "No workaround yet". 5. What to say and what not to say: what is approved, and what agents must not promise, such as a fix date, a cause, or compensation beyond what policy allows. 6. Tag and link: how to record each ticket, because the count of linked tickets helps engineering judge the impact. 7. Escalate when: the specific cases that need escalating, for example a customer who cannot work at all or reports lost data, and to whom. 8. Next update: when this brief will be revised. Then write a saved reply agents can send, under 100 words, using only approved information and the workaround, with [CUSTOMER NAME] where the name goes. Use only facts from the notes and the lines above. Do not guess at the cause, the fix date or how many customers are affected. Do not name individual engineers or blame another team. Keep the tone calm and practical. If the notes are unclear or contradict each other, for example about who is affected, write "Unconfirmed" in that section and add a final list, "To confirm with engineering:", with each open question.
Variables
- {{issue_notes}}
- What engineering or the incident lead has shared: symptoms, affected areas, cause if known, workaround, status.
- {{approved_messaging}}
- What has been cleared to tell customers. Write "symptoms only" if nothing else is cleared.
- {{ticket_tagging}}
- The tag, macro or parent ticket agents should use, for example "tag known-issue-export and link to the parent ticket".
- {{escalation_path}}
- When to escalate and to whom, for example "cases with data loss go to the on-call engineer via the escalation form".
- {{allowed_offers}}
- Any credit or other remedy policy allows for this issue, or "none".
- {{next_update}}
- When the brief will next be updated, for example "4 p.m. today".
Why it works
- Format. Sections follow the order an agent needs them during a ticket (spot it, fix it, say it, tag it, escalate it), with a ready reply at the end.
- What to avoid. Agents are told exactly what not to promise, such as a fix date or a cause, so fifty agents do not give fifty different answers.
- If unsure. Unclear or conflicting notes are marked "Unconfirmed" with a list of questions for engineering, so guesses never reach customers.