Use ChatGPT to Turn an Incident Note into a Reviewable Customer Update

A customer update has a small job: say what is known, explain what is being done, and avoid making the next update harder by guessing.

This documentation-based example uses a fictional service incident. It turns an internal note into two reviewable artifacts: a fact ledger and a short customer update draft. The draft is not a status decision, an apology policy, or permission to send.

Evidence label: Documentation-based and illustrative. The workflow follows OpenAI’s documented file-upload and prompting guidance. The input and output are fictional editor-written examples. No model run, incident, customer result, or personal test is claimed.

What you need

ChatGPT with text input and file upload if your plan and workspace provide it
a fictional or approved incident note
the approved customer communication rules for your team
a named incident owner who can confirm facts before anything is sent

Do not upload private customer data or security-sensitive details unless your organisation’s policy permits it. Use the sample below to learn the structure.

Sample input

Save this as harbor-incident-note.txt:

Harbor Desk incident note, 22 October 2026, 09:20 UTC

Between 08:42 and 09:05 UTC, some customers saw a timeout when exporting a monthly report.
The on-call engineer reproduced the timeout for the PDF export path at 09:02 UTC.
The CSV export path has not been checked yet.
The team rolled back release 4.18 at 09:10 UTC and is watching new export requests.
We do not yet know how many customer workspaces were affected.
Next internal update: 09:45 UTC.
Customer message must not promise a restoration time until the incident owner approves it.

The note contains a confirmed symptom, a tested scope, an unchecked path, an action, and a limit on what the customer message may promise.

Steps

1. Attach the note and the communication rule

Open ChatGPT and attach the approved note. If upload is unavailable, paste the complete text between the tags in the prompt below. Add your team’s approved wording rules as a second source, or leave that source out and ask for a draft only.

Keep the source boundary visible. Do not ask for a confident explanation of the cause when the note does not contain one.

2. Build the fact ledger first

Paste this prompt:

You are preparing a customer-update draft from the source between <incident_note> tags.

First create a table with these columns:
1. Statement
2. Status: CONFIRMED, UNKNOWN, or NEXT CHECK
3. Exact source phrase
4. Safe customer wording, or "Do not include yet"
5. Reviewer question

Rules:
- Use only the incident note. Do not infer cause, scope, customer count, resolution, or impact.
- Keep times, version numbers, paths, and quantities exactly as written.
- Treat a reproduction as evidence about that path only. Do not generalize it to other export paths.
- Treat a rollback as an action taken, not proof that the incident is resolved.
- Mark promises, restoration times, and customer counts as unsafe when the source does not confirm them.
- End with a section named "Before sending" containing the facts a named incident owner must confirm.

<incident_note>
[PASTE THE APPROVED INCIDENT NOTE HERE]
</incident_note>

3. Draft the update from approved rows only

After checking the ledger against the note, ask for a draft using this second prompt:

Using only rows marked CONFIRMED in the ledger, write a customer update of 80 words or fewer.

Structure:
- what happened
- what the team did
- what is still unknown
- when the next update is expected

Do not state or imply that service is restored.
Do not state a customer count.
Do not invent a cause, impact, workaround, apology, credit, or restoration time.
Use "We are checking" for an item marked UNKNOWN.
Add the heading "DRAFT FOR HUMAN REVIEW" and nothing that suggests the message was sent.

4. Compare the draft with the source

For this fictional note, a safe draft can say that some customers saw a PDF export timeout, that the team rolled back release 4.18, that the CSV path and affected-workspace count are still being checked, and that the next update is planned for 09:45 UTC.

That is an illustrative expected artifact, not a model result. The incident owner still needs to confirm the wording and decide whether it meets the organisation’s communication policy.

Checkable artifact

Keep these together:

the original incident note
the fact ledger with a source phrase in every row
the customer draft labeled DRAFT FOR HUMAN REVIEW
the owner’s answers to the Before sending questions

Acceptance checks

The package passes when:

08:42, 09:05, 09:02, 09:10, 09:45, and 4.18 remain unchanged
PDF export is not treated as evidence about CSV export
the rollback is not described as a confirmed restoration
no customer count, root cause, or credit is invented
the next update is described as planned, not guaranteed as a resolution
every customer-facing claim has an exact source phrase or an owner-approved addition

Troubleshooting

The draft says the issue is resolved. Repeat that a rollback is an action, not proof of restoration. Ask for a separate confirmation row before using resolution language.

The output includes a likely cause. Delete it unless the incident note explicitly confirms the cause. A plausible explanation is still an unknown.

The file upload is unavailable. Paste the entire note between the tags. Do not summarise it first, because the omitted detail may be the control you need.

The message promises the next update. Change the wording to “planned for 09:45 UTC” and ask the owner to confirm that the time is still valid before sending.

Limits and privacy

This workflow improves traceability. It does not detect every security, legal, contractual, or customer-support requirement. Use your incident process, approved data boundary, and human owner. ChatGPT access and file limits vary by plan and workspace.

TRY the ledger on a fictional note or an approved low-risk incident.

SKIP an automated customer send, especially when the note includes security, legal, health, financial, or regulated information.

USE the draft only after the source check and owner approval are complete.

For one practical AI-for-work workflow each week, join The Weekly Verdict.