External Communications

When an incident is affecting your customers, you must ensure that they are regularly updated during the outage or degradation. It's part of your role as a service provider to keep your customers up to date on the status, impact, and cause (and possibly other key details as well). Regardless of how you communicate or what tools you use to communicate incidents, changes, or other general messages, there are a set of principles that we recommend following to create the best possible customer experience.

Incident Communications Style Guide

Work to create an incident communications style guide that will help to ensure that your company has a singular voice and tone during the incident response process (regardless of who executes it or when or where the incident occurs). Here are some good core guidelines to follow; however, keep in mind that you should consult with your own corporate communications and legal guidelines to ensure that your specific incident communications style guide meets the requirements of your company at the corporate level.

No Personal Identifiable Information (PII) or Security/Privacy Events Don't publish any customer information or details related to security, privacy, or data loss events without consultation or review from your legal, security, or leadership teams.
Personal and Conversational Use contractions and first person to give a conversational tone, but don't use information contractions (like that'll).
  • "We're investigating a problem in your environment." Not "[Company name] is investigating some customer environments."
Use Active Voice by Default However, passive voice can be helpful to avoid spotlighting blame.
Active Voice Passive Voice
We routed connections to an alternate data center. Connections were routed to an alternate data center.
We deployed an update with a code problem. An update was deployed that contained a code problem.
Keep it Simple Use concise and simple sentences.
Don't Publish Internal Information Leave out any terminology or phrases that can't be easily found in a public web search. Spell out all acronyms on first use (except for any pre-approved acronyms that you've defined).
Don't Air Dirty Laundry Don't paint us in a bad light, admit wrongdoing, imply negligence, or reference a single point of failure.
  • "An engineer forgot to run the maintenance SOP" vs. "An unexpected problem occurred during regularly scheduled maintenance operations."
  • "A single network adapter became degraded" vs. "A subset of network routing infrastructure became degraded."
  • "A lack of capacity is causing systems to experience high CPU usage" vs. "An unexpected traffic pattern is causing a subset of infrastructure to perform below expected levels."
Use a Standard Time Zone Start times, end times, and any other times that are posted to customers should clearly indicate which time zone it's being presented in so no one has to guess. That should be consistent so your customers know what to expect and the dates and times should be provided in as much detail as possible.
Example: Monday, January 1, 2022, at 00:00 UTC
Stick to the Facts
  • Don't make commitments that something will never happen again.
  • Avoid subjective descriptors like "We quickly identified the problem."
Use Pre-Approved Templates and Phrases
  • Always use your designated template structure as a framework to make your communications consistent, speed up their development, and avoid mistakes.
  • Avoid certain loaded words, or words banned by your company's legal team.
Peer Review and Sanity Check Always have another person review any customer-facing content before sending. Have a quality assurance (QA) document as a reviewer's guide.

Peer Review

If you're asked to perform a peer review, have a checklist established that you can use to review a coworker's incident communications. You can use the example below as a starting point.

  1. Writing Check
    1. No spelling or grammar errors
    2. Statements are clear and concise
      1. Brief and understandable by a general tech audience
      2. Not needlessly wordy or repetitious
  2. Content Check
    1. Acronyms are spelled out (unless on an approved list)
    2. No internal information or PII
      1. Team names, customers names or content, or anything you can't find in a web search
    3. Technical accuracy
      1. Technical terms used in the correct context
      2. Server types or purposes referenced
    4. Logical progression of actions taken and current status
      1. By resolution, we provide a complete picture without missing any context
      2. Not jumping from "We're restarting a subset of services" to "We finished deploying the patch" without context
  3. Taxonomy Check
    1. Time zone and any calculations are correct
      1. Next update not scheduled for the past or too far in the future
    2. Any other selections specific to your incident communications platform are correct