Best Practices for Customer Communication During Incidents

Separating the communication lead from the incident commander has been pivotal for us. When the incident commander is deep in triage, they often forget to update customers, which can lead to distrust. We use Statuspage for broad visibility and send targeted emails to affected users. Our 'next update by X' policy is strict; we set a timer in the Slack channel as a reminder. If no updates have been made, the comms lead sends a holding message. This has drastically reduced gaps in communication. After the incident, we prefer to send a brief summary to affected customers within 48 hours, rather than a full postmortem, since they usually want to know what went wrong and the steps we're taking to prevent it in the future.

Customer support teams are essential for incident communication. It's crucial that internal engineers aren’t the frontline communicators. They should be fixing issues while support handles the client updates. The key is to make sure our support team has all the needed updates and is prepared to answer questions diligently.

For us, the communication starts with an incident response team, and the product manager determines what to share. It's not ideal to have engineers communicate directly with customers since they need to focus on resolving issues. Typically, as a manager, I relay updates through leadership in customer support or customer success teams. We share what the problem is, what parts are affected, our progress in fixing it, and sometimes an estimated resolution time, though that’s rare. For example, we might inform clients about increased load on our services impacting image delivery, and keep them posted throughout the resolution process.