How to Write a Professional SOP: Part 1 — Structure

Tourism Operations Excellence Series · Article S10

Audience

Tourism process owners, operations managers, quality teams, trainers, and SOP writers

Practical tool

Professional Tourism SOP Master Template

Running example

Airport Arrival Transfer SOP

#Structure is a control decision

Two procedures can contain the same basic information and perform very differently.

One begins with six pages of background, hides responsibilities inside paragraphs, mixes normal and exceptional steps, uses inconsistent terms, and ends without records or ownership. The other lets a manager confirm the scope, an employee find the required action, a trainer explain the control, and an auditor trace the evidence.

The difference is not decoration. It is structure.

ISO 10013:2021 gives guidance for documented information that supports an effective quality management system and emphasizes tailoring to organizational need. It does not publish one compulsory SOP template. The structure in this article is a practical tourism model designed for operations that combine guest service, logistics, suppliers, systems, time thresholds, and live exceptions.

The template should be adapted. A simple back-office task may need a short procedure. A high-risk, multi-party airport or MICE process may need a fuller SOP with referenced instructions and tools. What should remain consistent is the logic: the document must explain why it exists, where it applies, who owns decisions, how work is performed, what happens when conditions change, and what evidence shows the result.

#The complete SOP architecture

A professional tourism SOP can use the following sections:

1. Document control information
2. Title
3. Purpose
4. Scope
5. Intended outcomes and service standards
6. Definitions and abbreviations
7. References and related documents
8. Roles, responsibilities, and authority
9. Preconditions, inputs, and required resources
10. Procedure
11. Exceptions, escalation, and contingency
12. Communication requirements
13. Records and retention
14. Performance measures and monitoring
15. Training and competence
16. Approval, effective date, review, and revision history

Not every SOP needs sixteen visible headings. Related sections may be combined when clarity improves. Do not remove a control merely to make the document shorter.

#Document control information

The reader must be able to identify the document and confirm that it is current.

Include, as appropriate:

• document identifier;
• title;
• process/department;
• owner;
• approver(s);
• version;
• status;
• effective date;
• next review date or review trigger;
• information classification;
• source-of-truth location; and
• superseded document.

Example:

Do not use “Final,” “Final 2,” or a date in the filename as the only version-control method. Document Control & Version Management provides the full lifecycle.

#Title

Use a title that describes the controlled process, not the department or a vague concept.

Strong: Airport Arrival Transfer SOP

Weak: Airport Operations

Weak: Guest Service Procedure

The title should be unique within the register and consistent with the process catalogue.

#Purpose

The purpose states why the SOP exists and the result it supports.

Example:

This SOP defines the controlled method for preparing, operating, monitoring, and closing confirmed airport arrival transfers so that guests are met at the approved location and delivered to the correct destination with appropriate service, safety, accessibility, communication, evidence, and exception management.

Avoid generic language such as “to ensure efficiency and quality.” State the process and the result.

#Scope

Scope defines where the SOP starts and ends, which services, locations, teams, and suppliers it covers, and any exclusions.

Example:

Applies to confirmed individual and group arrival transfers operated or coordinated by the company from designated airports to approved hotels or venues. Begins when the approved booking is released to Operations and ends when the guest delivery, required status updates, records, and closure activities are complete. Charter operations, airside services, medical transport, and authority-controlled emergency response are outside scope unless separately approved.

Scope prevents the SOP from being stretched into situations it was not designed to control.

#Intended outcomes and service standards

Define what successful execution looks like.

Possible outcomes:

• confirmed information available by the required cutoff;
• suitable team and vehicle assigned and ready;
• flight and terminal monitored;
• guest met or exception managed according to the approved thresholds;
• accessible and other confirmed service needs delivered;
• guest and client communication accurate and timely;
• service completed and evidenced; and
• exceptions reviewed for learning.

If numeric service standards exist, reference the controlled standard or contract rather than duplicating values likely to vary by client or service category.

#Definitions and abbreviations

Define terms that could affect action or interpretation.

Examples:

• Arrival wave: one or more flights or guest groups managed as a coordinated operating window.
• Meeting point: the current location approved for the relevant terminal/service.
• Potential no-show: a confirmed guest not located after the defined initial checks; not yet a final no-show decision.
• Service owner: the role accountable for end-to-end control of the transfer.
• Material change: a change that affects timing, location, resource, guest requirement, cost, safety, accessibility, or contractual delivery.

Do not fill the section with common words. Define terms that control decisions.

#References and related documents

Show the document’s place in the operating system.

Possible references:

• Guest Service and Safety Policy;
• Airport Transfer Process Map;
• Operational Authority Matrix;
• Verify Flight Status Work Instruction;
• Airport Readiness Checklist;
• Guest No-Show Form;
• Delay and Missing-Guest Message Templates;
• Incident and Escalation Procedure;
• Business Continuity Plan; and
• applicable client, airport, authority, supplier, or contractual requirements.

Reference controlled sources. Do not paste the entire content of every related document into the SOP.

#Roles, responsibilities, and authority

Describe roles before steps so readers understand ownership.

