Never Write an SOP Before Mapping the Process

Tourism Operations Excellence Series · Article S06

Audience

Process owners, tourism operations managers, quality teams, SOP writers, and supervisors

Practical tool

As-Is/To-Be Tourism Process Mapping Worksheet

Illustrative context

Hotel pickup and airport-transfer operations

#The danger of starting with a template

An operations manager asks a supervisor to write the hotel-pickup SOP. The supervisor opens a standard template and describes the process:

1. The guide reaches the hotel.
2. The guide meets the guests.
3. The guests board the vehicle.
4. The driver departs on time.

The procedure is clean and almost useless.

It does not show how the final guest list reaches the guide, how hotel zones affect sequence, who verifies a changed pickup time, how accessibility or child-seat needs reach Transport, what happens when a coach serves several hotels, how a missing guest is handled, who may release the vehicle, how the dispatcher knows the coach has departed, or what evidence closes the service.

The problem is not poor writing. The problem is that writing began before discovery.

ISO’s process-approach guidance emphasizes understanding connected activities, inputs, outputs, controls, measures, and risks. A procedure should be built on that understanding. It should not be used to discover the process while simultaneously declaring the process approved.

The operating rule is simple:

Map what happens, test what should happen, then write how it will be controlled.

#The process people describe is rarely the whole process

Managers, supervisors, and employees see different parts of the same work.

A manager may describe the approved workflow. A dispatcher describes the live coordination. A guide describes guest behavior and hotel conditions. A driver describes loading and route constraints. Reservations describes booking changes. Finance describes evidence and supplier reconciliation. The guest experiences the gaps between all of them.

No single interview gives the complete picture.

The real process may also include invisible work:

• checking several messages to find the latest time;
• calling a colleague because the system field is unclear;
• rewriting a manifest for the guide;
• keeping a personal list of reliable suppliers;
• using a screenshot when connectivity is weak;
• asking a hotel desk to find a missing guest;
• delaying system closure until a client answers; and
• making an unofficial decision because the authority path is too slow.

Some workarounds are unsafe or inconsistent. Others are intelligent responses to a design gap. The mapping team must understand why the workaround exists before removing it.

#As-Is and To-Be: two different maps

#The As-Is map

The As-Is map represents the current process as it is actually performed. Its purpose is not to blame employees or make the company look disorganized. It establishes evidence for improvement.

The As-Is map should show:

• actual triggers and end points;
• real information sources;
• actual roles and suppliers;
• duplicate checks and rework;
• waiting and queues;
• informal handoffs;
• failure points and workarounds;
• guest touchpoints;
• records actually created; and
• differences by shift, client, market, or service type.

Do not clean the map during discovery. If the team draws what it wishes occurred, the later SOP will preserve the wrong assumptions.

#The To-Be map

The To-Be map represents the approved future process after the team has evaluated value, risk, customer needs, authority, technology, competence, and feasibility.

It should remove unnecessary complexity while retaining necessary controls. It should define a clear source of truth, ownership, handoff, exception route, evidence, and measurement.

The To-Be process is not automatically valid because it looks simpler. It must be tested. Removing a verification step may reduce waiting but increase the risk of sending the wrong vehicle. Automating a message may improve speed but create a privacy or accuracy risk. Centralizing approvals may improve cost control but delay service recovery.

#Define the process before drawing it

Complete a one-page definition first.

#Purpose

What result must the process produce for the guest, client, and company?

Example: collect confirmed guests from their assigned hotels and deliver them to the event venue according to the approved movement plan, with appropriate guest care, timing, accessibility, communication, and evidence.

#Trigger

What event starts the process?

“The guide arrives at the hotel” is too late. The process may start when the approved movement plan is released or when the final pickup manifest becomes effective.

#End point

When is the process closed?

Vehicle departure is not necessarily closure. The operation may need venue arrival confirmation, missing-guest disposition, completed counts, incident status, and system update.

#Inputs and outputs

Inputs may include guest list, hotel, pickup window, destination, vehicle, accessibility, client instructions, contact details, signage, and authority rules.

Outputs may include guests delivered, exceptions resolved or escalated, records completed, client status updated, and service ready for reconciliation.

