Tour Guide Software: Two Jobs, One Booking Record

The guide reaches the meeting point with a printed list, the office has a newer version in an inbox, and the travelers in front of the guide match neither one exactly. That gap is where departure day goes wrong. Good tour guide software closes it by putting the right participant information, schedule and equipment in front of the person running the trip, drawn from the same record the office sold and took payment on.

Why Departure Morning Breaks Before the Trip Starts

The printed manifest is from Tuesday. Two travelers have since corrected the spelling of their names, one waiver is still unsigned, and a celiac note sits in the original booking form where the guide can't see it. The van has fewer seats than the list assumes.

None of those errors started that morning. They started when each change landed in a different place and nobody rebuilt the guide's list afterward.

Two Jobs Buyers Mix Up

Tour guide software is the set of tools that puts the right participant information, schedule and equipment in front of the person running the trip. Buyers use the phrase for two different jobs. The first is guide-facing tools: schedules, manifests and participant details. The second is the booking and payments system that creates those details in the first place.

The first job can't fix bad input from the second. A clean guide view built from retyped spreadsheet data is still retyped spreadsheet data, only easier to read.

Guide-facing features only help when they're generated from the same bookings the office takes payments on. Otherwise the business is syncing spreadsheets with extra steps.

That setup is still common, partly because many operators have no booking record to generate anything from. Arival's survey of more than 7,000 operators, run between April and June 2024, found that 39% of tour and activity operators were not using an online booking system. For those businesses, a departure still starts life across a booking form, a spreadsheet and an inbox.

Training won't close that gap on its own. An office can build a short guide quiz online to check that every guide knows what a complete manifest should contain, and that's worth doing before the season starts. But a guide who spots a missing waiver at the meeting point still has a missing waiver. The fix has to happen upstream, where the booking is taken and the traveler details are collected.

So the buying decision isn't about which guide view looks nicest. It's about which setup keeps the guide's list current without someone rebuilding it by hand after every change. If you're also weighing tools for the person who travels with the group on multi-day trips, the tour manager software guide covers that adjacent role.

Three Ways to Run Departures Compared

Departure information lives in one of three places: paper and chat, a staff scheduling tool, or the booking and payments system. What separates them is who updates the guide's information when a booking changes.

Three approaches to guide information

Paper, Spreadsheets and Group Chat

Approach A costs nothing to start, but someone has to keep the list current. A name correction in an email thread does not update the printout in a guide's bag. Once the office and the guide hold different copies, neither can be trusted without a phone call.

Standalone Scheduling or Staff Tools

Approach B handles rosters well. Guides can see who is working each departure, and managers can keep shift schedules out of chat threads. Participant details still come from somewhere else, though. Every booking change has to be copied across, which leaves two records that drift apart.

Scheduling the guide and giving the guide accurate participant information are separate jobs. A standalone staff tool can do the first well and leave the second untouched.

Booking and Payments Back Office With Guide Access

Approach C generates guide information from bookings in the same system the office uses to take payment. When a booking changes, the guide's view reflects it without anyone retyping it into a separate file. Access can be limited to what the guide needs instead of exposing office records.

The cost model varies by vendor. Per-booking pricing scales with revenue; per-seat pricing scales with headcount. Compare current plan terms against how your bookings and seasonal staffing actually move. Neither model is automatically cheaper.

This approach only works if the office treats the system as its booking record. Keep a parallel spreadsheet "just in case" and you keep the manual update problem too.

Whatever the setup, ask one question: if a traveler's name changes on Thursday, will the guide see the correction on Friday without someone retyping it?

What Guides Need on Departure Day

Guides need less information than most systems try to give them, but what they do get has to be current and complete. Three things carry a departure.

A Manifest That Matches the People Standing There

A usable manifest lists each traveler's full name as it appears on the ID they'll show. Multi-day and cross-border trips add passport details. Dietary needs and allergies belong on it because celiac disease and nut allergies change what the kitchen or the picnic stop can serve, not just what the guide mentions in passing.

Rafting, cycling and trekking departures need signed waiver status visible at a glance, plus an emergency contact for every participant. If waivers still arrive on paper, online waiver software is the piece that makes that status visible before the day. These fields map directly onto the duties and responsibilities of a tour guide on the day, because the guide is the person who has to act on them.

