How to Manage Customer Communication During Incidents in SaaS?

Separating the communication role from the incident commander was a game-changer for us. If the IC is deep in troubleshooting, they often forget to update customers. Now, we have a dedicated comms person who posts updates every 30 minutes, even if it's just to say 'still investigating.' This consistency helps build customer trust. We use Statuspage for broad updates and targeted emails for specific affected customers. Implementing the 'next update by X' rule keeps everyone accountable, akin to setting a timer in our incident channel that prompts updates if no one posts in time.

Communications during incidents should really come from customer support teams rather than engineers. It's important for engineers to focus on resolving issues. The communication includes simple, clear updates on what’s happening and what impacts clients. We keep messages succinct and targeted. For example, if systems are down, we might just say, 'We're aware of the issues and working to fix them,' which keeps everyone informed without diving into the technical details. It's crucial to maintain transparency while being concise so customers aren't overwhelmed.

We typically have a designated incident response team, and the product manager is in charge of communications. It's essential to relay updates effectively without engineers dealing directly with customers, as they are busy fixing things. We communicate details like the issue at hand, affected product parts, our progress with fixes, and a rough resolution time if possible. For example, if there's a problem affecting image processing, we might say, 'We're currently having issues impacting image delivery, and we're working hard to restore services.' This way, customers stay informed without overwhelming them with technical jargon.