Travel website checklist before going live: who owns what
The first call after launch is rarely about the website. It is a customer who paid late at night, received a confirmation email, and now wants to know whether the hotel actually has their name. Or a son who booked his mother on the wrong date and wants the money back before the fare rules say he cannot have it. Whoever picks up that phone finds out very quickly which decisions were made before launch and which were left for later. This travel website checklist before going live is written from that chair: what has to be settled, and by whom, before the address goes on your business card.
Why a travel website checklist before going live needs three owners
Most pre-launch lists fail because they are one list. The technical lines get ticked because they are easy to see — the logo is there or it is not — and the commercial ones drift because nobody's name is next to them. Split the list by owner instead. In a small agency the same person may wear two of these hats, and that is fine, as long as they know which hat they are wearing when they tick a line.
- Commercial — the owner or sales lead. Prices, customers, credit, refunds.
- Technical — whoever set the site up. Domain, look, languages, staff access.
- Legal — the owner, with an adviser where the market demands one. The pages a customer agrees to when they pay.
Commercial: the decisions only the owner can make
None of these is a software setting, even though each one ends up as a setting. They are answers to questions a customer will ask in the first week.
- Which services are you actually selling? Flights, hotels, tour packages and attractions are switched on per site, and a site shows only what it sells. If nobody on your team can handle a hotel amendment, do not open hotels in week one just because the menu looks emptier without them.
- Your markup, per service, written down. One number set on launch day tends to become permanent through neglect. Decide the rule for flights and for hotels separately, and decide who is allowed to change it. We wrote separately about markup rules that survive a price-comparing customer.
- Default currency and the list you offer. Each site picks its own. Offer only the currencies you can reconcile; a refund in a currency your bank account does not hold is a small loss every single time.
- Who is the customer? Travellers, businesses, or both. A site can require sign-in before search, and business (agency) customers can register with an optional manual verification step. Decide now whether a sub-agent who signs up on Friday night may book on Saturday morning.
- Credit, if you extend any. Sub-agent credit limits and settlement invoicing are proper records on the platform, not spreadsheets. Set the limit before the first sub-agent asks for one, not while they are on the phone asking.
Technical: what the person who built it signs off
This is the part most checklists are stuffed with, and it is also the part the platform carries most of. A short list, then one warning.
- The site answers on its platform subdomain, and on your own domain if you are attaching one. The DNS step is guided and TLS is issued automatically; the platform address stays attached permanently, so test both. The details are in connecting your own domain to a booking engine.
- Logo, colours, fonts and template chosen. These change from the admin panel without a redeploy, so do not hold the launch for them.
- Every staff member has their own login, with a role that matches their job. Nobody uses the owner's password, and the person answering the phones does not need to see your markups.
- The phone number on the site rings a phone that somebody answers.
The warning is about languages. The storefront ships in 40 of them, right-to-left ones included, and it is tempting to switch everything on. Every language you enable is a promise that a customer writing in it will get an answer. Turn on the languages your team can support on a bad day, and add the rest when you can keep that promise.
Legal: the pages that are not optional
This section is short because the list is short. It is not optional because each of these pages is what you point to when a dispute starts, and one will.
- Terms of sale. Who the seller is — your registered company, under its real name and address — what you sell as an agent and what as principal, and which supplier rules bind the customer.
- Cancellation and refund policy. Fare rules and hotel cancellation terms belong to the supplier. Your policy says what you pass through, what fee you add on top, and roughly how long a refund takes.
- Privacy policy. What you collect — passport details, for a start — where it goes, and how long you keep it. The data-protection law of your market sets the details, so check it rather than guessing.
- Company identity and contact. The legal entity, a licence number where your market issues one, a physical address and a working phone number.
Copying another agency's terms is the tempting shortcut and a bad one. Their terms describe their company, their suppliers and their jurisdiction. Borrow the structure if you like; write the content yourself, or have it written.
Test bookings you must actually make
Clicking through to the payment page proves that the page loads. It does not prove that a ticket gets issued, that the voucher carries the right name, or that a cancellation comes back to you as money. Make real bookings — cheap and refundable ones where you can find them — and then cancel them. Some will cost you a small fee. That fee is the cheapest lesson on this whole list.
| Test | What it proves | What failure looks like on day one |
|---|---|---|
| One-way flight, one adult, paid by card | Payment, ticketing and the e-ticket email work end to end | Card charged, no ticket, customer on the phone |
| Return flight with a child and an infant | Passenger types and dates of birth are captured correctly | An infant booked as a child, and a fare difference nobody priced |
| Refundable hotel, then cancelled inside the free window | The cancellation reaches the supplier and the refund reaches the customer | The supplier still holds the room and charges a no-show |
| A booking in a second language and a second currency | The amount charged matches the amount the customer saw | A customer disputing a charge that looked different on screen |
| A business customer signs up | The verification request reaches someone who acts on it | A sub-agent waiting all weekend for approval |
| A staff member with a limited role logs in | Roles hide what they are meant to hide | Your net prices on a junior's screen, and then in a screenshot |
Book the flight tests in the real names of people on your own team, on a route you actually sell. A booking under a placeholder name is one you cannot use to check a voucher, a ticket or a passport match.
What to have decided before the first refund request
The first refund request usually arrives before the first complaint about the website. When it does, the person answering should not be inventing policy on the call. These are the questions it forces, in the order it forces them.
Who approves it? A name, and an amount above which it goes to someone else. Without that, either every refund waits for the owner, or nobody is sure whether they were allowed to say yes.
What comes back? The supplier's rules decide what the supplier returns. You decide what you return of your own margin and whether you keep a service fee. Decide it once, in writing, so that two members of staff do not give two customers two different answers on the same fare.
How long does it take, and what do you tell the customer? An airline refund can take a long time to travel back through the chain. If you refund the customer before the supplier refunds you, you are lending money. That can be a sensible service. It should be a choice, not an accident.
Where is it recorded? Every booking has its own record in the admin panel. The refund decision, the reason and the person who took it belong next to that record — not in a chat thread on one person's phone.
What it costs you to skip this
Almost nothing on this list costs money to do. Skipping it costs in three ways that tend to arrive together, in the first busy week. There is the direct loss: the no-show charge on a hotel you believed was cancelled, the refund you paid out before the supplier paid you, the currency difference nobody priced. There is the chargeback, when a customer who could not reach you goes to their bank instead — and the bank does not read your terms first. And there is the slow one. A customer whose first booking went badly does not make a second, and tells the next person who asks where they booked.
A site that launches a week later with every line ticked is ahead of one that launched today with half of them.
Running the list against a real site
You cannot make test bookings on a site that does not exist yet, which is the argument for provisioning early and announcing late. The white-label signup wizard sets up a branded site on a platform subdomain from the form itself, with no card required, so every test in the table above can run before a single customer knows the address. If what is still undecided is how fast the rest can move, what a 24-hour launch honestly involves walks through the order of the work.