• Names and ID details: Matched against the person checking in, not against the name of whoever paid.
• Dietary needs and allergies: Read before food is ordered or packed, not discovered at the table.
• Waiver status: Unsigned forms flagged while there's still time to fix them calmly.
• Emergency contacts: Reachable without calling the office and waiting for someone to search an inbox.

A printed list fails here for a mechanical reason: it's a snapshot from whenever it was printed, and every later change lives somewhere else. A printable PDF manifest is still useful for a boat crew, a lodge or a remote trailhead, but generate it late from the live booking record and treat it as a copy, not as the record itself.

The Schedule in the Calendar Already in Use

Guides need the start time, meeting point, group size against capacity, and any change that arrived after the booking cutoff. That belongs in the calendar app the guide already opens every day, not behind a separate login they'll forget to check on a busy morning. A subscribed calendar feed of departures does this in Google Calendar, Apple Calendar or Outlook, and because the feed is one-way, the booking record stays the only place anyone edits.

Equipment That Isn't Promised Twice

The third need is certainty about gear. The boat, bikes, vehicle or equipment assigned to a departure must not also sit on an overlapping departure, and that risk grows with every departure added to the week. Bike tour companies feel it first: a day ride and a weekend tour drawing on the same fleet is the classic double-promise, which is why bike tour operators need bikes treated as shared capacity. A guide shouldn't have to phone the office to confirm the van exists.

Two-minute test: Pick next Saturday's departure and ask the guide to produce the current name list, every dietary note, every unsigned waiver and the true seat count within two minutes. Whatever can't be produced is a gap in the setup, not a gap in the guide.

Payment details, invoices and revenue reports don't belong in that test. Guides don't need them, and keeping them out of the guide view is a deliberate boundary, not a missing feature.

What the Office Locks In Before Departure

Everything a guide needs on the day has to be collected and locked in days earlier. Departure morning is the wrong time to discover a missing passport number.

Collect Traveler Details Through Tasks

The pattern that works is a reusable task list: required traveler details defined once and attached to every trip that needs them, plus custom tasks for questions specific to a route or destination.

A standard list covers passport details for multi-day and cross-border travel, dietary needs and allergies, waiver acknowledgment, and an emergency contact. The trip-specific questions do the operational work, and they differ by activity.

• Walking and city tours: Mobility, stairs, distance tolerance and preferred pace.
• Rafting and kayaking: Water confidence, swimming ability and relevant medical limits.
• Cycling tours: Height for bike fit, riding experience and comfort with traffic or gravel.
• Food tours and retreats: Allergies separated from preferences, since kitchens treat them differently.

Structured collection matters most where disclosure is awkward. Responsible Travel's November 2025 survey of tour operators on accessible travel found that more than 60% of respondents had booked someone with limited mobility, yet fewer than 8% provided accessibility information on all their trips and only 3% let website visitors search and filter by accessibility needs.

Travelers rarely explain mobility aids, transfer ability or sensory needs cleanly over email or chat, and those threads expose sensitive details to anyone who can open the inbox. A structured form keeps the information in one place, limits who sees it, and gives the guide something usable: a traveler who needs a seat near the door, or one who can't manage the second hill. It also stops the office from promising access the route can't deliver. That handoff is where clear internal roles pay off, a point covered in more depth in team collaboration software for tour operators.

Set the Rules the Guide Relies On

Three settings protect a departure from late surprises. Capacity per departure keeps the group inside the seats, boats or bikes available. A minimum group size flags a departure that won't run early enough to rebook people politely. A booking cutoff sends late changes to the office instead of letting them appear at the meeting point unannounced.

Seven days out, the office check is short. Confirm balances are settled or flagged, chase missing task forms, review the manifest against capacity, and put any late change in writing so the guide isn't working from a phone call nobody else heard.

Payments and Pricing in the Same System

A guide shouldn't be collecting a balance at the trailhead. Money is an office job, and it should be finished before departure day.

Take a fictional example. A 12-seat departure at $300 per person has three travelers still owing balances a week out. Without reminders, someone in the office spends Friday sending payment links and checking the bank account, and the guide may still end up asking for money before the safety briefing. With deposits, installment plans and automatic balance reminders, those travelers pay through a self-service link and the manifest shows the departure as paid in full. The mechanics of payment processing automation are what keep the chasing off the guide.