#Scope and variations

Does the map cover private transfers, shared pickups, MICE coaches, cruise movements, VIPs, children, accessible services, or after-hours work? One map may not fit every variation.

#Collect evidence, not only opinions

#Observe the work

Watch the process at the point of delivery. Observe a dispatch shift, hotel departure, airport arrival, or tour-file handover. Record sequence, waiting, questions, corrections, system use, and communication.

Observation should be ethical and proportionate. Protect guest and employee privacy. Do not record personal information unnecessarily. Explain the improvement purpose and avoid turning mapping into covert performance surveillance.

#Review records

Examine actual manifests, handover messages, dispatch logs, incident forms, complaint records, supplier confirmations, and change histories. Records show variation that interviews may forget.

Ask:

• Which fields are commonly missing?
• How many versions circulate?
• Where are changes recorded?
• Which exceptions recur?
• Which evidence is incomplete?
• Which work is performed outside the approved system?

#Interview across the handoffs

Interview the person who supplies the input, the person who performs the work, and the person who receives the output.

Use questions such as:

• What must be true before you can begin?
• Where do you obtain the information?
• How do you know it is current?
• What do you verify?
• What normally goes wrong?
• What do you do when it goes wrong?
• Which decision requires approval?
• What do you produce, and who receives it?
• How does the next person know the handoff is complete?
• What would make the work safer or easier?

#Walk one real case end to end

Select a completed service and reconstruct the journey from booking to closure. Use timestamps and records. A real case exposes transitions that generic discussion misses.

#Build the As-Is map

#Start with five to ten stages

For hotel pickup:

Release plan → validate manifest → assign team/vehicle → confirm readiness → position at hotel → call and board guests → release vehicle → arrive at venue → close movement.

Agree on the boundary before adding detail.

#Add swimlanes

Possible lanes:

• Client/Sales;
• Reservations;
• Operations/Dispatch;
• Hotel Representative or Guide;
• Driver/Transport Supplier;
• Hotel;
• Venue Team; and
• Guest.

Include systems as lanes only when system responsibility or automation matters. Otherwise annotate the activity.

#Add decisions and exceptions

Examples:

• Is the manifest complete?
• Has the vehicle confirmed readiness?
• Is the hotel loading point available?
• Are all expected guests present?
• Has the waiting threshold been reached?
• Is the guide authorized to release the coach?
• Has the venue accepted arrival?

Each decision needs clear outcomes. “Escalate if necessary” is not a branch.

#Add information and evidence

Show the manifest, movement plan, briefing, vehicle confirmation, guest count, departure status, incident record, and completion update.

The Fleet Control Tower illustrates the value of one operating picture. The map should identify where that picture receives and validates information.

#Add guest experience

Mark what the guest sees and feels: message before pickup, signage, staff visibility, waiting, boarding clarity, luggage support, updates during delay, accessibility, and arrival guidance.

This layer connects process efficiency with service quality.

#Analyze the map before designing the future

#Handoff risk

Look for information that changes owner without confirmation. A departure time sent in email but not updated in the manifest is a classic control gap.

#Waiting

Identify where people or vehicles wait for information, approval, guests, loading space, or another supplier. Not all waiting is waste; some is a deliberate buffer. Distinguish protective capacity from unmanaged delay.

#Rework

Find activities repeated because the original input was incomplete or untrusted. Multiple teams may rebuild the same guest list because no source is reliable.

#Overprocessing

Identify approvals or reports that do not change a decision or satisfy a real requirement. Remove them carefully; a control may have a purpose that is not visible to the person performing it.

#Failure demand

Separate normal value-creating work from work generated by previous errors: clarification calls, repeated confirmations, corrected tickets, new manifests, complaint handling, and supplier disputes.

#Authority gaps

Find decisions employees face without clear limits: release a coach, change a vehicle, add waiting, split a group, contact a VIP, or incur recovery cost.

#Accessibility and inclusion gaps

Check whether accessibility needs are captured, confirmed, handed over, and delivered across the complete journey. ISO 21902 addresses stakeholders across the tourism supply chain, including tour operators, transport, MICE, contractors, and suppliers. A single “wheelchair” field is not a complete accessible-service process.

