Communicating with Stakeholders

Effective Stakeholder Communications

Proactive stakeholder communications advise others on the scope of impact and progress of an incident. When stakeholders are given proactive status updates, the primary response team can focus on resolution rather than answering status inquiries, leading to more efficient incident response and improved MTTR.

There are several aspects to preparing for effective stakeholder communications:

  • Establishing who to inform during an incident.
  • Understanding the various methods of adding stakeholders as subscribers to incidents.
  • Understanding how to send status updates to stakeholders.

Note

This feature is available to customers on our Digital Operations plan and as part of the Modern Incident Response package. Please contact our Sales Team if you would like to upgrade to a plan with this feature.

Who to Inform During an Incident

For any given incident, there are usually two factors to consider when deciding which stakeholders to inform:

  • What functionality, or service, is impacted?
  • What is the scope of impact?

Most organizations will have an incident classification scheme that is used to represent the impact - such as “Priority 1” through “Priority 5”. Generally speaking, the higher the incident classification, the more stakeholders are involved. For example, a Priority 3 incident with very limited customer impact might have no need for stakeholders, while a Priority 1 incident impacting a significant portion of a service’s customers might have IT management, executive leadership, and customer support as stakeholders. Some incidents may also benefit from specific additional stakeholders such as marketing, sales, or legal.

Organizing Stakeholders by Team

As with many aspects of incident response, preparation is essential for making the best use of in-incident response time. Proactively knowing which stakeholders are needed for various kinds of incidents can improve your incident response’s effectiveness. We suggest that you organize these stakeholders into PagerDuty teams - one team per functional area. For example, you might have the following teams of stakeholders defined:

  • IT Management Stakeholders
  • Executive Stakeholders
  • Customer Support Stakeholders
  • Sales Stakeholders

When it comes time to subscribe stakeholders to an incident, you can now pick from these defined teams rather than select many individual users one-by-one.

Stakeholder Users

Any kind of PagerDuty user can be added as an incident subscriber: the account owner, managers, responders, etc. There are special Full Stakeholder and Limited Stakeholder user licenses available; these users can be subscribed to incidents and receive incident status updates. Full Stakeholders have read-only access to other data in your PagerDuty account, while Limited Stakeholders only have access to view and subscribe to the status dashboard, and do not see any other parts of PagerDuty. Full Stakeholders and Limited Stakeholders cannot add, edit or delete any objects in the account. Both Stakeholder user licenses are available at a reduced price and are ideal for employees that need to be involved in internal incident communications but won't be actively participating in the resolution effort. Please contact our sales team for more information about both types of Stakeholder users.

Add Subscribers to an Incident

Automatically Adding Subscribers at Incident Creation

You can set up PagerDuty so that certain incidents will automatically subscribe the right stakeholders when they are created. To do so:

  1. Create a response play that subscribes users and/or teams. If you frequently subscribe the same sets of stakeholders to incidents, you can simplify this task by adding those groups to the play. Here’s an example response play that subscribes multiple stakeholder teams:

This is also easily done in the mobile app:

  1. Attach the response play to a PagerDuty service by navigating to Configuration, select Services, click the name of the service and click Edit Service on the right. In the Incident Settings section, check the Response Play checkbox, and select your desired response play:

This will ensure that every new incident created on the service will run the response play, which will subscribe it’s stakeholders to receive all status updates subsequently published for that incident.

Note

The act of subscribing stakeholders to an incident does not cause them to receive a notification. This “silent subscription” allows you to subscribe stakeholders to an incident at any time (for example, at incident creation) and then explicitly choose to publish a status update if and when there is something noteworthy to report. Thus, stakeholders receive only curated updates, which helps avoid notification fatigue.

Add Subscribers to an Ongoing Incident

Users and teams can be subscribed to an active incident from the PagerDuty web app.

