Why spreadsheets break for tour operators at around 30 trips a year (and what actually replaces them)

Most tour operators start in spreadsheets. It’s the right call. You don’t need a stack when you’re running five trips a year — you need to make money. The problem is that spreadsheets carry on looking like the right call long after they’ve stopped being it. By the time you notice, you’ve usually paid for a bad month.

Here are the specific failure modes that show up between roughly 20 and 40 trips a year, and what actually replaces them. None of this is theoretical — it’s the same set of mistakes you can watch operators repeat in real time on LinkedIn every quarter.

The five failure modes

1. Version sprawl on the quote

Someone in your team duplicates a quote tab. Someone else duplicates that. By Friday, there are three “v2 FINAL” tabs, two of which are missing a transfer cost and one of which uses last year’s park fees. Nobody’s wrong — they’re all working from what looked like the latest version when they opened the file.

At five trips a year, you catch this with eyeballs. At thirty, you can’t. The first time a quote goes out with a stale rate, you find out the failure cost is roughly one trip’s margin.

2. Supplier rate drift

Lodges and DMCs update rates twice a year. Sometimes more. If your rates live in cells copied into quote tabs, the rate update has to propagate manually into every open quote, every in-flight proposal, and your rate-card document.

Operators handle this by becoming the kind of person who responds to a supplier rate email by stopping everything else they’re doing for forty minutes. That’s expensive time, repeated maybe forty times a year per supplier across maybe sixty suppliers.

3. Agent and client notes that disappear

Agents tell you things in passing. “The Whitfields don’t do early flights.” “Origin’s clients always want a longer Cape extension.” “This couple are honeymooners but please don’t make it weird.” The first time you remember a detail like that on the call, the agent feels seen. The first time you forget it, the relationship cools.

Spreadsheets don’t hold this kind of context. It lives in someone’s inbox, someone else’s notebook, and a Slack thread from March. When the original person leaves, so does the context.

4. Handover gaps when ops happens

The designer sells the trip. Ops runs it. Sometimes a guide picks it up at the airport. The information the designer holds in their head needs to land cleanly into ops, and again into the guide. With spreadsheets, the handover is whatever the designer remembers to type into an email at 11pm the night before departure.

The cost shows up as small operational errors that compound — a missed dietary, a transfer at the wrong gate, a guest arriving without the welcome letter. None of them catastrophic in isolation. All of them visible to the client.

5. Reporting nobody trusts

At some point you want to know: which agents are profitable? What’s our average margin by trip type? How many quotes are sitting in “sent” for more than two weeks?

With spreadsheets, the answers exist but you can’t trust them. The data definitions drift across tabs. The currencies aren’t normalised. The quote totals don’t reconcile with the booking totals. You spend a Sunday rebuilding the report and then never look at it again.

What people try next (and why most of them don’t work either)

Airtable

Airtable solves the version-sprawl problem. It turns your spreadsheet into a database with relationships, which is genuinely better. The problem is you now have to design the schema — and most operators end up modelling “a trip” as a row with twenty columns and a long-text field, which is just a fancier spreadsheet.

Airtable works if you have one operator who loves data modelling and is willing to keep maintaining the base for the rest of the team. If you don’t, it slowly drifts back into a spreadsheet.

Notion + Pipedrive + Google Docs + WhatsApp

This is what most teams actually end up with: pipeline in Pipedrive, notes in Notion, quotes in Docs, ops in WhatsApp. The whole stack works if you’re willing to re-enter the same data four times. Most teams aren’t, so the data divergence costs you more than the spreadsheet did.

Safari Portal / itinerary builders

These solve the proposal problem brilliantly. Beautiful itineraries, clean client outputs. But they were built around making the proposal look good — not around running the operation behind the proposal. Supplier records, agreements, operational tasking and post-confirmation work tend to be thin or missing entirely.

Salesforce / HubSpot

Generic CRMs. They handle the pipeline competently, but the moment you need to model a trip, a stay, a transfer or a supplier rate, you’re back to custom fields and consultants. We’ve covered the “travel-native vocabulary” point in detail in the buyer’s guide.

What actually replaces the spreadsheet

The system you want is not “a CRM” and not “an itinerary builder”. It’s an operating dashboard — one system where:

• The enquiry, the quote, the trip and the operational tasks are connected, not re-keyed
• Supplier records live in one place with rooms, rates, seasons, contacts and transfers — and update everywhere when changed
• Agreements (STO terms, commission rules, cancellation policy) are linked to suppliers, not stuck in someone’s Drive
• Agent and client context follows the trip — not the person who took the original enquiry
• The proposal that goes out is generated from the structured data, not assembled by hand
• The handover to ops and the guide is generated from the same data — not retyped at 11pm

This is the system we’re building. FieldDesk is the operating dashboard for DMCs, tour operators, agencies, advisors and specialist travel teams. It is not an itinerary app and it is not a CRM. It’s the thing you reach for between them.

The short version

Spreadsheets work until the trips outnumber the people. Around 30 trips a year is when most operators feel the bottom drop out. The next system you buy should model trips, suppliers, quotes, agreements and operations as first-class records, not custom fields on a generic CRM.

If that sounds like where you are, we’d love to show you what we’ve built. Book a demo.