Preserve one verified incident state while changing detail, cadence, privacy, and actions by channel. 제공할 내용: Verified support facts, Recipients and channel contexts, Communication policy. 예상 결과: Channel-specific support messages with a shared fact ledger, update contract, and privacy audit.
1
맥락 추가
텍스트는 이 브라우저에 유지됩니다. AILesson Prompts는 이를 모델이나 서버로 보내지 않습니다.
2
프롬프트
채워지지 않은 필드는 플레이스홀더로 표시되므로 프롬프트를 복사하고 편집할 수 있습니다
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.
기본적으로 비공개프롬프트 구성은 브라우저에서 로컬로 이루어집니다. 조직에서 허용하지 않는 한 기밀 정보를 AI 서비스에 입력하지 마세요.
입력에서 결과까지
적용 예시
구체적인 맥락이 이 레시피를 바로 사용할 수 있는 결과로 바꾸는 방법을 확인하세요
실제 입력
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.
예시 출력
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…”
효과가 있는 이유
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
결과 확인
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
안심하고 사용하세요
자주 묻는 질문
이 레시피를 언제 사용해야 하는지, 무엇을 제공해야 하는지, 그리고 어떤 부분에서 사람의 검토가 여전히 중요한지에 대한 실용적인 답변
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
