Adapt a support response for email, chat, and public notice
Author: AILesson7 min setupTested with:ChatGPTReviewed: 2026-08-28
Quick answer
Preserve one verified incident state while changing detail, cadence, privacy, and actions by channel. Provide: Verified support facts, Recipients and channel contexts, Communication policy. Expected result: Channel-specific support messages with a shared fact ledger, update contract, and privacy audit.
1
Add your context
Your text stays in this browser. AILesson Prompts does not send it to a model or server.
2
Your prompt
Unfilled fields remain visible as placeholders, so you can still copy and edit the prompt
Adapt the verified support state into email, chat, and public-notice messages.
Issue, scope, times, symptoms, cause status, current status, workaround, risk, owner, and next update:
[facts]
Each channel's recipient, relationship, case/account context, visibility, length, reply path, and accessibility:
[audiences]
Approved terms, privacy/security, apology/compensation authority, status rules, localization, cadence, and review:
[policy]
Create a shared fact ledger first. All versions must preserve issue scope, exact dates/timezones, known versus unknown cause, current status, workaround eligibility, promises, and next-update time. Do not turn investigation into confirmed cause, partial recovery into resolution, one customer's report into global impact, or silence into unaffected status. Do not expose account, ticket, staff, infrastructure, security, or personal details in public messages. Never promise compensation or resolution without authority.
Email may use known case context and fuller next steps; chat should be brief, turn-based, and ask at most one necessary clarification; public notice should use aggregate verified scope, accessible plain language, timestamp, status, safe workaround, and next update. Avoid copying private troubleshooting into public text or giving account-specific instructions without verification. Provide all three drafts, shared fact ledger, difference rationale, prohibited-detail audit, update/correction template, and consistency check showing that every difference is due to channel need rather than changed truth.
Private by defaultPrompt assembly happens locally in your browser. Avoid placing confidential information into any AI service unless your organization allows it.
From input to outcome
A worked example
See how concrete context turns this recipe into a usable result
Actual input
Verified support facts
On 28 Aug 2026 at 09:20 UTC monitoring detected delayed CSV validation in EU web region. Confirmed affected action: some CSV validations started 09:05-10:12 UTC took 8-25 minutes instead of usual under 2; import uploads and approved data remained available. Cause is under investigation. Queue returned to usual processing at 10:12, but team is monitoring and has not declared resolved. Safe workaround for urgent new files: wait for current validation rather than resubmit, because duplicate submissions may create duplicate drafts. No data-loss evidence. Next update by 11:00 UTC even if unchanged. Incident owner: reliability lead. Individual ticket T-301 belongs to customer River Group; no compensation decision.
Recipients and channel contexts
Email to verified admin on T-301, under 180 words, may mention ticket and their reported file at 09:44 but not internal logs. Chat to signed-in user asking 'Should I upload again?', under 60 words, one turn. Public status notice for all users, no customer/ticket names, accessible plain text, timestamp. Email/chat can link support case; notice links status subscription.
Communication policy
Approved term 'delayed CSV validation in the EU web region.' May apologize for disruption, not admit negligence. Do not publish infrastructure identifiers, queue volume, staff names, account data, or security speculation. No compensation promise. Status remains Monitoring, not Resolved. English now; localization after incident. Next update deadline exact. Review by support lead.
Example output
Shared ledger: EU web region; some validations begun 09:05-10:12 UTC; 8-25 minutes versus usual under 2; uploads/approved data available; cause investigating; usual processing returned 10:12; Monitoring, not Resolved; no evidence of data loss; do not resubmit pending file; next update by 11:00 UTC.
Email subject: Update on delayed validation — ticket T-301
Hello,
We're sorry for the disruption from delayed CSV validation in the EU web region. The file you reported at 09:44 UTC falls within the period we are reviewing. Some validations started between 09:05 and 10:12 UTC took 8-25 minutes rather than the usual under two minutes. Uploads and approved data remained available, and we have no evidence of data loss.
Processing returned to its usual pace at 10:12 UTC, but the incident remains in Monitoring while we investigate the cause. Please wait for the current validation rather than uploading the same file again, which may create a duplicate draft. We will update this case by 11:00 UTC even if the status is unchanged.
Chat: “Please don't upload the same file again. Some EU-region validations were delayed, and a resubmission may create a duplicate draft. Processing is back to its usual pace, but we are still monitoring. Please wait for the current validation; we'll post another update by 11:00 UTC.”
Public notice — 10:20 UTC, Monitoring: “We are monitoring delayed CSV validation in the EU web region. Some validations started from 09:05 to 10:12 UTC took 8-25 minutes. Uploads and approved data remained available. Processing returned to its usual pace at 10:12, but the cause is still under investigation. If a validation is pending, do not resubmit the same file. No data loss has been identified. Next update by 11:00 UTC.”
Difference audit: only email includes verified ticket/file context; chat directly answers resubmission; notice uses aggregate scope. All preserve Monitoring/cause unknown. Excluded River Group, internal owner/logs, infrastructure, compensation. Correction template: timestamp, “Earlier we said… Correct information is… Impact/next action… Next update…”
Why this works
1
A shared ledger prevents channel brevity from changing incident scope, certainty, or promises
2
Channel-specific privacy boundaries keep useful case context out of public updates
Check the result
Do all versions preserve the same scope, time, status, cause certainty, workaround, and update promise
Is private case context confined to authorized channels and omitted from public notice
Are tone, length, action, reply path, and detail adapted without changing truth
Use it with confidence
Frequently asked questions
Practical answers about when to use this recipe, what to provide, and where human review still matters
What should I prepare before using “Adapt a support response for email, chat, and public notice”?
For “Adapt a support response for email, chat, and public notice,” prepare Verified support facts, Recipients and channel contexts, and Communication policy. Replace placeholders only with information you can verify. If a detail is unknown, preserve that uncertainty explicitly instead of asking the model to infer it.
When is the “Adapt a support response for email, chat, and public notice” result not ready to use?
The result is not ready if it does not yet deliver the stated outcome—Channel-specific support messages with a shared fact ledger, update contract, and privacy audit—from the supplied evidence, or if it relies on unresolved assumptions, missing approvals, or invented details. Use the checks as release gates: revise the source inputs or assign a named, authorized reviewer instead of polishing an unsupported output.
Which AI tools have recorded tests for “Adapt a support response for email, chat, and public notice”?
The published test record for “Adapt a support response for email, chat, and public notice” lists ChatGPT as of 2026-08-28. This confirms recorded runs, not guaranteed compatibility or identical results in later product versions. For another tool or version, keep every constraint visible and repeat the result checks before use.
ChatGPT