SOP Writing Part 4: Exception and Escalation Management

Tourism Operations Excellence Series · Article S13

Audience

Tourism operations managers, duty managers, process owners, quality teams, event controllers, and SOP writers

Practical tool

Exception and Escalation Matrix

Running example

A MICE airport-to-hotel movement with simultaneous disruptions

#The paragraph that weakens many SOPs

“In case of any issue, contact the manager.”

It is one of the most common sentences in operating documents, and one of the least useful. It does not define an issue, indicate when the normal process is no longer safe or achievable, identify which manager is on duty, set a response time, explain what the frontline team may do while waiting, or describe the information needed for a decision.

Tourism rarely runs in a perfectly controlled environment. Flights arrive early, guests change plans, baggage is delayed, roads close, suppliers substitute resources, systems stop responding, weather affects an activity, and a client requests a change during delivery. An SOP that covers only the expected sequence leaves its most important decisions to memory and improvisation.

Exception management does not mean writing a script for every imaginable problem. It means designing a controlled method for departures from the expected path. The method should help the team identify the condition, protect people and the service, distinguish operational authority from emergency authority, select an approved response, communicate accurately, keep evidence, and return to a stable state.

This is where procedure, risk, continuity, customer care, and management authority meet.

#Define the levels before writing responses

Teams often use “issue,” “incident,” “emergency,” and “crisis” as if they mean the same thing. The labels themselves matter less than a shared, approved classification. One practical model is:

These are illustrative definitions, not universal legal categories. A company should align them with applicable law, authority guidance, contracts, insurance, venue or airport rules, and its business-continuity and emergency plans.

The distinction matters because different situations require different command structures. A delayed coach is usually an operational exception. A collision with injuries is not a “transport delay” to be solved only by dispatch. The team must know when local emergency procedures take priority and when business-continuity arrangements support, rather than replace, the competent response.

#Start with the objective and tolerances

Every exception is a departure from an expected condition. The SOP therefore needs an explicit operating objective and meaningful tolerances.

For a MICE arrival movement, the objective may be to receive confirmed delegates, care for them at the arrival point, allocate them to the correct transport, and deliver them to the designated hotel within the approved programme and service conditions.

Tolerances may cover:

• minimum confirmed vehicle capacity;
• allowable dispatch variation;
• maximum waiting period before the next decision;
• information cutoff for manifest changes;
• cost authority by role;
• approved substitution rules;
• service, accessibility, and safeguarding conditions;
• client-notification thresholds; and
• evidence required before closure.

A tolerance is not permission to conceal poor performance. It is an approved boundary within which a role can act without unnecessary escalation. If the situation moves outside that boundary, the next decision owner becomes clear.

The risk assessment should determine which tolerances and triggers are necessary. See How to Conduct an Operational Risk Assessment Before Writing an SOP.

#Design the escalation architecture

An effective escalation path answers seven questions.

#What triggers escalation?

Use observable conditions where possible:

• assigned coach has not reached the staging point by the readiness deadline;
• confirmed capacity is below the current passenger count;
• guest requiring an accessible vehicle cannot be served by the assigned resource;
• group is likely to miss a timed venue entry or onward connection;
• client requests a material change after operational release;
• an unverified person requests passenger information;
• a supplier fails to respond after the stated attempts and interval;
• injury, safeguarding concern, missing vulnerable guest, or credible threat is reported; or
• the operating team loses access to a critical system or current manifest.

“When necessary” is not a trigger. Neither is “if serious,” unless seriousness is defined.

#Who owns the first response?

The person who sees the exception needs immediate actions within their competence and authority. These may include protecting the guest, stopping an unsafe action, checking the current operating source, separating verified facts from assumptions, preserving contact, and notifying the control role.

The SOP should not ask frontline staff to wait passively when a safe, approved stabilizing action is available.

#Who decides at each level?

Use roles, not personal names. A typical path might be:

1. airport representative or driver;
2. movement controller or dispatcher;
3. duty operations manager;
4. event lead or head of operations;
5. designated incident, continuity, crisis, safety, security, or executive role.

The path may branch. A safety or safeguarding trigger may bypass normal commercial authority. A personal-data concern may require the privacy or information-security role. A client change may require commercial approval as well as operational feasibility.

#How quickly must the role respond?

Set service-appropriate response expectations: immediate notification for protective issues, a defined acknowledgment time for live operational exceptions, and a decision or update interval where resolution takes longer.

Avoid setting arbitrary times in a generic corporate template. Response requirements should reflect consequence, speed of onset, guest exposure, programme dependency, contractual commitments, operating hours, and actual staffing.

