Software will not decide who owns the price
Most transformation projects in travel fail for one reason that has nothing to do with technology: the company has not decided who owns product and pricing. Software then freezes that confusion in place and makes it permanent.
Why these projects fail, said plainly
A travel company decides to modernise. A system is chosen, configured and launched. Six months later people are still sending prices by message and the system holds a partial copy of reality that nobody trusts. The software is usually fine. What was never settled is who is allowed to decide a price and where that decision is recorded.
You can see it before a single tool is installed. Two people can quote the same product at different prices and both believe they are right. The current rate sheet is an attachment in somebody's inbox, and the really current one is a Zalo message. A discount is whatever the person who answered first agreed to. Nothing in that list is a technology problem, and installing a system on top of it does not remove the ambiguity — it publishes it.
Who is allowed to change a selling price, and where does that change have to be written for it to count. If a company cannot answer that in one sentence, we start there and not with software.
Steps you can stop at
We refuse to run these projects as one long push toward a launch date. Every phase has to leave the business measurably better even if the next phase never happens — because sometimes it should not, and a company that cannot stop cannot say no to its own supplier.
- One product catalogue with stable identifiers. Stop here and you already have a price list everyone shares.
- One place for availability, even if it is still edited by hand. Stop here and double selling largely disappears.
- Enquiries and quotes in a pipeline instead of individual inboxes. Stop here and you can finally see what is being lost and where.
- Confirmed bookings created in the system, with the operational documents generated from it. Stop here and handover between staff stops depending on memory.
- Online selling and payment on top of all of the above. This is where a booking platform belongs — and only here.
Each step is deployed, used for a real period, and reviewed before the next one is quoted. That review is where we most often recommend stopping.
The order that matters: availability and price before marketing
The most common request we decline in its original form is a marketing system first — campaigns, automation, a beautiful funnel — on top of availability that is still a spreadsheet. It works, briefly, and then it works against you. More demand pointed at a system that does not know what is left produces the worst outcome in travel: selling something you do not have, at scale, to strangers.
| Order | What gets fixed | What it prevents |
|---|---|---|
| First | One catalogue, one price, one owner | Two staff quoting different numbers |
| Second | One availability record, updated by one process | Selling a seat twice |
| Third | Pipeline and quoting in one place | Enquiries dying quietly in a personal inbox |
| Fourth | Booking, documents, payment | Reconciliation done by memory at month end |
| Last | Campaigns, automation, scale | Amplifying a problem you have not fixed yet |
If you already have the first two, a campaign is a good investment. If you do not, it is an expensive way to generate complaints.
Lark Base as the landing place between Excel and a platform
Under2 runs its own CRM and project pipeline on Lark Base, and we set it up for clients for the same reason we use it: it is shaped enough like a spreadsheet that staff will actually enter data into it, and structured enough that the data can later be moved somewhere serious.
That middle ground is underrated. A team that has worked in Excel for eight years will not adopt a rigid enterprise interface in a month, but they will adopt a table with columns they recognise, a form to add a record, and a board view their manager reads.
- Enquiries, quotes and follow-ups in a pipeline with owners and dates.
- Forms that staff and partners fill in, which stops attachments circulating by email.
- Views instead of copies — the same records seen by sales, operations and management rather than three divergent files.
- A structure that exports cleanly when it is time to move on.
What it is not: a booking engine. Lark Base will not hold live availability for a public website, will not take payment and should not be the system a guest indirectly depends on. When selling online is the next step, that is the point where izBooking or a custom build belongs, and we say so rather than stretching a tool past what it is for.
Training, and the staff who go back to Excel after three weeks
This happens on almost every project, and it is not a failure of character. Look at the reason before you look at the person. Usually the new system is slower for the one task they perform forty times a day, or the number it shows disagreed with reality once and was never trusted again, or nobody ever explained what the record they are creating is used for downstream.
- Train on the tasks people actually repeat, in their words, not on a feature tour.
- Fix the slow path first. If entering a booking takes four minutes instead of ninety seconds, the spreadsheet will win and it deserves to.
- Make the old sheet read-only on a named date, agreed in advance and communicated. Two live paths means neither is trusted.
- Name one internal owner with time allocated. A transformation with no owner inside the company is a subscription, not a change.
- Watch the first month. Adoption problems appear in week two and are cheap to fix then and expensive to fix in month six.
What to measure
Not "digital maturity". Pick a handful of numbers that a manager can read on a Monday, record them before anything changes, and compare honestly.
| Measure | Before | What good looks like |
|---|---|---|
| Share of bookings created in the system | Often under half | Almost all of them, with the exceptions named |
| Hours from enquiry to quote sent | Unknown, felt as "slow" | Measured, and shorter |
| Price corrections after a confirmation | Nobody counts | Counted, and trending toward zero |
| Double-sold departures per season | Remembered, not recorded | Recorded, and rare |
| Days until a new hire makes a correct booking alone | Weeks | Days, because the process is in the system |
If none of these moves after a phase, that phase did not work, and the review is where we say so rather than proposing the next module.
When not to start
There are seasons and situations where the right advice is to wait, and we would rather lose the quarter than sell into one of them.
- You are in high season. Operations staff have no attention to spare, and the first month of a new system is exactly when attention is required.
- Ownership of product and pricing is genuinely undecided, or contested between two people. Settle it first; it is free and it is the whole project.
- Nobody internal has time allocated to the change. Not enthusiasm — allocated, protected time.
- The company is being restructured, sold or merged. The process you encode this quarter will be the wrong one next quarter.
- A system has already been bought before anyone described the process. In that case the useful engagement is a short review of whether it fits, not an implementation.
The how we work page describes the discovery and acceptance gate we apply to all of this, and the pricing page gives ranges.
Describe how the work flows today
Who takes an enquiry, where the price comes from, what is in a spreadsheet and what is in someone's head. That is enough for a written first step.
What travel operators ask us most
How long does a transformation project take?
Each step is measured in weeks, not the whole programme in months. A catalogue and pricing phase is typically three to six weeks; a pipeline phase similar; anything involving online selling and payment adds the approval time we cannot control.
The total depends entirely on how many steps you decide to take, and stopping after two is a legitimate outcome.
Do we have to replace the software we already bought?
Often not. Plenty of companies own a capable system that was configured before anyone agreed on the process, and the fix is configuration and ownership rather than a new purchase.
We will say when a replacement is genuinely cheaper, and we will say when it is not, including when that means a smaller invoice for us.
Can you train our staff, or do we need our own trainer?
We train the people who will use the system, on their real tasks, and we write short task guides in the language the team works in.
What we cannot supply is the internal owner. That person has to come from your side and needs protected time, because adoption is decided in the first month.
What if our staff simply refuse to use it?
Then something about the design or the sequence is wrong, and refusing is useful information rather than a discipline problem. We look at where the new path is slower or less trustworthy than the old one and fix that first.
If the real cause is that the change was never actually decided at management level, no amount of training will substitute for that decision.
Read next
Tell us what you are trying to run
What you sell, what you use today, and what is breaking. You get a written answer with an approach and a price range - not a brochure.