Procedures, Processes and Process Maps: What Is the Difference?

Tourism Operations Excellence Series · Article S04

Audience

Tourism operations managers, process owners, quality teams, trainers, and supervisors

Practical tool

Tourism Process Definition and Mapping Sheet

Illustrative context

From confirmed booking to completed airport transfer

#Why the distinction matters

A tourism manager asks for an airport-transfer SOP. A writer opens a template and begins with “The driver reports to the airport.” The document looks organized, but it misses the sales handover, guest requirements, resource assignment, flight monitoring, representative, dispatch decision, hotel arrival, service evidence, and financial closure.

The writer has documented a fragment of activity, not the process.

This is one of the most common reasons procedures fail. Teams begin with sentences before they understand flow. They describe what one role does while the service actually moves through several roles, systems, suppliers, and guest touchpoints. The result may be grammatically correct and operationally incomplete.

ISO’s process-approach guidance explains that processes consist of related activities and controls that transform inputs into intended outputs. It also connects the process approach with risk-based thinking and the Plan-Do-Check-Act cycle. This is highly relevant to tourism: an airport transfer, excursion, hotel movement, quotation, complaint, or event arrival is not one action. It is a connected service flow.

The practical distinction is:

• Process: what flows from trigger to result;
• Process map: the visual model of that flow; and
• Procedure or SOP: how the organization controls and performs the work.

They support each other, but they are not interchangeable.

#What is a process?

A process is a set of interrelated activities that uses inputs to produce an intended result. In tourism, that result normally combines an operational output with a guest or client outcome.

For a confirmed airport transfer:

• Trigger: a confirmed, approved booking is released to operations;
• Inputs: passenger, flight, hotel, contact, accessibility, vehicle, commercial, and client information;
• Activities: validate, assign, confirm, monitor, meet, transfer, update, close;
• Outputs: guest delivered to the correct destination, client informed, evidence retained, supplier and financial status ready for reconciliation; and
• Customers: guest, client, downstream hotel or event team, finance, and management.

A process has boundaries. If the beginning is unclear, work arrives inconsistently. If the end is unclear, services remain open, records are incomplete, and suppliers or clients dispute what occurred.

A process also has an owner. The owner is accountable for the end-to-end result even though multiple roles perform the activities. Without an owner, each department may optimize its part while the total guest journey deteriorates.

#What is a procedure?

A procedure describes the specified way an activity or process is carried out. In everyday operations language, organizations often use “procedure” and “SOP” together. The label matters less than the document’s function and control.

A professional SOP normally explains:

• purpose and intended result;
• scope and boundaries;
• definitions;
• responsibilities and authority;
• required inputs and preconditions;
• main operating steps;
• decision points and exceptions;
• communication and escalation;
• records and evidence;
• measures; and
• document approval and control.

The procedure should translate the approved process design into usable instructions. It should not invent a different process. If the map shows that Operations must validate accessibility requirements before assigning a vehicle, the SOP must define that control. If the SOP contains a client approval step that is absent from the process design, the process architecture should be updated or the inconsistency resolved.

#What is a process map?

A process map is a visual representation of activities, decisions, roles, handoffs, and flow. It helps people see relationships that prose can hide.

A simple map may show:

Confirmed booking → validate information → assign resources → confirm suppliers → monitor flight → meet guest → release vehicle → arrive at hotel → close service.

A detailed map may add:

• different lanes for Sales, Reservations, Operations, Airport Team, Transport, Guest Service, and Finance;
• decisions such as missing information, flight change, guest not found, vehicle unready, or hotel changed;
• information systems and documents;
• waiting points and time thresholds;
• guest-visible touchpoints;
• records; and
• escalation paths.

The map is a model, not the operation itself. Its level of detail should match the question. A leadership map may show eight stages. A mapping workshop may need thirty steps. A work instruction may need screen-level detail that does not belong on the end-to-end map.

#One transfer, three views

The difference becomes clearer when the same service is represented three ways.

#Process view

