What to tell customers while the answer is changing

A customer opens the status page because a report has not arrived. “We are investigating” confirms that someone is awake, but leaves the practical questions untouched: is this my region, should I try again, and when is it worth checking this page?

At 14:15 UTC in this fictional Dispatch incident, the team can answer some of that. Exports in region A are late, both worker versions are affected, and storage behavior is under investigation. There is no reliable recovery estimate. The next internal check-in is at 14:25. A useful update gives people the part of that picture they can act on, without filling the missing pieces with optimism.

One incident, two useful updates

For responders, a draft might read: “Dispatch exports in region A are missing the completion deadline. Both worker versions are affected. We are investigating storage timeouts; the worker and storage owners will report at 14:25 UTC. No mitigation has been executed.”

That last sentence matters to the person comparing results. Nobody has yet carried out an action to reduce the impact, so a change in the chart should not be attributed to an imaginary repair. The update also identifies who is returning with findings and when, without turning the check-in time into a recovery estimate.

The customer version can be shorter: “Some report exports in region A are taking longer than expected. We are investigating the processing delay and will post another update by 14:30 UTC.” It describes the same situation without asking the reader to understand worker versions.

What about “Please retry”? Only add that if the team has checked that retrying helps this operation. A customer trying to be helpful can otherwise add load or submit duplicate work. A workaround is an instruction people may follow immediately; it needs more support than a wish to give them something to do.

Give each reader the detail that helps them move

The storage engineer can use a timeout observation. The customer needs to know whether another submission would help. Leadership may be able to find a missing specialist. Different details serve those different decisions without requiring three different versions of the truth.

If a proposed repair needs specialist review, tell leadership what would unblock it: “We need the storage duty owner to review a proposed repair; escalation is in progress.” A page of logs may contain more information, but it does not necessarily help anyone find that person. Saying “storage is fixed” would do something worse: it would replace an open investigation with a result the team does not have.

The communications owner publishes approved updates through the incident process. That responsibility does not itself grant permission for a risky mitigation or disclosure of restricted information. Establish those boundaries before a real incident, when nobody is waiting for the next sentence to appear.

At 14:23, another region enters the update

Add a new fact to the exercise: delayed exports are now confirmed in region B. Both internal and customer accounts need a prompt correction. For customers: “We have now confirmed delayed exports in region B as well as region A. Investigation continues, and our next update is still due by 14:30 UTC.”

“Now confirmed” describes when the team learned about the wider impact. It does not claim region B’s delay began at 14:23. Keep the earlier region-A update in the timeline. Someone may have read it, made a decision and returned; silently replacing it would make their earlier understanding difficult to account for.

The same care helps when a dashboard starts looking better. “We are seeing recovery” can describe a supported improvement. “Resolved” requires the service’s recovery checks. A customer deciding whether to resume work deserves to know which of those the team has actually established.

14:30 is an appointment, not a promised repair

“When will it be fixed?” is a reasonable question. If there is no dependable estimate, explain the next technical decision and whatever progress can be established, then give a time for the next update. “We do not yet have a reliable estimate; our next update is at 14:30 UTC” promises communication. It does not quietly promise recovery at 14:30.

Suppose that time arrives with no useful technical change. Keep the appointment: “Exports remain delayed in regions A and B. Storage investigation continues, and we do not yet have a reliable recovery estimate. We will post another update by 14:45 UTC.” These are fictional practice times, not a report about a real service.

There is no new fix in that message. There is still useful reassurance: the impact has not been forgotten, the earlier commitment was kept, and the reader knows when to return. Inventing progress would make the update more exciting and less useful.

For security, privacy or contractual matters, follow the organization’s actual review and disclosure requirements. This general service-delay exercise grants no permission to release sensitive details.

Read the two timelines side by side

Compare the internal and customer messages from 14:15. Both should describe region A and the same state of action. Compare them again at 14:23: both should expand visibly to regions A and B, with the earlier account preserved. Judge each update by what was known then, not what the next message will reveal.

The customer who returns to the page should be able to follow what changed. They need neither an invented cause nor an unsupported workaround or finish time. They came looking for their report. Until it is ready, a clear account of the delay, with a kept promise to speak again, gives them something solid to plan around.

Sources

Google’s incident-response guidance covers response roles and communication. The messages and timestamps in this exercise are synthetic.