Travel

The customer is usually more than one person

A family of five. A group of eleven walkers. A couple where one does all the arranging. A company sending four people to a conference. In almost every booking there is a person who enquired, a person who pays, and a set of people who travel, and those three sets overlap differently every time.

What almost every system does is offer one customer per booking, so ten names go into a notes field. It works, in the sense that the booking completes. It fails the following January, when those ten people are invisible: they cannot be searched for, cannot be marketed to, have no history, and are not people you know. You sold eleven holidays and acquired one relationship.

Holding people and organisations as one family, connected with roles, is what fixes this. The booking is an opportunity. The lead passenger is a relationship. The party members are relationships connected to it. It is thirty seconds more work at the point of booking and it is the difference between a customer list and a mailing list.

The enquiry is long, and going quiet is not dying

Someone planning a significant trip takes weeks and often months. They enquire in January, go silent in February, come back in March having spoken to two competitors, and book in April. A pipeline borrowed from business to business software, where an opportunity that has not moved in three weeks is at risk, describes none of that and will tell you to write off half your best enquiries.

Name your own stages, put a likelihood on each, and keep the stage history. What that gives you is the ability to distinguish waiting from gone, which in this trade is the entire skill of running a pipeline. It also tells you the truth about where you lose people, which is very often at the quotation rather than at the price.

Long silences are not peculiar to travel. The consultancy page describes the same difficulty in a pipeline where every opportunity is large, slow and personal, and the reasoning there transfers to a family planning a significant trip.

The dates run the business

Departure is fixed and everything else counts backwards from it. Balance due at twelve weeks. Passport checked at eight. Final documents at two. Rooming list to the hotel at three. Each of those is work with a deadline attached to a booking, and in most travel businesses it lives in a spreadsheet and someone's memory.

Tasks against the booking, appearing in a daily view of what is due and what is late, is a small change with a large effect: the chase becomes visible to whoever is covering instead of being the private knowledge of the person who is on leave in August, which is exactly when they will be.

It is not a reservation system

Consonas holds no inventory. It does not connect to a global distribution system, does not talk to a bed bank, does not issue a ticket, does not price a package, does not hold structured flight data and does not produce an itinerary document.

Those are the core of a reservation platform, they are genuinely difficult, and they are not what this product is. An operator who needs them needs one, and should buy one.

What operators use it for alongside one

The pattern is a business with a reservation system that handles a confirmed booking competently and knows nothing about the four months before it existed. The enquiry, the brief, the three revised quotations, the competitor they were also talking to, the party members who are not the lead passenger, the reason it did not happen.

Those live in a shared inbox and a spreadsheet in most travel businesses, and they are the part of the operation that determines whether you get the booking at all.

What would make it fit better

Reading from a reservation system so the confirmed booking, the balance position and the departure date appear against the relationship without being typed twice. The connector framework exists, the list of systems it speaks to is short, and this trade is not on it yet. The roadmap says that plainly rather than describing it as coming soon.

The record is a party, not a person

The lead traveller, the people travelling with them, and whoever is paying. A booking is about a group, and a system with one contact per record forces you to lose two of the three.

Create the travellers as relationships and connect them, with the role on the connection. Below Enterprise most businesses model the party as an organisation, which works and is a simplification worth knowing you have made.

Record the source on every enquiry

Travel enquiries come from a small number of channels and convert at wildly different rates. The source report is the number that decides where the marketing money goes, and it cannot be reconstructed later.

Accept that a long enquiry going quiet is normal

A holiday enquiry can go silent for six weeks and still convert. That means the ordinary instinct for whether something is alive stops working, and the stage history is what replaces it.

Put the dated follow ups in

The deposit balance date, the departure, the documents. Also the one everybody skips: the enquiry that said we are thinking about next year, which is the best converting follow up in this trade and the one no one makes.

Then leave the sequences alone for a season

One season of real enquiries tells you where people actually go quiet, which is almost never where anybody predicted.

The durable record here is a person, and the party is the thing that dissolves

Travel is unusual in this. The family of five who went to Croatia is a family of three the year the eldest two go with friends instead. The walking club sends eleven people this year and nine of them are different next year. The couple who booked together for a decade sometimes stop booking together, and one of them still travels.

So the party is a grouping that was true for one departure, and the traveller is the thing that lasts. Model it the other way round, with the booking as the record and the people as text inside it, and you have built an archive of groups that no longer exist instead of a list of people who might travel again.

Everything below follows from that. Facts that belong to a person stay on the person. Facts that belong to one departure stay on the booking. Getting a fact on the wrong one is the commonest cause of a system that looked fine in the first season and was useless in the third.