The process view states the purpose, boundary, inputs, outputs, customers, owner, measures, and connected subprocesses.

Purpose: deliver a confirmed guest from the designated airport meeting point to the correct destination safely, punctually, and with appropriate communication and evidence.

Boundary: starts when an approved booking enters Operations; ends when delivery and required records are completed and the service is released for reconciliation.

Main stages: handover, validation, assignment, readiness, monitoring, meeting, transfer, arrival, closure.

#Map view

The map shows who does what and where the work crosses a boundary.

Sales releases the approved service. Reservations validates the core booking. Operations assigns the team. Transport confirms the vehicle. The airport representative prepares the meeting point. Dispatch monitors the flight and vehicle. The representative meets the guest and confirms loading. The driver operates the movement. Operations monitors completion. Finance receives the approved closure status.

The map also exposes the handoffs:

• Sales to Reservations;
• Reservations to Operations;
• Operations to suppliers and field team;
• airport representative to driver;
• driver to hotel or venue; and
• Operations to Finance and Quality.

#Procedure view

The procedure defines how the process is controlled. It specifies what information must be validated, how resources are assigned, when readiness must be confirmed, how flight changes are handled, what constitutes a no-show risk, who may release the vehicle, what evidence is required, and how the service is closed.

This view contains the operating rules and instructions the map cannot carry cleanly.

#The hierarchy of detail

Processes and documents work best when the level of detail is intentional.

Trying to put every level on one page produces either an unreadable map or a vague procedure.

#Map the process before writing the procedure

The map provides the skeleton. The procedure adds the controls, responsibilities, evidence, and explanation.

Before drafting, the team should answer:

1. What event starts the process?
2. What result marks successful closure?
3. Who supplies each required input?
4. Which inputs are frequently missing or changed?
5. Which roles, systems, and suppliers participate?
6. Where does responsibility or information transfer?
7. What decisions alter the normal path?
8. What does the guest see, wait for, or need at each touchpoint?
9. Which failures could affect safety, accessibility, timing, cost, privacy, or reputation?
10. Which records and measures show whether the process worked?

The companion article Never Write an SOP Before Mapping the Process explains the discovery method in detail.

#Choosing the right type of map

#High-level flowchart

Use a high-level flowchart to establish stages, boundaries, and major decisions. It is useful for leadership, scope agreement, and training orientation.

#Swimlane map

Use swimlanes when responsibility and handoffs are central. Each lane represents a role, team, system, or supplier. The map reveals bouncing work, duplicate checks, unclear ownership, and approval delays.

For a DMC, swimlanes are often the most useful starting point because service crosses organizational boundaries.

#Service blueprint or journey-linked map

Use a journey-linked map when the guest experience must be connected to backstage operations. It separates what the guest sees from support activities, systems, supplier actions, and evidence. How to Apply Customer Journey Mapping to SOP Design develops this approach.

#Decision map

Use a decision map when several conditions create different actions. Examples include no-show management, weather decisions, accessibility arrangements, coach-release authority, or complaint escalation.

#Data or information-flow map

Use an information-flow map when the main risk is version control or system handoff: which system owns the flight time, hotel, passenger count, vehicle, message, or service status.

No map type is universally best. Start with the operational question.

#Use consistent, simple notation

Teams do not need to become specialist modelers to produce useful maps. A small, consistent vocabulary is enough:

• rounded shape: start or end;
• rectangle: activity;
• diamond: decision;
• arrow: direction of flow;
• document symbol or note: information/record;
• swimlane: responsibility; and
• connector: continuation or linked subprocess.

Name activities with a verb and object: “Validate booking,” “Assign vehicle,” “Confirm readiness,” “Meet guest,” “Close service.” Avoid labels such as “Operations” or “Airport” that do not describe action.

Name decisions as questions with clear branches: “Is required information complete?” “Has the guest been located?” “Is the assigned vehicle ready?”

The map should represent approved reality, not what the team hopes happens.

#Handoffs are where tourism processes weaken

Many failures are not caused by a person performing a technical task badly. They occur because responsibility or information crosses a boundary without clear acceptance.

