Rehearse how a critical service keeps going

This one-hour tabletop exercise helps a service owner and the teams around them talk through a disruption before one happens. You discuss decisions and handoffs. You change no systems and contact no customers. The worked example follows Northwind Provisions, a fictional company, and its regional order-support service. If a real incident is under way, use your organization's active incident communication route, not this page.

Colleagues around a whiteboard covered in sticky notes

60-minute agenda

Authored example agenda for a facilitator, not a live schedule. Adjust the timings to your group.

60-minute agenda
Time Activity Output
0:00–0:05 Frame the scenario and the exercise boundary Everyone can state the scenario and what is out of scope
0:05–0:20 Map essential activities and their dependencies A short list of what must continue, what can wait, and who depends on whom
0:20–0:45 Rehearse role decisions and handoffs The first decision each role needs from another team, and who makes it
0:45–1:00 Capture learning actions Three to five actions, each with a responsible role and a follow-up point

Scenario and scope

Read this aloud to open the session, then use the prompts to settle the boundary.

  • The scenario It is the last Thursday of the month, Northwind's busiest week for urgent orders. The shared workspace the order-support team normally uses to receive, track and assign requests becomes unavailable at 9:30 and is not expected back until the next day.
  • The service in focus Regional order support: receiving urgent customer requests, assigning each to an owner, and passing work to warehouse and billing teams.
  • Who is affected Order support, the warehouse dispatch team, billing, and the customer-team liaisons who speak to enterprise customers every day. Ask the room which other teams belong on this list.
  • In scope Discussing continuity options, dependencies, priorities and who needs to decide what.
  • Out of scope Changing any real system, contacting real customers, or testing safety-critical procedures. Park those questions for the learning actions.
  • Prompts to settle before you start Which service priority matters most today? What do you need to know in the first 30 minutes before you can choose a response? Who would you expect to hear from, and who would expect to hear from you?

Essential activities versus preferred ways of working

Work through the sample with the group, then repeat it for your own service.

Must continue
Essential: receive urgent requests

Customers still need a way to raise something urgent, and someone still needs to see it within the working day.

  • Ask: where could a request arrive if the usual workspace is down?
  • Ask: who checks that channel, and how often?
Must continue
Essential: assign an owner to every urgent request

An urgent request with no named owner is the first thing to fall between teams.

  • Ask: how do we record who owns what without the shared view?
  • Ask: who can reassign if the owner is unavailable?
One way, not the activity
Preferred method: the shared workspace

The workspace is how the team normally does the two activities above. It is not the activity itself, so the group can discuss alternatives and what can be deferred, such as routine status updates and weekly reporting.

  • Ask: which dependencies, such as dispatch or billing, need the information in the same form?
  • Ask: what can wait until the workspace returns?

Run the role exercise

Three fictional roles take part: service owner, request coordinator and customer-team liaison. Add your own roles as needed.

  1. 1

    Open the scenario

    Read the scenario aloud and give each role two minutes to note its own first concern. Facilitator prompt: "The workspace is unavailable. What is the first decision your role needs from another team?"
  2. 2

    Take it role by role

    Each role states what it would do first, what it needs to know, and who it would contact. Example: the request coordinator says, "I need the service owner to confirm which fallback channel we are using before I can tell dispatch."
  3. 3

    Add a timed update

    After about 10 minutes, announce: "It is now 11:00 and three urgent requests have arrived by phone." Ask each role what changes, and who knows about the three requests.
  4. 4

    Review the handoffs

    Ask each pair of roles: "What did you pass to them, in what form, and how would you know they had received it?" Note every handoff that depended on the unavailable workspace.
  5. 5

    Stop at the boundary

    If the discussion turns to fixing a real system or drafting customer messages, note it as a learning action and bring the group back to the scenario.

Record learning actions

Each participant keeps notes using these five prompts. Nothing here is submitted or assigned automatically.

Observation

What did the exercise show? Write what you saw, not who was at fault.

Proposed action

One concrete thing that would help, small enough to describe in a sentence.

Responsible role

A role, not a person, so the action survives team changes.

Decision or dependency needed

What must another team decide or provide before the action can move?

Follow-up point

When the group will check progress, for example the next monthly service review.

Worked example

Observation: urgent requests have no shared view when the workspace is down. Action: assess an agreed fallback record. Role: service owner, with the customer-team liaison. Needs: agreement on who can see the record. Follow-up: next service review.
  • Observable: the group can check whether a fallback record exists
  • Names a role and a follow-up point