A booking system can be unavailable while the day's departures still need to run. The difficult moment is often not the first error message. It is the next ten decisions: whether a booking completed, which pickup instructions are current, who can approve a manual action and how the team will avoid duplicating work when access returns.
A short outage rehearsal exposes those decisions before guests are waiting. This guide focuses on operational continuity for a small operator or agency. It is a suggested exercise method informed by public preparedness guidance, not a certification exercise or a claim that any particular vendor is unreliable. The aim is to practice a controlled fallback and a careful return to normal work.
Pick one failure and one business period
Start with a specific scenario rather than “the internet is down.” Examples include the booking workspace being unavailable during morning dispatch, an email provider failing during proposal follow-up or a messaging service being inaccessible before pickup. Different failures require different fallbacks.
Choose a manageable time window and group of tasks. A tabletop exercise can ask the team to describe what it would do during the first hour, using test cases and dummy information. There is no need to disable production systems or interrupt real travelers to learn whether the process makes sense.
The Ready Business guidance treats training, testing and exercises as part of preparedness. For a small travel business, the useful adaptation is to make the scenario concrete enough that people must choose actions. A vague discussion about “keeping customers informed” can feel successful while leaving the contact list, message owner and update timing entirely unresolved.
Identify what cannot wait
List the business outcomes that need to continue during the selected period. For morning dispatch, that may include identifying confirmed departures, contacting the duty team, locating current pickup instructions and recording changes. A future brochure edit can probably wait. A client who cannot find today's meeting point needs a faster route.
For each outcome, note the information and people it depends on. Do not begin with a list of software subscriptions alone. A manifest may be useless without the latest changes, and a contact number may be useless if only one absent colleague knows which person is on duty.
NIST's contingency-planning guide provides a structured reference for planning around system disruption. Its federal-system context is much broader than this exercise. The relevant principle is to connect recovery choices to business needs. Decide your own acceptable delay for each operating task rather than borrowing a technical recovery target that has no relationship to the departure schedule.
Build a limited, protected fallback pack
Prepare only the information required for the chosen operating window. It might include confirmed departure references, essential contact routes, assigned guide and driver information, current meeting-point instructions, outstanding exceptions and the manual-action log. Label the pack with its preparation time, scope, owner and expiry or refresh rule.
Do not export all historical customer data as a default precaution. Minimize information, protect it appropriately and define who can access it. Printed material needs handling and disposal rules just as digital copies need access controls. A fallback should reduce dependency without creating an uncontrolled second customer database.
Test the pack from the position of the person who will use it. Can they open it without the unavailable service? Does a link point back into the very system that is down? Can the backup owner identify whether a copy is current? An offline file that contains only cloud links may provide less independence than it appears to. Record these limitations explicitly and choose a proportionate alternative.
Define what staff may and may not confirm
During an outage, uncertainty must remain visible. A traveler may have submitted payment immediately before the system stopped responding. Staff should not assume success or failure from a browser error alone. Use the approved payment and booking investigation route before asking them to pay again or promising a place.
Write a manual-authority rule. Specify who can accept an enquiry, seek supplier availability, authorize an operational arrangement and confirm a booking under the fallback process, if any such authority exists. If capacity cannot be verified, collect the request and explain the pending check. A manual notebook should not become a reason to sell unverified places.
Also define actions that can safely continue: answering general questions from approved information, recording callbacks and contacting the duty coordinator. This helps staff remain useful without inventing authority. NIST's small-business quick-start guide places response and recovery within wider risk management. Your travel adaptation should likewise connect decisions, responsibility and evidence, rather than treating an outage as only a technical problem.
Give the exercise roles and a clock
Assign a facilitator, an operating decision-maker, a recorder and the staff who would handle the work. In a small team, people may hold more than one role, but someone should preserve what actually happened during the test. Use hypothetical guest and booking data throughout.
Set a start condition: “At 07:15, the normal booking workspace cannot be opened. Three confirmed departures appear in the last prepared schedule.” Then introduce one additional event at a time. A driver asks whether a location changed. A guest reports a payment uncertainty. A supplier calls with an operating update.
Do not reveal the answer while presenting the problem. Ask the team to show where it would find the needed information, who would decide and what it would record. If someone says “I would call the manager,” ask what happens if that person is unavailable. The exercise is useful when it exposes a missing dependency, not when it produces a flawless story helped along by the facilitator.
A hypothetical morning dispatch rehearsal
Imagine a small operator rehearses an outage starting forty-five minutes before the first pickup. The fallback schedule lists the confirmed bookings, but one hotel entrance was changed the previous afternoon. The guide has the new instruction in a private message; the printed schedule still has the old one.
The team stops the simulated dispatch decision and identifies the source conflict. The duty coordinator checks the approved communication record available through the agreed fallback route and contacts the guide. The recorder marks the affected reference, the decision and who must receive the corrected instruction. The exercise reveals that the fallback refresh process did not include late changes.
Next, the facilitator introduces a traveler who says their payment screen froze. The advisor records a pending investigation and explains that confirmation must be checked. They do not create a duplicate booking or request a second payment simply to move the conversation along. This hypothetical exercise has already produced two useful corrections: a late-change refresh check and an explicit payment-uncertainty procedure. Neither requires a real service outage to discover.
Keep a manual-action log that can be reconciled
Every fallback action that could affect a booking, payment, capacity commitment or guest instruction needs a traceable record. Use a temporary reference, time, staff member, related booking or enquiry reference, action, evidence, current status and recovery follow-up. Mark unresolved facts clearly.
Distinguish receiving a request from accepting it. “Guest asked to move date” should remain a request until the appropriate supplier and booking process approve the change. Likewise, “supplier contacted” is different from “supplier confirmed.” Those distinctions make the later reconciliation safer.
Choose one controlled log for the exercise. Separate private notebooks and chat messages can generate conflicting records that are hard to merge. If the team must use paper temporarily, define who collects and transcribes it, how entries retain their original references and how personal data is protected. The log should be usable under pressure, so practice writing an entry while the facilitator introduces another call. Fields that nobody can complete in the scenario may need simplifying.
Prepare messages that admit uncertainty clearly
Draft a short service update for the actual audience. Explain the effect on their task, the current next step and the update route. “We are checking your booking status and will contact you through the agreed channel” is more useful than a technical error description or a confident promise unsupported by the records.
Give existing guests and new enquiries different instructions when their needs differ. A traveler due for pickup may need the duty contact immediately. Someone asking about next month can receive a realistic reply window. Avoid a universal message that sends every contact to the same overwhelmed person.
Assign responsibility for updating and retiring the outage message. When service returns, a stale notice can continue to confuse guests. Do not publish a recovery time supplied by an unverified rumor. If a vendor provides an official status update, record its source and distinguish that report from your own operating decision. A technically restored service may still need checking before your team resumes every action.
Reconcile before declaring normal operations
Recovery is a business workflow. First confirm that the system is functioning for the tasks you need. Then compare the manual-action log with authoritative booking and payment records. Identify actions already completed, actions still pending and any conflicting commitments.
Use stable references to avoid duplicates. If a pending booking appeared after the service returned, match it to the temporary record before creating anything new. Review uncertain payments through the appropriate payment process. Confirm accepted changes and update guest instructions through the normal channel, preserving the earlier evidence where required.
Ready.gov's business emergency-plan guidance connects technology recovery with business recovery needs. In this travel exercise, that means the operations lead, not merely a green status icon, decides when the queue has been reconciled sufficiently to resume normal work. Keep unresolved cases assigned. Record when the fallback pack is retired, how temporary copies are handled and which manual records need retention under your own requirements.
Turn the debrief into a short improvement plan
Ask what the team could not find, what it assumed, which decisions lacked an owner and where duplicate or contradictory records appeared. Separate technical dependency problems from unclear procedures and training gaps. They need different fixes.
For each finding, write the consequence, corrective action, owner, due date and retest. Avoid a long report with no accountable change. Three completed improvements can be more useful than a catalogue of hypothetical disasters. Do not grade staff for admitting uncertainty; those admissions are the evidence the exercise was designed to produce.
Use this debrief checklist:
- The fallback works without the failed service.
- Its scope and freshness are visible.
- Urgent operating decisions have an owner and backup.
- Staff distinguish requests from confirmed commitments.
- Payment uncertainty has a safe investigation route.
- Manual actions can be matched to normal records.
- Guest messages explain a useful next step.
- Recovery includes reconciliation and temporary-data handling.
Retest the most consequential defect after the fix. If the new fallback file still depends on an inaccessible login, the written improvement is not complete.
Keep the rehearsal connected to daily operations
Review the exercise after a material software change, a new sales channel, a new staffing pattern or a genuine incident. The aim is not to rehearse every possible failure. It is to preserve a working understanding of the most important dependencies and the decisions people may need to make without them.
For approved Tripnatic partners, the operator journey provides the relevant listing, availability and booking workspace. Registration requires applicable verification and approval before activation. An outage fallback should respect that workspace's role and the actual booking rules. Do not turn a manual enquiry into assumed reserved capacity or claim an unverified integration.
Connect this exercise with a maintained operating-procedure test. Keep the fallback short enough to use and specific enough to trust. A successful rehearsal ends with staff who can show the next action, the evidence behind it and the route back to an accurate booking record. That is a practical continuity capability a small team can build before its busiest day.