Examples include:

• a quotation promises an inclusion that Operations does not see;
• a changed hotel is updated in email but not in the dispatch plan;
• the airport representative finds the guest but does not notify the driver;
• the hotel desk changes a departure time on one printed list;
• a supplier acknowledges the service but not the accessibility requirement;
• the night shift assumes the morning shift has received the update; and
• the driver marks a movement complete before the guest reaches the agreed point.

For every handoff, define:

• sender and receiver;
• required information;
• required format/system;
• timing;
• acceptance or confirmation;
• exception response; and
• retained evidence.

The existing portfolio article The Assignment Engine shows how assignment quality depends on matching guest, task, person, timing, and context—not simply filling an empty slot.

#Connect the process to measures

A process map becomes more valuable when the team identifies where performance can be observed.

Possible airport-transfer measures include:

• percentage of bookings complete at the operations handover;
• supplier confirmation within the approved lead time;
• resource-readiness exceptions before service day;
• on-time representative and vehicle readiness;
• guest-location time after exit;
• vehicle waiting and release exceptions;
• successful completion without avoidable escalation;
• record completeness; and
• complaint, recovery, or dispute rate.

Each measure needs an operational definition. “On time” is not useful until the event, threshold, source, exclusions, owner, and response are defined.

The process owner should use measures to learn where the system is weak, not to punish employees for every variation. If bookings routinely arrive incomplete, measuring only driver punctuality misses the real constraint.

#From map to SOP: a controlled conversion

Use the approved map as the drafting outline.

1. Convert the process purpose and boundary into the SOP purpose and scope.
2. Convert lanes into responsibilities and authority.
3. Convert inputs into prerequisites and required information.
4. Convert activities into procedure steps.
5. Convert decisions into conditional instructions and exception rules.
6. Convert handoffs into communication and confirmation requirements.
7. Convert records into evidence and retention requirements.
8. Convert process measures into KPI definitions or monitoring requirements.
9. Reference work instructions, checklists, forms, templates, and systems.
10. Test the draft against normal and exceptional scenarios.

The SOP should remain traceable to the process. If a reviewer cannot identify where a procedure step fits in the map, the team should ask whether the map is incomplete, the step is unnecessary, or the process has changed.

#Common mapping mistakes

#Mapping departments instead of work

Boxes say “Sales,” “Operations,” and “Finance,” but no action or result is visible. Use verbs and objects.

#Starting at the employee’s first task

The true trigger and upstream quality conditions disappear. A dispatcher may inherit a bad booking that the map never shows.

#Ignoring the guest

The map shows internal actions but not waiting, uncertainty, information needs, accessibility, or recovery. The process can appear efficient while the experience remains weak.

#Mapping only the happy path

Tourism operations include delay, absence, changes, shortages, technology failure, and supplier variation. Add the important decision branches without turning the map into a maze.

#Adding system-screen detail too early

The map becomes obsolete and unreadable. Keep system clicks in work instructions unless the data flow itself is the process risk.

#Creating a map no one owns

The map is placed in a workshop folder and never updated. Assign an owner, version, effective date, and review trigger.

#Practical tool: Tourism Process Definition and Mapping Sheet

Complete this sheet before opening mapping software.

Run the map with a real case. Ask each participant to explain what they receive, what they verify, what they produce, and how the next person knows the handoff is complete.

#Final perspective

A process is the operating flow. A map helps the organization see that flow. A procedure governs how the flow is performed.

When teams confuse them, they write documents around fragments and miss the relationships that determine service quality. When they connect them, the process map becomes a shared model, the SOP becomes a controlled method, and employees can see how their task contributes to the guest’s complete journey.

The sequence is simple: understand the result, map the flow, design the control, then write the procedure.

• Never Write an SOP Before Mapping the Process
• How to Apply Customer Journey Mapping to SOP Design
• How to Write a Professional SOP: Part 1 — Structure
• Existing portfolio: The Fleet Control Tower
• Existing project: InfraDispatch