Trust Recovery Starts Before the Incident, Not After
Trust recovery starts before the incident. Most organizations treat customers as outsiders to protect from technical details but your incident is also happening to them. Withholding context doesn't protect you and wastes the opportunity to demonstrate competency.
How you communicate before and during an incident significantly impacts your ability to retain or recover customer trust. Even when customers understand that there will be occasional issues, they still need to see competent incident management and clear communication. Demonstrating operational maturity during the incident becomes evidence of your organization’s reliability.
Yet, most organizations approach incidents with a defensive mindset, becoming so focused on minimizing perception of the problem that they inadvertently create a trust problem. They treat customers as outsiders to be protected from incident details, when in reality, your incidents aren't just happening to you; they're also happening to your customers. By keeping information from the people who are directly affected, you're withholding context that could actually help them understand and work with you through the disruption.
Moreover, this erosion of trust doesn't simply reset once your team closes the incident — it carries forward, making every future incident harder to navigate as customers approach each new disruption with accumulated skepticism.
What Could Go Right: Reframing Incident Communication
Our “What Could Go Right” principle asks teams to consider:
What if this incident actually demonstrated our organizational strengths?
What if clear communication during the outage became evidence of our reliability rather than proof of our problems?
When incidents occur, this reframing becomes especially powerful because:
Most incidents involve legitimate operational decisions. Many incidents stem from routine maintenance, capacity planning, or protective measures that didn't work as expected. The narrative shift from "we broke something" to "we were being proactive and hit an edge case" requires intentional communication during the incident.
Customers expect operational complexity. Most business customers understand that robust systems sometimes create unexpected interactions. They're more concerned with how quickly and professionally you handle the situation than with the fact that it happened at all.
Operational maturity becomes visible in real-time. How you coordinate between technical teams and customer support during an incident provides customers with direct evidence of your organizational competence. Smooth information flow and clear communication demonstrate the kind of operational excellence customers want in their vendors.
Building Better Incident Communication
Incident response communication shouldn't be a special mode you switch into during emergencies. It should be an extension of how you engage with customers every day. Incidents may be punctuated moments, but they don't happen in a vacuum. The trust and communication patterns you've established during normal operations become the foundation customers rely on when things go wrong.
Think of it like a Formula 1 pit crew making adjustments mid-race. The driver doesn't suddenly freak out at the team because they need to change tires or adjust the wing – they expect the crew to handle these situations smoothly because they've practiced together countless times. The difference between a winning pit stop and a race-ending disaster is the seamless communication and coordination that comes from working as a unified team long before race day.
Similarly, the most effective incident communicators prepare for trust-building opportunities by:
Training customer-facing teams on technical concepts. Your support agents need ongoing education about your systems and operations, not just crisis briefings. When they understand how your infrastructure works day-to-day, they can explain disruptions confidently without revealing sensitive details that could compromise operational security or your competitive advantage.
Establishing clear information-sharing protocols. Technical teams often hold information too tightly during incidents because they've never practiced sharing it during calm periods. Defining what can and can't be communicated (and training teams on those boundaries) enables faster, more confident customer communication when it matters most.
Planning for uncertainty as a normal state. Most technical work involves uncertain timelines, not just incident resolution. Rather than treating timeline uncertainty as an incident-specific problem, successful teams develop frameworks for managing customer expectations around evolving situations as part of their regular communication practice.
Practicing What Could Go Right
Our Discernible Experience incorporates this “what could go right” principle in the tasks assigned to participants each week. Rather than just focusing on technical resolution, our scenarios challenge participants to consider how their incident response choices impact stakeholder trust and organizational reputation.
Participants practice communicating technical security issues into executive- and customer-facing explanations, coordinating between security engineering and cross-functional partners, and managing stakeholder expectations during extended resolution processes. The goal isn’t just to restore service, but to emerge from the incident with critical relationships intact or even strengthened.
Organizations that apply “what could go right” thinking to incident communication often discover that incidents become opportunities to demonstrate their operational maturity. Customers who see competent incident management and transparent communication during outages frequently become more loyal, not less.