The record-keeping point is simple. A deposit is cash received, the balance has a due date, and both attach to the booking, not to a spreadsheet tab. A reusable payment-plan template, such as a 30% deposit followed by two installments before departure, keeps terms consistent across every trip instead of negotiated case by case in email.

Stripe's payment processing guidance for travel agencies uses the example of a £200 deposit today and an £800 balance charged automatically on a set date, and recommends stating at checkout whether the deposit is refundable and under which conditions. The same guidance notes that installments can make high-ticket trips such as multiweek tours more accessible. One thing to check with any vendor: a reminder sent after a failed card is not the same as an automatic retry, so ask which of the two the system does.

What the Per-Booking Fee Costs

Samba's pricing is a per-booking model, which makes it a useful worked example. There is no setup fee and no contract. The first $10,000 in bookings is free, then the fee is 2% per booking. The operator can absorb that fee or add it as a service fee at checkout, and a refund returns the 2% as well.

Illustrative fee at 2% per booking

Those figures apply once the first $10,000 in cumulative bookings has been used. Stripe bills its own processing fees separately, and payouts go to the operator's own Stripe account, so the platform never holds the money. Cash or bank transfer payments logged for the record carry no platform fee.

Per-seat pricing scales with headcount, so a business pays more every time it adds guides for high season. Per-booking pricing scales with revenue, so quiet months cost less and busy months cost more. Neither model is cheaper in the abstract. The useful question is which one grows for a reason the business would rather pay for.

One bookkeeping caution applies either way. Deposits should stay linked to their departures and future balances, not booked as revenue the moment they arrive, since the trip hasn't run yet and refunds or credits may still follow.

Features to Check, Then Run One Departure

A departure-day manifest is only as reliable as the booking records behind it. Before choosing a guide-facing setup, check that traveler details, payments and departure information all come from the bookings the office manages.

Six Buyer Checks

Start with role-based access for guides, office staff and partners, and confirm which roles can see sensitive traveler details such as passport and medical information. Then check that manifest fields can match the trip: a food tour and a cross-border trek need different details.

Next, check shared-resource conflict controls for boats, bikes, vehicles and gear. A resource assigned to one departure should not be bookable on an overlapping one. Finally, look for a calendar feed guides can subscribe to, traveler details collected before departure through reusable tasks, and email and transaction logs that show what was sent and when a booking record changed.

Manifest fields by trip type

The person who pays is not always the person who travels. A system should record the buyer separately from the travelers, so group leaders and gift bookings work without putting the payer on the manifest as a participant. If bookings also arrive through an OTA or your own website, confirm they land in the same operating record and not in a separate inbox.

Meeting-point instructions need the same care. Operators who meet groups in stations, museums or large venues can borrow ideas from indoor wayfinding projects in transit hubs and public buildings, such as step-by-step directions from a named entrance. Then collect each traveler's specific access needs in the task form so the guide knows before departure who needs the lift instead of the stairs.

Finally, decide how guides will actually open the manifest. Some systems ship a dedicated guide app with offline mode and a check-in scanner; others run in a browser and rely on a printable PDF as the backup when connectivity is unreliable. Remote departures make that choice matter, so settle it before rollout.

Run One Departure as the Test

Keep the first test narrow. One trip, one departure, real bookings:

1. Connect payments: Make sure payouts go directly to the operator's own account.
2. Set up one trip: Configure its capacity, booking cutoff and minimum group size.
3. Attach the task list: Collect passport details, dietary needs, waivers or emergency information before departure.
4. Invite the team by role: Give guides, office staff and partners access suited to their work.
5. Set up the calendar feed and shared resources: Check the schedule and confirm boats, bikes or vehicles are assigned correctly.
6. Compare the manifest with a printed list: Check names, dietary notes, waivers and seat count.

Add other trip types only after the first departure runs without last-minute corrections. The test takes staff time, so use it to answer one question: does the manifest reflect the booking record, or is it a second spreadsheet with a nicer layout?

Samba was built around that question: guides get a manifest and a calendar feed generated from the same bookings the office takes payment on, with shared resources checked across overlapping departures. It has no dedicated guide app, offline mode or check-in scanner; guides work in a browser, with a printable PDF manifest for remote trips. You can start free, connect your own Stripe account and run one departure to see whether that fits how your guides work.