#Evidence gaps

Ask whether the process creates factual, proportionate records at the right moment. If a supervisor cannot reconstruct what happened without calling several people, the evidence design is weak.

#Design the To-Be process

#Begin with the intended outcome

Do not begin by adding technology. Define the guest and business result, then select the simplest controls that can reliably deliver it.

#Establish one source of truth

Name the system or controlled document that owns critical information. Define change permission, timestamp, notification, and fallback.

#Design the handoff contract

For each handoff, define sender, receiver, required information, timing, acceptance, exception, and evidence.

Example:

Reservations releases the final movement manifest to Operations by the agreed cutoff. Operations confirms acceptance or returns identified gaps within the response window. Changes after cutoff follow the late-change path and create an alert to affected roles.

#Put decisions with the right role

Move routine decisions to the role closest to the work within approved limits. Escalate high-consequence or cross-functional decisions. This reduces delay without losing governance.

#Design normal and exceptional paths together

Test at least three scenarios:

• expected operation;
• common exception; and
• high-impact disruption.

For hotel pickup, test a complete group, one missing guest, and an unready vehicle or inaccessible loading point.

#Define evidence and measures

Decide what must be recorded and how performance will be reviewed. Avoid collecting fields that no one owns or uses.

#Assign implementation work

The To-Be map may require system changes, supplier agreements, training, new tools, data cleanup, or authority approval. The SOP cannot compensate for an unimplemented dependency.

#Validate before writing

#Tabletop walkthrough

Give participants a scenario and walk the map step by step. Ask who acts, what information they use, what decision they make, and what evidence they produce.

#Field pilot

Use the future process on a controlled service. Observe usability, timing, workload, guest communication, and system behavior. A pilot should have defined success criteria and a rollback or fallback plan.

#Exception simulation

Simulate a flight change, missing guest, vehicle failure, system outage, or late client amendment. How to Conduct an Operational Risk Assessment Before Writing an SOP helps select scenarios.

#User acceptance

The process owner approves the design, but users must confirm that the process is understandable and feasible. Acceptance does not mean every personal preference is adopted. It means concerns are evaluated and decisions recorded.

#Convert the validated map into documents

Only now should the team decide what documentation is required.

• process definition and map for the end-to-end flow;
• SOP for controlled execution;
• work instructions for detailed tasks;
• checklist for critical readiness or confirmation;
• form for structured evidence;
• template for recurring communication;
• authority matrix for decisions; and
• KPI definitions for performance.

Use the map to maintain traceability. Each procedure step should correspond to an activity, decision, control, or handoff. Each major process risk should have a designed treatment or escalation. Each required record should support a defined purpose.

#Common mistakes

#Mapping the ideal process as the current process

The team loses the evidence needed to understand gaps and adoption difficulty.

#Blaming the person shown in the box

The map describes system behavior. A repeated manual correction may be caused by poor input design, workload, or system limitations.

#Automating a broken process

Automation makes the wrong path faster and harder to see. Simplify and validate first.

#Designing without suppliers

Transport, hotels, venues, attractions, guides, and other partners may perform critical steps. Invite them or validate assumptions with them.

#Using one workshop as proof

A workshop captures opinions. Combine observation, records, real cases, and pilot evidence.

#Writing the SOP while decisions remain open

Writers fill gaps with assumptions. Record unresolved issues and assign owners before approval.

#Practical tool: As-Is/To-Be Tourism Process Mapping Worksheet

#Final perspective

The first draft of an SOP should not be the first time the organization sees its process.

Mapping creates the shared evidence needed to design the right method. It reveals where value moves, where information weakens, where the guest waits, where employees improvise, where suppliers influence delivery, and where authority is missing.

When the As-Is process is understood and the To-Be process is tested, the SOP writer is no longer guessing. The writer is converting an approved operating design into controlled, usable information.

That is the difference between documenting activity and engineering reliable service.

• Procedures, Processes and Process Maps: What Is the Difference?
• How to Conduct an Operational Risk Assessment Before Writing an SOP
• How to Apply Customer Journey Mapping to SOP Design
• Existing portfolio: The Assignment Engine
• Existing project: InfraCluster