Incident Communication and Stakeholder Management Questions

Direct answer

Interviewers expect the STAR frame: Situation (context), Task (your responsibility), Action (what you did and sent), Result (outcome and lesson). I would tell a specific story that way, with a clear situation, the messages I actually wrote, how I kept people informed and honest, and a concrete lesson. If you have never led communications in a major outage, use the closest honest example instead: a smaller customer-facing failure, a bad release you helped announce, a near-miss, or a tabletop drill (a rehearsal of a fake incident), and say plainly that it was smaller. Do not inflate it. If you only have two minutes, keep the essentials: one sentence of situation, the single hardest message you sent, how you kept the next-update promise, and one lesson. Below is an illustrative story skeleton (the numbers and names are placeholders; use your own real details, and do not embellish).

Situation

A change to a storage layer caused our file-sync product to fail for a large share of customers, and recovery took most of a working day because the fix required rebuilding data in stages. I was the communications lead (the person who owns all messages to people outside the response team) while a colleague acted as incident commander (the person coordinating the response). Executives wanted answers every hour, and several enterprise customers had contractual uptime promises (service-level agreements, or SLAs).

Task

Keep executives and customers accurately informed for the full duration without distracting the responders, and protect trust when we could not give a fix time.

Action (what I sent and how)

1. First message (within minutes): plain symptom, "investigating", next update time. It went on the status page (the public web page where customers see service health). No cause and no fix time.
2. A fixed rhythm: every 30 minutes at first, moving to hourly once stable, announced in the message so silence was expected.
3. Two versions of each update: a candid internal one (suspected cause labeled as suspected, asks of leadership) and a shorter customer one for the status page.
4. A "restored, still affected, unknown" format once partial recovery started, so no one mistook partial recovery for resolution.
5. Direct notes to key customers through account managers, using the same wording as the status page.
6. Handoff of the writer role at the end of my shift, named in the message.

Excerpt from a mid-incident message (illustrative):

Update 6, 15:00 UTC. Restored: reading files. Still affected: uploading new files. Unknown: when uploads will recover; we are rebuilding data in stages and will give an estimate once the first stage is verified. Next update 15:30.

Result

Executives stopped asking responders directly and customers received consistent messages. Describe results qualitatively like this unless you have real figures you can defend; do not invent precise numbers.

How I kept trust

• Never gave a fix time we could not support, but always gave the next update time and kept it.
• Corrected one earlier statement openly when we found it was too optimistic ("earlier we said X; now we know Y").
• Only said "resolved" after we had watched recovery.
• Published the promised review by the date I stated.

What I would do differently

• Prepare a status page template (a pre-written entry with blanks for symptom, start time and next update) and a holding statement (a short pre-approved message used until facts are known) before any incident, since we wrote the first message from scratch.
• Agree with enterprise customers in advance on what notice they get and when.
• Rotate the communications role sooner; my updates got vaguer late in the shift.

Trade-offs and pitfalls for this answer

• Do not tell a hero story; describe team roles and what you specifically did.
• A story with no failure or lesson sounds rehearsed. Pick one real thing that went imperfectly.
• Avoid unverifiable numbers ("reduced tickets by 60%"); use figures you can defend.

Direct answer

Build four templates, one per stage of the incident: acknowledge, in progress, resolved, follow-up. Each has a fixed skeleton (structure, tone, promises the company always keeps) and a small set of fill-in fields. Only a named communications owner (also called the communications lead: the same role), appointed by the incident commander (the person running the response), publishes to customers. Engineers supply facts, they do not post to customers directly.

What goes in each template

Required fields in every notification (six fields to include, then one to leave out)

1. Service name. 2. Impact in customer terms ("card payments fail at checkout", not "500s from the gateway"). 3. Affected regions or customer groups. 4. What we are doing (mitigation). 5. Next-update time (a clock time, not "soon"). 6. Status page link. Leave out: severity is internal, so omit it unless customers know the scale.

Who can send

• Publisher: the communications owner, with the incident commander approving any statement about cause or duration.
• Backup: a named deputy from the same rota (the on-call rotation, the schedule of who is responsible when), so one person's absence never blocks a message.
• Anyone else: no. The status page tool should enforce this with permissions, not just a rule in a wiki.

Worked example: payment outage (illustrative)

[Investigating] Card payments failing at checkout
14:05 UTC. Some customers in EU and UK regions cannot complete card payments.
Orders already paid are not affected. We are working on a fix.
We will update this page by 14:35 UTC. Status: https://status.example.com