#Process owner

• owns end-to-end performance, review, risk, and improvement;
• approves operational design changes within authority; and
• coordinates cross-functional issues.

#Reservations or handover role

• validates booking information;
• releases the service through the approved channel; and
• manages late changes according to the rule.

#Operations/dispatcher

• validates operational readiness;
• assigns resources;
• monitors flight and vehicle status;
• coordinates exceptions; and
• maintains the operating picture and records.

#Airport representative

• attends the approved location;
• maintains visibility and guest care;
• verifies guest against the current manifest;
• coordinates loading and handoff; and
• reports status and exceptions.

#Driver/transport supplier

• confirms assigned service and readiness;
• operates the vehicle according to approved requirements;
• coordinates with the representative/dispatcher; and
• reports completion or exception.

#Duty manager

• decides escalated issues within authority;
• approves defined cost or service changes; and
• activates higher-level continuity or emergency arrangements when thresholds are met.

Responsibilities should align with the process map and contracts. Avoid listing names; use roles.

#Preconditions, inputs, and required resources

Define what must be available before execution.

Possible inputs:

• approved booking and reference;
• current passenger/guest manifest;
• flight, terminal, date, and origin;
• hotel/venue destination;
• approved pickup/meeting instructions;
• contact and communication permissions;
• accessibility and special service requirements;
• assigned representative, driver, and suitable vehicle;
• supplier confirmation;
• signage/identification;
• approved systems and fallback information; and
• client-specific conditions.

State what happens when an input is missing. “Ensure information is complete” is not enough. Define who returns, corrects, accepts, or escalates the service and by when.

#Procedure

The procedure section follows the validated process sequence. Use numbered stages and conditional instructions.

#Stage 1 — Receive and validate the service

1. Reservations releases the approved booking through the designated source.
2. Operations verifies mandatory information against the process requirements.
3. Missing, conflicting, or changed information is returned or escalated through the approved path.
4. Operations records acceptance and current status.

#Stage 2 — Assign and confirm resources

1. Operations assigns a representative, driver, and vehicle appropriate to the service and confirmed guest requirements.
2. Suppliers receive the current service details through the approved channel.
3. Acceptance must confirm the critical fields, not only acknowledge receipt.
4. Unconfirmed or unsuitable resources follow the escalation and replacement path.

#Stage 3 — Complete readiness checks

1. The representative verifies reporting time, terminal, meeting point, manifest, signage, contact route, and special requirements.
2. Transport verifies vehicle and driver readiness according to the applicable control.
3. Operations reviews unresolved exceptions before the cutoff.

#Stage 4 — Monitor arrival

1. Operations begins flight monitoring at the approved time.
2. Material changes are recorded and communicated to affected roles.
3. Early arrival, delay, terminal change, cancellation, or missed connection follows the defined exception path.

#Stage 5 — Meet and identify the guest

1. The representative reports at the approved location and maintains the required visibility.
2. The representative verifies the guest against the current manifest using proportionate identification controls.
3. The representative provides the approved welcome and next-step information.
4. Unlisted, missing, or incorrectly matched guests are not improvised into the service; the exception route applies.

#Stage 6 — Load and release the vehicle

1. The representative and driver coordinate luggage, guest count, confirmed support, and vehicle readiness.
2. Departure status is communicated through the approved operating source.
3. Vehicle release follows the waiting, missing-guest, and authority rules.

#Stage 7 — Operate and complete the transfer

1. The driver follows the approved destination and service information.
2. Material route, guest, vehicle, or destination changes are reported.
3. Arrival is confirmed at the agreed destination/handoff.

#Stage 8 — Close the service

1. Required completion and exception records are finalized.
2. Operations updates the service status and identifies unresolved actions.
3. The service is released for reconciliation only when closure criteria are satisfied.

The next masterclass article will develop sentence-level procedure writing, action verbs, sequence, time standards, and conditional logic.

#Exceptions, escalation, and contingency

Define categories and triggers, not a generic statement.

Examples:

• missing or conflicting booking information;
• flight early, delayed, cancelled, or moved;
• guest not on manifest;
• guest not located;
• baggage delay;
• unsuitable or unready vehicle;
• staff absence;
• inaccessible route or service;
• hotel/venue change;
• system or communications outage;
• medical, safety, security, or emergency condition; and
• supplier failure.

For each material exception, define first response, owner, response time, authority, guest/client communication, evidence, fallback, and closure. SOP Writing Part 4: Exception and Escalation Management provides the full model.

An SOP should also state when a situation leaves its scope and activates a business-continuity, crisis, emergency, security, medical, or authority-controlled plan.

#Communication requirements

Define communication that is operationally necessary:

• who communicates;
• audience;
• trigger;
• channel;
• minimum facts;
• approval where required;
• update interval;
• language/accessibility consideration;
• privacy restriction; and
• record.

Use templates as controlled starting points, not messages sent without verification.

#Records and retention

List the records created and the system of record.

Examples:

• accepted booking/handover;
• resource confirmations;
• readiness checklist;
• manifest and movement status;
• flight-change record;
• guest-search/no-show form;
• authorization;
• guest/client communication;
• incident record; and
• service completion.

