01
It begins on the operator's own site
A traveller reads about the journey where the operator already tells that story. The booking engine picks up from there, in the operator's colours and type, so nothing about the handover feels like a handover.
Epoch North · A booking layer for PEAK 15
PEAK 15 bookings,
from anywhere.
A customer-facing booking experience that sits between a multi-day tour operator’s website and the PEAK 15 platform. The operator keeps their brand and their system of record; the traveller gets a checkout worth the price of the trip.
A demonstration build. Nothing here contacts a live PEAK 15 instance or a payment processor.
Specimen departureReserve
DEP-2027-PATAGONIA-04124 places remaining
Patagonia, end to end
Torres del Paine to the Perito Moreno ice field, on foot and under canvas, with two rest days in El Chaltén.
- Departs
- 12 April 2027
- Duration
- 14 days
- Group
- Max 12 travellers
- Grade
- Moderate to strenuous
From, per person
$11,400Simulated — This value comes from demonstration fixtures, not from a live system.
Fixture data, shaped like a PEAK 15 departure record.
How it fits together
02
The reservation is made here
Dates, travellers, room pairing, insurance, deposit. A four-step checkout that holds the traveller's hand through a five-figure decision, and never asks the same question twice.
03
PEAK 15 remains the system of record
The booking, the manifest and the money belong in the ERP the operator already runs their business on. This layer is the shopfront in front of it — everything it captures is shaped to go straight in.
Walk the demonstration
Two doors in.
One for the traveller, one for the operator’s team. They are the same application, wearing the same design.
Traveller
A departure, and the checkout behind it
The landing page for one departure, then a four-step reservation: dates and travellers, details, extras, deposit.
DEP-2027-PATAGONIA-0412Open
Operator
The console behind the counter
Two personas — reservations staff working the day's bookings, and an owner watching the season fill.
Two personas, one consoleOpen
Being straight about it
What is real here, and what is standing in.
The flow is real application code. The data behind it is not yet wired to a live system, and every value that comes from a fixture carries an ochre mark — inline, or around the region it belongs to. That mark means one thing and is never used for anything else.
- Simulated — This value comes from demonstration fixtures, not from a live system.
Departures and availability
Fixture data shaped like a PEAK 15 departure record.
- Simulated — This value comes from demonstration fixtures, not from a live system.
Pricing and deposits
Calculated by the real pricing rules over fixture inputs.
- Simulated — This value comes from demonstration fixtures, not from a live system.
Payments
Card capture is simulated end to end. No processor is contacted.
- Simulated — This value comes from demonstration fixtures, not from a live system.
Bookings written back to the ERP
Held locally. Nothing is sent to a PEAK 15 system.
- Real
The booking flow itself
Real application code — validation, state and rules all run.