The in-progress version at 14:35 keeps the skeleton and shows movement:

[Identified] Card payments failing at checkout
14:35 UTC. We have found the cause of the failures for EU and UK card payments and are applying a fix.
Orders already paid are not affected. Retrying a failed payment may succeed.
We will update this page by 14:55 UTC. Status: https://status.example.com

The resolved version keeps the skeleton: "14:52 UTC. Card payments are working again. If your payment failed between 13:58 and 14:47 UTC, please retry; you have not been charged twice. We will publish a written review by Friday."

The follow-up, published on the promised day, fulfils that commitment:

[Review] Card payments failure: what happened and what changes
What happened: a change to one payment provider connection caused card payments to fail for EU and UK customers between 13:58 and 14:47 UTC.
What we are changing: changes to payment connections will be tested on a copy first and rolled out gradually.
No customer was charged twice.

Technical versus business customers

Keep one public text but add a short "technical detail" line beneath it for API customers: error codes, affected endpoints, whether retries are safe (idempotent, meaning repeating a request has no extra effect). Business customers get impact, workaround and timing; they should not have to decode error names.

Trade-offs and pitfalls

• Over-templating produces robotic text that hides real news. Keep the "what we know" line free-form.
• Never promise a fix time you cannot control. Promise the next update time instead; that is always keepable.
• Pre-approve the templates with legal and support in advance, so nobody drafts under pressure.
• Forgetting the follow-up stage is the most common gap: customers remember the promised review far longer than the outage.

Direct answer

A good status update opens with what customers experience and its current stage, then scope, workaround, what we are doing, and when the next update comes. It stays honest by stating only verified facts with timestamps, and it avoids legal and public relations (PR) risk by describing impact and actions rather than fault, cause or promises. Each part earns its place because it answers a question a reader would otherwise ask support.

Order and justification

The four stages mean: Investigating (something is wrong, cause unknown), Identified (cause found, fix underway), Monitoring (fix applied, watching to confirm it holds), Resolved (confirmed stable).

Keeping it honest without legal or PR risk