Define owner, access, retention, and disposal through the organization’s record-control requirements. Do not collect personal data without a purpose.

#Performance measures and monitoring

Possible measures:

• booking completeness at handover;
• resource confirmation by cutoff;
• readiness exceptions;
• representative/vehicle readiness;
• guest-location or no-show exceptions;
• on-time completion under the approved definition;
• accessibility requirement delivery;
• record completeness;
• complaints/recovery; and
• repeated exceptions by cause.

Define source, formula, frequency, owner, threshold, and action. Avoid metrics that encourage unsafe speed or conceal complexity.

#Training and competence

State which roles require training, practice, assessment, and refresher triggers.

The competence method may include:

• briefing on purpose and controls;
• guided review of role-specific sections;
• system/task demonstration;
• scenario practice;
• observed performance;
• assessment and authorization; and
• refresher after change, incident, poor performance, or extended absence.

Distribution is not training, and training attendance is not competence.

#Approval, effective date, review, and revision history

The revision history should explain material changes.

Define review triggers such as process redesign, system change, client/contract change, legal or authority requirement, supplier change, incident, audit finding, or performance deterioration. An annual review should not prevent immediate change when risk is material.

#Writing rules for usable SOPs

#Use one accountable action per sentence

Weak: “The manifest should be checked and if there are any problems they should be dealt with.”

Stronger: “Operations verifies the mandatory manifest fields before accepting the service. Missing or conflicting information is returned to Reservations through the late-change workflow.”

#Name the role

Avoid “someone,” “the team,” or passive language when accountability matters.

#Use conditional logic

Write: “If the flight terminal changes after the representative reports, Dispatch confirms the new meeting arrangement and records the update before instructing movement.”

Do not hide decisions in notes.

#Use measurable terms

“Promptly,” “early,” “regularly,” and “where possible” require defined meaning or judgement guidance. Reference approved thresholds where values vary.

#Keep stable and volatile content separate

Stable process control belongs in the SOP. Frequently changing system screens, contact lists, rates, or location details may belong in controlled instructions, registers, or tools.

#Write for point-of-work use

Use clear headings, numbered stages, short paragraphs, tables only for true comparison, and direct references to tools. Test on the device and environment employees use.

#Review the draft through four lenses

#Operational lens

Can the user perform the normal process? Are inputs, steps, handoffs, and closure clear?

#Risk lens

Are material risks, decision points, exceptions, authority, and fallback addressed? Use the findings from How to Conduct an Operational Risk Assessment Before Writing an SOP.

#Guest lens

Does the SOP support clear, accessible, respectful, and continuous service? Use the journey map.

#Assurance lens

Can the organization verify current version, competence, implementation, records, measures, and improvement?

#Common structure failures

#Background overwhelms action

Move long rationale to training or guidance. Keep necessary context, but let users find the procedure.

#Scope is missing

Employees apply the SOP to a service, location, or emergency it was not designed for.

#Responsibilities repeat the job description

List process responsibilities and decision authority, not generic duties.

#Exceptions appear as “notes”

Critical conditions are easy to miss. Give them a visible section and link to the exact procedure stage.

#Records are undefined

The SOP requires “documentation” without naming the record, field, owner, or system.

#The approval page is stronger than implementation

The document has signatures but no pilot, training, access, or usage review.

#Practical tool: Professional Tourism SOP Master Template

Use this outline as the controlled drafting shell:

1. Document control: ID, owner, approver, version, effective/review dates, status, source.
2. Title: unique process-oriented name.
3. Purpose: why the SOP exists and intended result.
4. Scope: trigger, end point, services, locations, roles, exclusions.
5. Outcomes/standards: successful result and referenced requirements.
6. Definitions: terms that change action.
7. References: governing policies, maps, instructions, tools, external requirements.
8. Roles/authority: process accountability and decision limits.
9. Preconditions/inputs: mandatory information, resources, systems, approvals.
10. Procedure: numbered stages, actions, handoffs, decisions, and closure.
11. Exceptions/escalation: triggers, responses, authority, communication, fallback.
12. Communication: audience, channel, facts, timing, templates, privacy.
13. Records: evidence, owner, system, access, retention.
14. Measures: definitions, source, frequency, threshold, action.
15. Training/competence: roles, method, assessment, refresher.
16. Approval/revision: sign-off, effective date, history, change reason.

#Final perspective

The best SOP structure makes the operating logic visible. It tells the reader what result matters, where the process begins and ends, who decides, what must be ready, how work flows, what changes the path, what the guest is told, what evidence is created, and how management knows the procedure still works.

A template cannot replace process discovery or professional judgement. It can prevent important control questions from disappearing.

Structure is therefore not the final formatting stage. It is part of operational design.

• Policy vs SOP vs Work Instruction vs Checklist vs Form vs Template
• SOP Writing Part 4: Exception and Escalation Management
• Document Control & Version Management
• Existing portfolio: The Tourism Quality and SOP AI Toolkit
• Existing portfolio: The Assignment Engine