Incident Management Communication Plan – Do you have one?

A proactive Help Desk team will have Incident Management Communication Plan in place to follow when an outage to a service occurs. In advance of an outage, it is important to develop a well thought-out Incident Management Communication Plan detailing how people will be initially notified, what information they need, when status updates will be communicated, and what resolution steps occur when a service has been restored. Answer the following questions about the state of your Incident Management Communication Plan.

  • Do you have a defined Incident Management Communication Plan to follow when there is an outage to a major service? Have people been trained and know how to access the plan?
  • Are your customers and supported business groups proactively informed of when a service is down or do they generate a large volume of calls to the Help Desk?
  • Are your Help Desk staff members immediately informed about the outage and provided support information such as available workarounds and an estimated time for recovery?
  • Are members of the technology leadership department immediately aware of service outages or are they the “last to know”?

Incident Management Communication

Customers of a service, technical service support staff, and service owners rely on the Incident Management team to obtain the latest status of a service outage and recovery. Incident Management Communication is typically handled in a coordinated effort via email, text messages, voicemail, web portal messages, and phone bridges. Incident Management communication reduces call volume to the Help Desk, allow the business to adjust their work activities, facilitates greater collaboration to resolve the incident, and keeps the leadership team informed of the status.

Objectives of Incident Management Communication Plan

  • Have a detailed approved Incident Management Communication plan documented and readily available for support staff to follow.
  • Have up to date communication distribution groups defined and communication tools in place to send incident status messages.
  • Ensure customers of a service, the leadership team, and technical staff are informed of the start and end of unscheduled outages.
  • Ensure that any workarounds are communicated to the proper groups that use the service.
  • Provide detailed recovery information related to the outage to technical groups.
  • Provide a post-incident summary to the problem management team related to the service.

Customer Focused Incident Management Communication

The goal of customer Incident Management Communication is to let the customer know a service is down and some basic information without a lot of technical jargon. Customers just want to know what service is down, what workarounds are in place, and when will a service be available again. This will allow the customer to make business decisions to maximize their resources. It may mean that they can perform internal communication, provide business direction, and let some of the work force take a break or leave early if applicable.

Customer Focused Incident Management Communication template

Communication Header

  • Recipient list – Who will receive the communication.
  • Subject line – Service name and status.

Communication Body

  • Service name
  • Incident start time
  • Status – Available, degraded, or unavailable
  • High level summary, impact and workarounds – What is not working, who is effected, and any actions that can mitigate the impact.
  • Next update – Time when the next status update will be communicated.
  • For more information – The contact information for the Help Desk.

Technical Incident Management Communication template

The Technical Incident Management Communication template is similar to the customer template but also provides the following;

  • A detailed timeline of recovery efforts
  • The war room bridge information
  • Specific details related to the recovery of the service.

6 Steps to Start Building an Incident Management Communication Plan

  • Identify your major services covered by the plan
  • Identify the customer and technical groups that will receive communication.
  • Establish the frequency of updates.
  • Determine the communication tools used to send incident status messages.
  • Establish and format templates to be used for communication from each communication tool.
  • Establish a bridge number and access code to be used only for war room bridges.

It’s time to be proactive and take control of your Incident Management communication. Implementing an Incident Management Communication Plan before an outage occurs will mature your team, improve the service you provide, and will improve customer satisfaction.

 

6 Comments

  1. Hi,

    would you give any tips on the sort of words to be used in the communication as an example or any examples of how communication is structured for updating users. are there any words that we should avoid using?

    • The most important item is to ensure the message is tailored towards your audience, which should be a non-technical user. Give a high level summary, impact of the issue and workarounds – What is not working, who is effected, and any actions that can mitigate the impact. Above all else make sure it is to the point.

  2. Can a generic change record be kept open for server reboots when required? trying to avoid creating a CR everytime

    thanks

    • For server reboots, i have two suggestions. First rebooting a server may be necessary for break/fix. In that case you should allow the server to be rebooted under the incident management policy. Second a server reboot can be standard practice for a number of reasons such as patch management or other reason. In that case you should have a standard change request process, A standard change does not need CAB approval and is created with a pre-approved process. However you will still need to also setup a scheduled maintenance window to ensure you are not impacting business operations. Let me know your thoughts on these tips.

Leave a Reply

Your email address will not be published.


*