• Facts, not causes: "Login failures for EU customers" is safe; "a bug in our vendor's code" may be wrong and may assign blame.
• No promises you cannot keep: avoid fix times and words like "guarantee". Service credits (compensation defined in an SLA, the service-level agreement with the customer, for example a partial refund on that month's bill) are handled through the support process, not announced in the post.
• Pre-agree wording with legal and PR once, so that during an incident the communications lead picks from approved phrases instead of asking for sign-off each time.
• Escalate to legal only for suspected data exposure, regulated customers or contractual notice duties.
• Never delete or rewrite history: correct mistakes with a visible new update.

Worked example (illustrative sequence)

Investigating | 11:05 UTC
Some customers in the EU cannot log in since 10:40 UTC. Customers already signed in are unaffected. Workaround: none yet. Next update by 11:35 UTC.

Identified | 11:35 UTC
We have found the affected component and are applying a fix. Login remains impacted for some EU customers. Next update by 12:15 UTC.

Monitoring | 12:10 UTC
A fix has been applied and login is working again for EU customers as of 12:10 UTC. We are watching to confirm it stays stable. Next update by 12:40 UTC.

Resolved | 12:40 UTC
Login has been stable for all customers since 12:10 UTC. Affected window: 10:40 to 12:10 UTC (1 hour 30 minutes). A written review (a postmortem, a blameless account of what happened and what will change) will follow.

The duration in the resolved post is derived from the timestamps shown. The post is factual, has no blame, and has a next-update time until the end.

Trade-offs and pitfalls

• Too much technical detail confuses customers and creates risk.
• Vague apologies without substance read as PR. Say what happened and what you did.
• Marking Resolved too early forces an embarrassing reopen.

Direct answer. Write one internal message per audience group, not one generic blast. Each states in plain terms: what failed, which of your systems are affected and how, what has been ruled out, what teams should do (or explicitly need not do), and when the next update comes. Give guidance as options with the trade-off, and leave the decision to the team that owns the service.

Draft (illustrative scenario: a third-party email-sending provider is down).

Subject: [SEV2] Email provider outage: impact by team, next update 15:30 UTC

What happened: Our email provider (Vendor X) has been failing to accept
messages since about 14:10 UTC. Vendor status page: investigating. No ETA.

Impact by team:
- Accounts team: password-reset and verification emails are not being
  delivered. Sign-ups and resets are affected. Login itself works.
- Billing team: invoice emails are queued and will send when the provider
  recovers. No action needed unless you need invoices sent today.
- Notifications team: alert emails are failing. Push and in-app alerts are
  unaffected.
- Not affected: anything that does not send email, including the API and
  dashboard.

What you may want to do (your call, you know your service best):
- Accounts: consider showing an in-app banner and offering the backup
  SMS code path. Trade-off: SMS costs more per message.
- Billing: nothing required.
- Notifications: consider temporarily routing critical alerts to push.

Please do NOT: retry-loop against the provider (it adds load and gets us
rate-limited on recovery) or tell customers a cause or ETA. Support has
approved wording; ask in #incident-comms.

Next update: 15:30 UTC or sooner if the vendor recovers.
Questions: reply in #incident-comms. Coordinator: Dana.

Terms used in the draft.

• SEV2 means severity level 2: a serious incident affecting customers or several teams, but not the worst tier (SEV1).
• Status page is the public web page where a company (or here, the vendor) posts live service status.
• Retry-loop / retry storm: code that resends a failed request again and again. If 20 services each retry every second against a provider that is struggling, that is 20 extra requests per second, and the moment it recovers they all hit at once. The provider may then throttle us (rate-limit, meaning it refuses requests over a quota), which delays our own recovery.
• Coordinator is the named person running the response (the incident commander) and the one who owns questions about the message.

Why it is written this way.

• Impact first, by team, so nobody has to read the whole message to find out whether they are affected. A team that is not affected still wants to be told so.
• "What we know / do not know" is explicit, because vague dependency outages breed rumours.
• Recommendations are labelled options with a trade-off, not orders. Teams own their own risk and know their own customers. The message only hard-restricts the two things that are unsafe for everyone (retry storms, customer-facing claims).
• A fixed next-update time stops the flood of "any news?" pings.

Pitfalls. Blaming the vendor in language you would not want quoted; instructing every team to do the same thing; omitting who to ask; promising the vendor's recovery time as if it were yours.

Direct answer

Cadence and audience should scale with severity (how bad the impact is) and should be re-set at defined moments as the incident ages, not left to whoever remembers. A SEV-1 (the highest level on the company's numbered severity scale: customer-facing, widespread, or revenue-critical; SEV-2 and SEV-3 are progressively lower, with fewer customers hit or a workaround available) gets frequent updates to a wide audience. A lower-severity incident gets slower updates to a narrow one. As an outage stretches to many hours, cadence can relax but never disappears, audience widens to cover new needs (shift handoff, support, customer-facing managers), and partial restoration creates a new duty: say exactly what is back, what is not, and who is still affected.

Severity changes the cadence and audience

These numbers are an example policy, not a standard. Your company's incident policy sets them; the point is that they are decided in advance.

Duration changes it again (the outage stretches to a full day)

• Hours 0 to 2: fastest cadence, smallest facts. Establish the rhythm and the channel.
• Hours 2 to 8: keep the promised rhythm. Executives want a shorter, higher-level summary; add support and account managers so they can answer customers with the same words.
• Beyond a working shift: hand the communications role over explicitly (the incident commander, who coordinates the response, and the writer, the communications lead who drafts and posts updates, both rotate), and post the handoff so readers know who now speaks for the incident. Fatigue causes sloppy updates and contradictions.
• Relaxing cadence: once the situation is stable and there is nothing new, move to hourly or every two hours, and announce the change in the update itself.

Partial restoration (the hard turn)

Say what changed in the form "restored: X; still affected: Y; unknown: Z". Do not use "resolved" or "mostly fixed". Tell still-affected customers directly (support and account managers need a short scripted line). Move status to "Monitoring" only for the restored part, keep a separate line for the rest, and restart the update clock for the remaining problem. In a message that looks like: "Update 13, 15:00. Restored: dashboards can be viewed (Monitoring). Still affected: saving any data change (Investigating). Next update on the saving problem: 15:30."

Worked example (illustrative): a data platform outage, 09:00 to next morning

In that table, reads means viewing data and writes means changing or saving it, so "dashboards read-only" means people can look at data but cannot save changes.

Trade-offs and pitfalls

• Contractual customers with a service-level agreement (SLA, a promise of uptime or response time) may need their own timed notices regardless of your default cadence. That is the case that overrides the table.
• Going quiet during the long middle is the classic failure. Silence gets read as loss of control.
• Widening the audience without shortening the message causes noise; each audience needs its own version.
• Do not downgrade severity just because the update load hurts. Severity follows impact, not effort.