Two ways of holding a group, and what each one costs you

The first is to make the group an organisation and hold the travellers as people connected to it. This is cheap to set up, it is how most businesses below the Enterprise plan do it, and it makes the group findable as a thing in its own right. The cost is that you have invented an organisation that does not exist in the world. A year of doing it to families leaves you with an organisation list full of entries like Family, August, and no one can tell which August.

The second is to leave the group implicit: the booking is the opportunity, and each traveller is a relationship connected to it with a role. Nothing is invented. The cost is that the group has no name of its own, so a question phrased as who went on the walking trip is answered through the booking rather than through the group.

The rule that survives contact with a real business is this. If the group will still exist next year when none of this year's travellers do, it is genuinely an organisation and should be one: a school, a society, a walking club, a company, a church, a sports team. If the group only existed because those particular people travelled together once, it is not an organisation and you should resist the temptation, however tidy it looks on the day.

Which connections need dates on them, and which are permanent

A traveller connected to a booking needs no period. They went, and the departure date already says when.

A person connected to an organisation almost always does. The club secretary who arranges the trip holds that role for a couple of years and then hands it on. The office manager who books the sales team's travel changes jobs. The teacher who runs the annual trip retires. Without a period, next year's secretary overwrites this year's and the question of who arranged the trip that went wrong becomes unanswerable at exactly the moment somebody is asking it in writing.

The connection between a traveller and the consultant who sold to them is worth dating too, because in this trade people ask for the person by name and that person may have left. Knowing who held the relationship and when is the difference between a warm call and an embarrassing one.

What hangs off the booking and what hangs off the person

On the booking: the stage and its history, the tasks with their due dates, the files, the conversation, the source, the reason it did or did not happen. All of that is about one departure and means nothing without it.

On the person: passport expiry, dietary requirement, accessibility need, insurance held, loyalty number, and the fact that they will not fly with a particular airline after what happened. Those follow the traveller into every future trip, and putting them on a booking means retyping them every time and getting them wrong at least once.

The test for a fact you are unsure about is simple. Ask whether it would still be true if this booking had never been made. If yes, it belongs to the person.

Three custom fields worth having and the ones that only look useful

Passport expiry earns its place because it is a date that generates work: a task raised before it matters rather than a spreadsheet checked when someone remembers. Accessibility need earns its place because it changes what you book, not merely what you say. Insurance held earns its place because it changes the conversation you have when something goes wrong, and because the answer is frequently no.

The fields that look useful and are not tend to be preferences no one acts on: preferred seat, preferred board basis, a free text field called interests that fills up with sentences and can never be reported on. The test for a field is whether somebody would do something differently because of what it says. If the honest answer is that it would be nice to know, it is a note, not a field.

The field almost everybody adds and a good number later regret

Passport number. It feels obvious, because the number is on the form in front of you and typing it now saves asking later. Consider what it actually is: a piece of information valuable to somebody other than you, held in a system used by everyone who sells, for a purpose that arises once.

The expiry date is what generates the chase, and the expiry date is not the number. The number is needed at ticketing, which happens in the reservation system that issues the ticket. Holding it here as well means you have taken on the responsibility twice and gained nothing you could not ask for on the day. If you do hold it, hold it under the same grant as the medical notes rather than in the open, and be able to say why you have it.

None of it was collected to be nosy

A travel record accumulates things a shop would never know. That somebody uses a wheelchair, or can manage stairs but not many. That they cannot eat pork, which implies something about them they did not volunteer. That two people are sharing a room and two others are not. That this is a honeymoon, or the first trip after a bereavement, or a trip someone is taking because a diagnosis means it is now or not at all.

Every one of those was collected because it changes the booking. That is the honest justification and it is a good one. It is also why the record needs handling with more care than a list of people who bought a kitchen.

Which is why the sensitivity grant is separate from the role

A consultant selling next summer does not need to read the medical note attached to last summer. The person preparing the manifest for the ground handler does. Holding the grant separately from the role is what makes those two statements compatible without either giving everybody everything or making the operations team ask permission every time.

Decide it before you invite the second person, not after. The version of this decision made in a hurry, once eleven people already have accounts, is the version that gets made by giving everyone the grant.

The party members never agreed to anything, because they never spoke to you

This is the part of travel data protection that goes wrong most often and it is specific to the trade. The booker gave you ten names, ten dates of birth and in some cases ten dietary requirements. Those ten people did not give you anything. They may not know you hold it.

Holding them properly, as relationships rather than as a paragraph in a notes field, does not change what you were given. It changes what you can do accurately with it, including honouring a request from one of them without unpicking a document. What it must not become is a shortcut to a mailing list. Agreeing to receive travel documents is not agreeing to a newsletter, and a rooming list is a list of names someone else handed over.