#What authority is available?

Define authority for actions such as:

• delaying or releasing a movement;
• substituting a vehicle, guide, hotel, attraction, or route;
• buying an emergency service within a limit;
• changing guest allocation;
• offering approved service recovery;
• informing the client;
• suspending a supplier;
• activating an offline process;
• calling relevant emergency services; and
• activating continuity or incident coordination.

Authority should include constraints. A manager may approve additional transport cost but not waive a safety, accessibility, immigration, insurance, or data-protection requirement.

#What information must travel with the escalation?

A weak escalation transfers anxiety. A strong escalation transfers a decision-ready picture.

One concise briefing structure is FACT:

• Facts: What is confirmed? What remains unverified?
• Actions: What has already been done to stabilize or investigate?
• Choices: Which safe, feasible options exist, and what authority or decision is required?
• Time: When is the decision needed, and when will the next update be provided?

Example:

Facts: Coach C12 has a reported mechanical warning and remains at the staging area. Forty-two delegates are ready; the hotel journey normally takes approximately 35 minutes. Actions: driver has stopped movement, supplier control has been notified, guests remain with two hosts, and water is available. Choices: approve backup coach B07 with an estimated arrival of 18 minutes, or split the group across two confirmed vehicles with sufficient capacity. Decision required: authorize the selected replacement and related cost. Time: decision needed in five minutes to protect the programme; next update in ten minutes.

The exact times and options must be verified in the live operation. The structure prevents opinion from being presented as fact and gives the decision owner something actionable.

#What happens if the assigned person cannot be reached?

Every live escalation path needs a fallback:

• primary role and approved channel;
• secondary role or duty number;
• number of attempts and interval where appropriate;
• next level if no acknowledgment occurs;
• offline alternative if a system or channel fails; and
• rule for immediate protective action.

A contact list without coverage hours, alternates, and maintenance ownership is not a reliable escalation system.

#Write exception content inside the SOP

Exception control should not be hidden only in a separate emergency manual. The operating SOP needs enough information for the user to recognize and route the condition. It can then reference specialized controlled plans.

A useful exception section contains:

1. the exception or trigger;
2. immediate stabilizing action;
3. restrictions or prohibited action;
4. role to notify and required channel;
5. information required;
6. decision authority;
7. response or update time;
8. approved options or referenced contingency;
9. guest/client communication owner;
10. records required; and
11. criteria for closure, handover, or plan activation.

The step sequence should distinguish what the employee shall do from what the decision owner may authorize.

#Practical tool: the exception and escalation matrix

The following abbreviated matrix shows the design logic. Values are illustrative and must be approved for the actual operation.

The matrix should not become unreadable. High-complexity responses can reference a work instruction, contingency plan, contact directory, or role card.

#A multi-exception MICE scenario

Consider an evening arrival wave with three flights and 160 delegates. One flight lands early. The first coach reports a warning light. Twelve delegates are not on the current printed manifest, and one traveller has a confirmed wheelchair-accessible transfer requirement. The hotel asks to move part of the group to a different entrance because another event is checking in.

Without a control model, each team member may solve a different problem. The airport host starts calling reservations. The driver asks the hotel for direction. The supplier dispatches a smaller vehicle. The client receives three conflicting updates. The printed manifest gains handwritten changes that never reach the movement controller.

With a controlled model:

1. The representative verifies the current passenger data and separates unverified names from confirmed allocations.
2. The driver follows the vehicle safety response; the coach is not released merely to protect timing.
3. The movement controller establishes one operating picture and logs each exception.
4. The accessible transfer remains protected as a specific service requirement, not traded away for general capacity.
5. The duty manager decides replacement capacity and cost within the authority matrix.
6. The hotel entrance change is verified, assessed for movement and accessibility effect, approved, and issued through the controlled change channel.
7. The event lead receives one FACT briefing with impact, actions, options, decision needs, and next update.
8. Hosts communicate only confirmed guest-facing information.
9. Completion, unresolved issues, cost, and required follow-up are recorded before handover or closure.

The team does not need a separate escalation for every symptom if the issues are interdependent. The controller groups them into a coherent operating picture while maintaining ownership for each action.

This control-room approach is expanded in When the MICE Plan Changes, The Fleet Control Tower, and The Abu Dhabi MICE Movement Control Room.

#Communication during exceptions

Good service communication is not an apology template added at the end. It is a controlled part of response.

The SOP should assign:

• who communicates with the affected guest;
• who updates the client or travel partner;
• who coordinates with suppliers and venues;
• who may communicate externally or publicly;
• which facts are approved for release;
• language, accessibility, privacy, and channel considerations;
• update frequency when resolution is not immediate; and
• how communications are recorded.