To add subscribers to an ongoing incident:

  1. On the Incidents page, open an incident to view the details. Go to the Status Updates tab on the incident details page.
  2. In the Subscribers field, search and select the team or specific users you’d like to add.

Self-Subscribing to Incidents via Status Dashboard

For accounts with the Status Dashboard add-on product, users that subscribe themselves to a business service on the dashboard will then be added as incident subscribers on any incidents that impact that business service.

Sending Status Updates to Subscribers

Once subscribed to an incident, stakeholders can expect to receive all subsequent manual status updates on that incident. Status updates can be published in three different ways:

  • A responder can compose and publish a status update ad-hoc in the incident’s Status Updates tab via the web or mobile app.
  • A responder can run a response play that publishes a predefined status update via the web or mobile app.
  • A responder can publish a status update or run a response play that publishes a predefined one via the API.

Send Status Updates via Web App

Publishing a status update ad hoc in the web app is beneficial when the content is context-dependent. For example, if a status update needs to provide details about the nature of the incident, the current impact, or the estimated resolution time:

To send a status update via the web app:

  1. Navigate to the Incidents page in the web app and click the Title of the active incident to view the incident details page.
  2. Select the Status Updates tab. In order for a status update to be published to the Status Dashboard, it is required that you enter an Incident Priority and select the Impacted Business Services:
  1. Once those details have been entered or confirmed, click the New Update button in the Status Updates section. Ensure that the following dialog confirms that your update will be published to the status dashboard:

If the dialog says that it will not be published to the status dashboard, return to the incident’s Status Updates tab and verify the required details from step 2 have been entered.

  1. Enter a message and click Send Update. Status updates will appear in the incident timeline.

Send Status Updates via Response Play

In other situations the status update may be less context dependent. For example, notifying stakeholders about the onset of a P1 incident or announcing incident resolution. In these cases you can automate the status updates using a response play.
A response play can publish a status update in combination with subscribing stakeholders and/or adding responders. Here’s an example response play that would be suitable for attaching to a service so that whenever that service has a new incident, the identified stakeholder is subscribed and immediately receives a status update notification:

Alternately, a response play such as the following can be used as a one-click wrap-up after an incident has been resolved, and could be run from either the web app or the mobile app:

Status Update Notification Methods

Status updates will be sent to users via their first email contact method and first SMS contact method, and their last push contact method in their user profile.

[Callout: We currently do not offer customized notification rules to notify on a specific channel; if you do not wish to receive updates on a certain channel we recommend leaving that contact method blank.]

Email Status Update

Status update emails contain the most information about an incident:

  • Who sent the status update
  • Incident number and description
  • When the incident was opened
  • The affected service
  • Incident status
  • A link to the incident status page

Subscriber Notifications

Once subscribed to an incident, stakeholders can expect to receive all subsequent manual status updates on that incident. Subscriber notifications will be sent the status update via their first email contact method and first SMS contact method, and their last push contact method in their user profile.

We currently do not offer customized notification rules to notify on a specific channel; if you do not wish to receive updates on a certain channel we recommend leaving that contact method blank.

Notification emails contain the most information about an incident:

  • Who sent the notification
  • Incident number and description
  • When the incident was opened
  • The affected service
  • To whom the incident is currently assigned
  • Incident status
  • A link to the incident status page

SMS Status Update

Push Status Update

Status Dashboard Update

For incidents that appear on the status dashboard, all status updates will also be posted to the status dashboard. See this article for more information on how to show an incident on the status dashboard.

Remove Subscribers from an Incident

Users assigned to the incident can remove subscribers from an incident, and subscribers can choose to unsubscribe themselves.

If you are a user assigned to the incident and you want to remove a subscriber:

  1. Go to the Incident Details page.
  2. Click on the Status Updates tab.
  3. Under Subscribers, click the name of the subscriber you want to remove.
  4. Click Remove Subscriber.

Other Features to Facilitate Incident Response

Alternatives to engaging non-incident-related stakeholders are:

Communicating with Stakeholders


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.