Opening
Mojatrip
Simplifying how hotels and tour operators work together.
In prototype testing, bookings were confirmed in under two minutes, down from a day or two.
At a glance
The result
Under 2 minutes to confirm a booking in prototype testing, down from a day or two.
What I did
Design and engineering, in a team of 7.
The problem
Hotels and tour operators worked through email chains, spreadsheets and heavy supervision.
01 What shipped
In focus: the designed and built product.
What changed
What changed
<2 min
to confirm a booking in prototype testing, down from a day or two.
Auto
Routine bookings confirm or cancel by each hotel’s own policies
1 place
for bookings, payments, contracts and performance
“The potential this product has in the tourism industry is really impressive”
What I learned: the biggest improvements often come from removing steps, not adding features. The fastest booking flow turned out to be the one where most bookings never needed a person at all.
02 What I did
Design and engineering for one booking space hotels and operators share.
Design and engineering, in a team of 7: 2 designers, 4 developers and 1 PM.
Client
Hotels and tour operators
My role
Design and engineering
Timeline
10 months · 2026
Team
Team of 7: 2 designers, 4 developers, 1 PM
Question
Why let policies confirm bookings?
Most supervision went into routine bookings. Each hotel’s own rules handle those now, so staff only see real exceptions.
Question
Why put contracts inside the system?
Agreed rates and terms lived in people’s memories. Now they’re a shared record that automatic bookings can follow.
03 The story behind it
Tourism runs on partnerships between hotels and tour operators. The tools behind them hadn’t kept up.
Bookings were negotiated through long back-and-forth conversations, payments were tracked by hand, and a large team of reservation officers supervised every step.
The result was slow and expensive for hotels, frustrating for operators, and fragile wherever a message got missed.
Confirming a booking, the old way
01
Receive a request by call or email
02
Check rates and free rooms by hand
03
Wait for a supervisor to approve it
04
Chase the payment and log it in a spreadsheet
05
Confirm a day or two later, if no message got missed
From watching hotel staff at work
“We’ve seen the prototype and all we can say is... Phenomenal work!”
Bringing it into focus
The real need: one shared place where routine bookings confirm themselves.
What we kept seeing
A single booking took several calls or emails, and a day or two to confirm.
From watching hotel staff at work
What it needed
One shared booking space, where each hotel’s own policies confirm routine bookings automatically.
Chapter 04 — Bringing it into focus
More detail · Research
How we watched the work happen before designing anything
Before designing anything, we watched how the work really happened.
What we found
- Bookings took too many conversations: several calls or emails, and a day or two to confirm.
- Supervision was a bottleneck: officers checked routine bookings that rarely needed a person’s judgement.
- Information was scattered across inboxes, spreadsheets and paper records.
- Relationships ran on memory: rates, terms and past issues lived with individual staff.
- Owners had no easy way to see how their hotel was performing.
Technical notes
Stack and trade-offs, for engineers and recruiters · Figma · Miro · React · Claude
Stack
- FigmaDesign
- MiroResearch and flows
- ReactFrontend
- ClaudeAssisting the build
My part
Design and engineering, in a team of 7: 2 designers, 4 developers and 1 PM.
How it works
Booking policies.
Each hotel sets its own rules (payment holds, deadlines, cancellation tiers), and routine bookings confirm or cancel against them.
Contracts in the system.
Automatic bookings follow agreed rates and terms, and owners can track performance against them.
An invitation
Running a business that still runs on calls and spreadsheets?
Booking calls now · Pick a time that suits you