A useful guest update usually acknowledges the situation, states what is known without speculation, explains the action under way, gives a realistic next update, and provides a way to obtain help. It should not expose another guest’s information, assign blame before facts are established, or promise an outcome outside the communicator’s authority.

Technology can support prepared messages and faster status management, but human review and authority remain essential. The Guest Experience AI Toolkit discusses responsible support for guest communication.

#Record the decision, not only the problem

An exception record should allow another authorized person to reconstruct:

• date, time, service, location, and reference;
• who identified and classified the exception;
• verified facts and information sources;
• people or services affected;
• immediate actions;
• notifications and acknowledgment times;
• options considered;
• decision, authority, rationale, and time;
• communications issued;
• recovery and completion status;
• cost or contractual effect;
• linked incident, complaint, supplier, or corrective-action record; and
• closure owner and follow-up date.

Do not collect sensitive information merely because a form has space. Access, retention, and sharing should follow approved requirements.

An exception register is valuable because repeated “small” deviations may reveal a systemic issue: late supplier confirmation, unclear handover, poor master data, unworkable cutoff, or an SOP step that does not match reality.

#Close, review, and learn

Operational closure is not the same as learning. The guest may have reached the hotel while cost, client response, supplier action, record reconciliation, or corrective work remains open.

Define closure criteria:

• people are safe and the service is stable or formally handed over;
• affected parties have received the required update;
• operational records are complete;
• temporary changes are reconciled into the source of truth;
• costs and approvals are captured;
• required reporting is initiated;
• an owner and date exist for outstanding actions; and
• the event is screened for review, trend, or corrective action.

Review depth should be proportionate. A routine deviation may need trend coding. A material incident may need a structured review that separates immediate cause, contributing conditions, control failure, and organizational learning. Avoid a search for the person to blame; examine why the system allowed the condition or failed to detect and recover from it.

ISO 22301:2019 provides requirements for business-continuity management systems, while ISO 22313:2020 offers guidance on applying them. Operational exception management should connect to, not compete with, the organization’s continuity arrangements. If a disruption crosses the approved activation threshold, the SOP should route the team to the relevant plan and governance.

#Test the exception design

An escalation matrix that has never been exercised may fail under pressure. Test realistic scenarios through walkthroughs, tabletop exercises, simulations, or controlled drills.

Check whether participants can:

• identify the trigger;
• find the current document and contact path;
• take safe immediate action;
• distinguish fact from assumption;
• reach an authorized role;
• use the fallback when that role is unavailable;
• produce a decision-ready briefing;
• protect guest communication and information;
• work offline where designed;
• keep an adequate record; and
• hand back to normal operations.

Exercises should test nights, weekends, supplier interfaces, and simultaneous events—not only office-hours scenarios with every manager present.

#Common design failures

#Escalate everything

If every minor variation goes to the general manager, the process is slow and management attention is diluted. Give competent roles clear tolerances and authority.

#Escalate nothing until failure is visible

Late escalation removes options. Use leading triggers, such as unconfirmed capacity by a deadline, not only the final failure.

#Create a long phone tree

A phone tree is not governance. Identify the decision owner, the backup, the required information, the response expectation, and the next level.

#Focus only on cost

Tourism exceptions may affect safety, accessibility, dignity, privacy, programme, contract, trust, and staff welfare. Consider the full consequence.

#Use uncontrolled messaging groups as the only record

Fast channels can support coordination, but the authoritative decision and required evidence must reach the controlled record.

#Confuse service recovery with root-cause correction

An upgrade or apology may restore the guest relationship. It does not correct the process weakness that caused the issue.

#The writing test

Before approving the SOP, select the five most credible operational exceptions and ask a trained person to use the document without coaching.

Can the person tell:

• that the normal path has been exceeded;
• what must happen immediately;
• what must not happen;
• who owns the next decision;
• how to reach that role and the fallback;
• what information to provide;
• which options are within authority;
• who communicates with the guest and client;
• what must be recorded; and
• how the operation is returned or handed over?

If the answer depends on “everyone knows,” the SOP is incomplete.

The structural foundation is covered in How to Write a Professional SOP: Part 1 — Structure. Together, structure and exception management turn the SOP from a description of ideal work into a practical operating control.

#Key takeaway

Professional tourism operations do not eliminate every exception. They reduce preventable variation and make the remaining variation visible, owned, time-bound, authorized, communicated, evidenced, and learnable. The best escalation section is not the most dramatic. It is the one a competent employee can use calmly when the plan changes.