None of that is our rule. The Information Commissioner's Office publishes guidance on direct marketing, and the electronic marketing rules it enforces sit in the Privacy and Electronic Communications Regulations. Both are worth twenty minutes before anybody sends a newsletter to a rooming list.

The request you will eventually receive, and where it hurts

Sooner or later a trip goes badly and somebody asks for everything you hold about them. Subject access tooling, the audit trail and a complete export are on every plan, including the free one, permanently, so the mechanics are not the problem.

The problem is the content. It is the note typed at half past five in August by somebody who had spent the afternoon being shouted at, describing a traveller in terms they would not use in front of them. That note is part of what you hold. The only defence is a habit instead of a feature: write the note you would be content to read aloud, and put the frustration somewhere that is not the record. Staff who understand this from the first week never have to be retrained out of it.

How long to keep a passport expiry after someone has come home

The product does not decide this and does not pretend to. It holds what you put in it until someone removes it, records who changed what and when, and gives you a complete export so that what you hold is a question you can actually answer rather than an estimate.

The decision is a policy one, it depends on how often your travellers return and on obligations that are not the same in every market, and it should be written down somewhere a new member of staff will find it. A system that quietly enforced a retention rule someone chose in the first fortnight would be worse, because nobody would remember it had been chosen.

The regulations are on the business, not on the software

Package arrangements, financial protection and insolvency cover are duties that sit with the organisation selling the trip. They differ between the European Union and the United States, they change, and a system with any of them hard coded is wrong the following year.

So Consonas records what you did and when, holds the documents against the booking they belong to, and gives you an audit trail no one can edit. It does not calculate a licence position, does not submit anything and does not model a protection scheme. When an auditor or a solicitor asks what you told a traveller in March, the record answers that question. It does not answer the question of whether what you told them was compliant, and any product claiming otherwise is selling you a feeling.

The high volume online agent whose bookings arrive already decided

If someone chooses, pays and travels without a conversation, then the long enquiry that this page spends most of its length on does not exist in your business. What you have instead is a funnel problem, a conversion rate and a basket, and the tools for those are your booking engine's own reporting and an analytics product. Buying a relationship system to hold transactions that had no relationship in them is paying for the wrong half.

The exception is the online agent with a small high value line where people do ring. That line is a different business wearing the same brand, and it is the one this might suit.

The coach or day trip operator whose real constraint is seats

Fifty three seats, a departure, and a list of who is on it. The problem is inventory: what is left, who is where, who has paid, and never selling the same seat twice. Consonas holds no inventory of any kind. It will not stop you overselling a coach, it does not know a departure has a capacity, and no amount of careful modelling will make it know.

A ticketing or reservation product for group travel is the correct purchase and it is not an expensive category. Come back to this when the question changes from who is on the coach to why the group that came for six years stopped.

The business whose actual pain is commission and supplier reconciliation

Money owed by suppliers, commission due to agents, deposits held, and the quarterly argument about which of those was already paid. This is real, it is expensive when it goes wrong, and it is an accounting problem. Where the invoicing module is bought Consonas will raise an invoice, number it at the moment it is sent and record what was paid against it. What it will not do is any of the rest: no ledger, no supplier statement, no commission calculation and no reconciliation.

If you would describe your worst week as chasing what you are owed instead of chasing what you might sell, buy the back office system first. The relationship side will still be here and will still be worth doing afterwards.

The ground operator with five customers, all of them tour operators

A destination management company selling to a handful of operators has a pipeline you can hold in your head, and everyone in it is already under contract. The difficulty is operational: the ops sheet, the guide roster, the vehicle, the change at eleven at night. None of that is here, and a pipeline of six opportunities does not justify software.

The part that might justify it is the individual travellers and their requirements, if you are the one holding those. If the operator holds them and sends you a spreadsheet, you are not the business this page is describing.

The specialist working alone with a small number of trips a year

A spreadsheet may genuinely be enough, and pages that will not say so are selling rather than advising. The honest test is not the number of bookings. It is whether you have ever failed to answer the question of what you said to someone in March, or been surprised by a departure, or discovered that a traveller you thought was new had travelled with you before.

If none of those has happened, your memory is doing the job and it is free. When the second person joins, the memory stops being shared and every one of those starts happening at once. That is the moment, and it usually arrives before anyone plans for it.

What the five have in common

In each of them the bottleneck is inventory, money or fulfilment. This product's subject is the enquiry, the party and the relationship that outlives both. When those are not what is costing you money, the honest recommendation is the other product, and we would rather make it now than in month two of a subscription.