What the traveller sees, and what the team needs
A booking system is easy to judge on the booking experience alone. The team's side decides whether it works for the travel business.
A date is a departure
A traveller booking a private trip chooses any available start date. For the tour operator, that date is a departure: a start, an end and a group. On the Discovery World Trekking site, a start date chosen in the departure calendar shows the trip's end date at once. The traveller reads "10 November to 23 November" rather than working it out.
Working from departures goes back to the second phase of the build, which set end dates automatically from them. In March 2024 we reopened how dates and departures work.
The price depends on the group
Discovery World Trekking's prices fall per person as the group grows. A single price without the group size would hide that difference.
On this site, group size sets the per-person price, and the trip page shows the table. The traveller sees what a group of two pays before they ask. The request reaches the company with the group size in it.
Full payments, advances and direct payments
Travellers can pay the full trip price or an advance at checkout. A separate payment form takes agreed amounts directly when a payment does not start from a trip page.
Keeping these payment types distinct lets the team identify a part-payment, a full trip payment or a payment made outside trip checkout.
Keep details when dates change
A traveller filling in a booking form changes their mind. They pick another date, or the page reloads. The booking form keeps their details through both. A form that empties itself on a date change asks the traveller to enter the same details again.
Every enquiry says where it came from
Enquiry buttons sit beside trip and article content, not only on a contact page. Each enquiry records the page and the action it came from. When the team replies, they know which trip or article the traveller was reading, and the conversation starts there.
Five checks for your own travel booking system
- Dates: does a chosen date become a departure your team can manage, or a note someone retypes?
- Prices: does the price follow the group, and does the traveller see it before they ask?
- Payments: can the team distinguish full trip payments, advances and direct payments?
- Forms: does the booking form keep what the traveller typed when they change a date?
- Source: does each enquiry carry the page it came from?
The Discovery World Trekking case study shows the trip pages and the design system behind them. We design and build commerce and booking platforms like it.
A booking system can look finished to every traveller and still leave the team retyping each request. The test is what reaches the inbox.
