During an incident, people need to know whether they are affected, what they should do, and when they will hear more. An incident-communications presentation helps the team give consistent answers. It should not make customers or executives decode the engineering incident channel.
Consider this initial customer update for a fictional attachment-upload service. All times, observations, and messages in the example below are invented for illustration; they do not describe a Presenti incident.
10:15 UTC — Investigating attachment-upload errors
We are investigating errors affecting new attachment uploads for some workspaces hosted in our EU region. We first observed the errors at 10:05 UTC and are still determining the full scope. We will publish another update by 10:30 UTC.
The message names the task, the known scope, and the next update without inventing a cause or recovery time. Build your briefing around the same confirmed facts. Once those notes are approved, Presenti can help turn the text into an editable presentation for a stakeholder briefing. It does not monitor the incident, verify recovery, or publish status-page updates for you.
Keep one fact record behind the different messages
Before designing slides, make a short incident record that everyone writing an update can use. Each observation needs a time and a source. A hypothesis needs a label. An unanswered question should stay unanswered until someone has evidence.
In the fictional incident, the 10:18 UTC record might contain:
| Status | Entry | Evidence or next action |
|---|---|---|
| Confirmed | New attachment uploads are returning errors for some EU-hosted workspaces. | Gateway error records and an unsuccessful upload test from an affected workspace; first observed at 10:05 UTC. |
| Confirmed, limited coverage | Existing-file downloads passed the checks performed so far. | Recorded test results; these checks do not prove that every download for every customer is unaffected. |
| Unknown | Exact incident start time and total affected-workspace count. | Operations is reviewing earlier records and the scope of failed requests. |
| Hypothesis | A routing change may be involved. | The service team is comparing the change record with observed failures. Timing alone does not establish causation. |
| Unknown | Whether all timed-out upload attempts failed before storing an attachment. | Request outcomes need reconciliation. Do not tell customers that no data was lost or that nothing was stored. |
Keep the exact start time separate from the first observation. “We first observed errors at 10:05” is supported here. “The incident started at 10:05” is not. That distinction avoids revising a confident claim when earlier failures appear in the logs.
The presentation is a dated snapshot of this record, not a competing source of truth. Put “As of 10:18 UTC” on the internal briefing. If someone forwards it an hour later, the timestamp should make its age obvious.
Give each audience the information it can use
Google’s incident-response guidance separates incident command, operations, and communications responsibilities. It also recognizes that customers, support teams, engineers, and leaders need different information. Use that distinction to change the emphasis—not the facts.
| Audience | Main question | What belongs in its update |
|---|---|---|
| Customers | Can I complete my task, and what should I do? | Affected function and scope, confirmed action or workaround, current status, next update time. |
| Support | How do I answer consistently and escalate useful reports? | The approved public message, symptoms to recognize, what not to promise, and which diagnostic details to request. |
| Responders | What do we know, what is being tested, and who is doing it? | Evidence, hypotheses, current actions, owners, dependencies, and unresolved technical decisions. |
| Business leaders | What is the exposure, and is a decision needed from me? | Known customer impact, unknown scale, response ownership, resource or communication decisions, and the next briefing time. |
A customer update usually does not need a theory about routing. The response team does. A leadership briefing needs to know that the affected-workspace count is still being established, not receive a rough guess that will become an official number when someone forwards the slide.
Here is a short internal leadership message for the same fictional 10:18 briefing:
New attachment uploads are failing for some EU-hosted workspaces. The affected-workspace count and exact start time are not yet confirmed. The service team is investigating; the incident commander owns response decisions, and the communications lead is coordinating customer and support updates. No recovery time is approved for communication. The next customer update is due at 10:30 UTC. No additional executive decision is requested at this point.
For support, add a separate instruction: ask for the workspace identifier, approximate UTC time, and visible error message through the normal support channel. Do not ask customers to post private files or credentials on a public status page. If there is no confirmed workaround, say so instead of suggesting speculative steps.
Show both the incident timeline and the communication timeline
An operational event and the message about it are different records. A mitigation applied at 10:42 does not mean customers were told at 10:42, or that recovery was already verified. Put both kinds of event on the briefing timeline.
| Time | Event type | What the record says |
|---|---|---|
| 10:05 | Observation | Upload errors first observed. Exact onset still unknown. |
| 10:12 | Response | Incident declared; incident commander and communications lead assigned. |
| 10:15 | Public update | Investigation acknowledged; next update promised by 10:30. |
| 10:30 | Public update | No confirmed recovery yet; investigation continues; next update by 10:50. |
| 10:42 | Response | A mitigation is applied. Its effect must still be checked. |
| 10:50 | Public update | Recent checks show improvement; service is being monitored; next update by 11:15. |
| 11:15 | Public update | Upload availability is declared restored after the agreed recovery checks. A support route remains available for unresolved customer problems. |
The intervals here are examples, not a universal incident policy. Set a cadence the response team can actually maintain, with shorter intervals where the situation warrants them. If a meaningful change happens before the promised time, communicate it early.
A promised update is not a promised fix. Write “next update by 10:50 UTC,” not “back by 10:50,” unless the latter has a defensible basis and is approved. When investigation produces no new conclusion, the obligation to update still exists.
Use status messages that remain accurate as the incident changes
The opening acknowledgement gets the issue onto the public record. The following messages show how the same fictional incident can progress without turning tentative evidence into certainty.
At 10:30: investigation continues
10:30 UTC — Investigation continuing
We are continuing to investigate attachment-upload errors affecting some workspaces hosted in our EU region. We do not yet have a confirmed recovery time or a confirmed workaround. Our next update will be published by 10:50 UTC.
This is useful even though it does not announce a fix. It confirms that the incident is active and prevents the previous update time from silently expiring. Avoid padding it with “our engineers are working tirelessly” or repeating an unverified cause.
At 10:50: improvement is being checked
10:50 UTC — Monitoring recovery
We have applied a mitigation, and recent checks show attachment uploads succeeding again in the affected region. We are monitoring upload outcomes before declaring the service restored. If you still receive an upload error, contact support with the workspace identifier and approximate time. We will update this page by 11:15 UTC.
“Checks show improvement” is narrower than “everyone is back online.” Keep that boundary. A graph returning to normal does not, by itself, settle the outcome of earlier attempts or prove that every customer path has recovered.
At 11:15: describe what has been restored
11:15 UTC — Attachment-upload availability restored
Attachment uploads are working normally in the affected region. Upload outcomes have remained within the service’s normal range during the recovery observation period, and the agreed upload checks have passed. If an earlier upload returned an error or its result is unclear, check your attachment list before trying again. Contact support if you still have a problem.
This final message assumes the fictional team has completed those checks and confirmed that the customer instruction fits its service. Do not copy it into a real incident before that evidence exists. It does not claim a root cause, quantify all affected customers, or make a blanket statement about data loss.
For your own messages, replace the function, scope, observed symptom, evidence-backed status, customer action, and next update time. Those fields carry the meaning. Changing only the service name while retaining unsupported recovery language is not a safe adaptation.
Make approval and the next update visible in the briefing
A communications lead needs more than a finished paragraph. The briefing should identify who confirms the technical facts, who approves the public message, and who publishes it through the authorized channel. Use your actual incident roles; do not assume the slide author can authorize a recovery declaration.
For the fictional service, a five-slide briefing would be enough:
- Current status: the affected function and region, the timestamp, and the current incident owner.
- Impact and uncertainty: what is confirmed, what remains unknown, and the source of each important statement.
- Response: current actions and decisions needed, without presenting an untested hypothesis as the cause.
- Communications: the approved customer message, the support note, the publishing owner, and the next update time.
- Recovery evidence: the checks required to move from investigating to monitoring or restored, with their actual results when available.
Keep draft wording visibly separate from sent wording. Record the version, approval time, publication time, and destination. If the team changes the scope from “EU region” to a narrower set of workspaces, revise the shared fact record and subsequent messages together rather than leaving contradictory slides in circulation.
Google’s guidance on managing incidents emphasizes maintaining a current incident record and a clear handoff. The practical implication for this deck is simple: its owner and timestamp must stay visible, especially when the response changes hands.
Separate restored service from the later explanation
During recovery, communicate the function that is working again and any action customers still need to take. Do not wait for a complete causal analysis before acknowledging restoration. Equally, do not hide continuing customer impact behind a “resolved” label just because one system metric improved.
After the incident, the team can investigate contributing factors and longer-term changes in an incident postmortem presentation. That is a different deliverable. The active briefing should not contain an invented root-cause narrative simply to make the story feel complete.
When the communications lead hands over before resolution, leave a usable record. Here is the fictional handoff at 10:35 UTC, between the investigation and monitoring updates:
Communications handoff — 10:35 UTC
Current public status: investigating attachment-upload errors in some EU-hosted workspaces. Last message: version 2, published at 10:30 UTC. Next public update: due by 10:50 UTC, including a no-change update if recovery is not confirmed. Incoming communications lead has accepted ownership. The incident commander confirms operational status; the communications lead publishes the approved wording. Recovery time, exact onset, and affected-workspace count remain unconfirmed. The shared incident record contains the latest evidence and the support message.
The incoming owner can now send the next accurate update without reconstructing the incident from chat history or guessing which slide is current.
