Philippines staffing blog ·
Stop Duplicate Status Updates During an Outage
One incident record, one update owner, and a single customer channel prevent five agents from sending five different truths.
Direct answer
Operational guidance
Name one update owner
During an outage, everyone wants to reassure the customer. The result is often three slightly different messages in ten minutes, each with a different estimate. Assign one person to own the customer-facing update, one to own the technical investigation, and one to own the internal coordination. The help desk can feed information to the update owner without sending its own version.
Use one source of truth
Create a single incident record with the start time, affected services, known impact, current mitigation, next update time, and the name of the update owner. Link every related ticket to it. Agents should read the incident record before replying, not rely on a chat message that may be stale. When the record and the chat disagree, the record wins and the chat is corrected.
Write updates with four parts
A useful update says what is affected, what the customer can do now, what the team is doing, and when the next update will arrive. Avoid guessing a restoration time unless the technical owner has confirmed it. Replace "we are working on it" with a specific next checkpoint. If there is no workaround, say so plainly rather than implying one exists.
Suppress duplicate outbound messages
Before sending a bulk update, check whether the same message has already gone to the affected group. Use a channel or tag that marks who has been notified. If a customer replies to an individual ticket, respond in the ticket but do not trigger a second company-wide notice. The goal is one clear message, not maximum coverage.
Give the desk a holding macro
Agents need an approved reply for the period before the first official update. It should acknowledge the incident, state that the team is aware, point to the status channel, and give the next update time. It should not speculate about cause or resolution. A good holding macro prevents improvisation and reduces the number of conflicting messages.
Close with a short review
After the incident, record the actual timeline, the updates sent, the customers who received them, and any duplicate or contradictory messages. Ask whether the update cadence was met and whether the content was accurate at the time. The review is about the communication path, not about finding someone to blame for the outage.
Authoritative sources
- Google Site Reliability Engineering, Managing Incidents
- Atlassian, Incident Management Handbook
- NIST SP 800-61 Rev. 3, Incident Response Recommendations