MakeMyTrip remembers what you booked. It doesn't remember why. This is the gap — and a 4-part system that closes it.
DomainIndian OTA · Hotels
RoleResearch · Strategy · UX
DesignerJoseph Anthraper
80% visit an OTA before booking ●81% cart abandonment rate ●MMT — 55-60% India OTA market ●Only 40% of guests leave reviews ●4 weeks avg research time ●$9.8B gross bookings / year ●0 OTAs capture why ●36.4M monthly visitors ●80% visit an OTA before booking ●81% cart abandonment rate ●MMT — 55-60% India OTA market ●Only 40% of guests leave reviews ●4 weeks avg research time ●$9.8B gross bookings / year ●0 OTAs capture why ●36.4M monthly visitors ●
During trip planning I had 11 browser tabs, a Notes app entry that read "the one near the metro — quiet street, café on corner," and no memory of why I rejected the other seven. On the next trip I did it again. From scratch.
Decision fatigue — the behaviour every OTA ignores
Users build a mental shortlist based on personal criteria — neighbourhood vibe, walkability, noise, nearby amenities. These criteria are repeated across trips and never structurally captured by any platform.
0%
of travelers visit an OTA before booking — even if they book elsewhere
Expedia Group 2023
0%
OTA cart abandonment — users research but don't commit
Condor Ferries 2024
4 wks
Average trip research time — platforms capture none of it
TripAdvisor 2023
55–60%
India OTA market share (MMT)
$9.8B
Gross bookings / year (FY25)
36.4M
Monthly active visitors
100M+
Combined app downloads
Early Validation
Before formal testing, I checked the instinct against real people.
I ran 8 informal conversations with frequent travellers in my network — a directional gut-check, not a formal study. Two behaviours showed up again and again, and both point at the same missing layer.
PATTERN 01
They keep manual notes on why.
Notes app entries, screenshots, WhatsApp-to-self — homemade memory systems to hold onto the reason a place made the shortlist.
PATTERN 02
Or they re-research from scratch.
When they hadn't noted it down, they re-opened listings they'd already evaluated — redoing the same comparison to remember why they'd cared.
What it told me
People already do this work by hand. The behaviour exists — no platform has just given it a home. StaySense isn't teaching a new habit; it's absorbing one that's already there.
Scope note: n=8, convenience sample from my network — directional signal to justify a prototype, not a substitute for the structured study defined in the metrics section below.
Core Insight
The gap isn't storage. It's that the reason never becomes data.
Platform
Saves listings
Captures why
Post-stay validation
Personalisation loop
MakeMyTrip
✓
✗
✗ shallow
✗
Booking.com
✓
✗
~ open review
✗
Airbnb
✓
✗
✓ structured
~ partial
Google Hotels
✓
✗
✗
✗
StaySense ↗
✓
✓ Tagged note
✓ Binary prompt
✓ Full loop
"Wishlists capture that a user was interested. They don't capture why — and nothing downstream consumes it. The gap isn't storage. The gap is that the reason never becomes data."
The Solution
StaySense: a 4-part system that closes the loop.
System Overview
01
CAPTURE
Research Notes
While browsing a listing, users tap "Save Research Note" to open a bottom sheet. They select predefined tags — quiet area, walkable cafés, scenic surroundings — and add an optional note. Zero friction, embedded in the existing booking flow.
02
TAG + CONTEXT
What Caught Your Interest?
Tags like "Quiet area", "Walkable cafés", "Scenic surroundings" let users structure their reasoning without effort. The "Add Street View" button saves neighbourhood context directly into the note.
03
CONFIRM + SAVE
Save Research Note
Once tags are selected, the Save button activates. One tap saves the structured note — tags, free text, and Street View context — to the listing. The user's reasoning is now data the platform can learn from.
04
VISUAL CONTEXT
Street View Snapshot
One tap saves the view by coordinates — not cached imagery — keeping it fully compliant with Google Maps Platform ToS. The snapshot becomes visual evidence of the user's intent, tied to the research note.
Key Design Decisions
Three calls that shaped the outcome.
Decision
Binary prompts over open reviews
Considered
Open-text review (existing model)
Chose
Yes/No prompts tied to user's own notes
Tradeoff
Lower richness, but 12–18% vs ~5% completion. Structured signal beats sparse narrative.
Decision
Tags over free-text notes
Considered
Free-text note field only
Chose
Predefined tags + optional note
Tradeoff
Tags constrain expression but enable aggregation. Free text needs NLP — tags work on day one.
Decision
Street View via coordinates
Considered
User uploads own photos
Chose
Re-fetch by coordinates, never cache imagery
Tradeoff
Maps ToS compliant. Legally scalable, lower storage cost, no licensing risk.
Post-stay Quick Check-in
Binary prompts — not open reviews
Questions are derived directly from what the user noted before booking. Takes under 15 seconds. Targets 3× baseline completion vs. open-text reviews. The value return is personal — your answer improves your next recommendation.
The Hard Question
I diagnosed a motivation problem and initially prescribed an effort fix.
The Contradiction
My problem statement says post-stay reviews barely happen. My solution depends on post-stay validation.
Reducing effort only works if effort was the actual constraint. For open reviews, it's partly motivation — writing a public evaluation for strangers returns nothing to the reviewer.
But binary prompts tied to the user's own notes are different: the question references something they said, and the answer improves their next recommendation. The value return is explicit and personal.
How I'd Test It
Hypothesis
Binary prompts tied to user's own notes achieve 3× completion vs. generic review (baseline: 5–8%)
Method
A/B: generic 3-question review vs. note-derived binary prompt. n ≥ 500 per arm, 30-day window.
Success
≥ 18% completion on binary arm (SMS survey benchmark: 12–18%, FeedbackRobot 2024)
Guardrail
No increase in time-to-book for note-capture users
Success Metrics
What we'd measure — and what we'd protect.
Metric
Type
Baseline
Target
Source / Rationale
Note capture rate (5+ listing sessions)
Adoption
0% (new feature)
≥ 22%
Comparable to Airbnb Wishlist save rate
Post-stay validation completion
Adoption
5–8% open review
≥ 18%
FeedbackRobot 2024; binary format targets upper end
Not a feature. A data asset that changes both sides.
Consumer side
What users are trying to find — and keep forgetting why they wanted it
Reduces cognitive fatigue
Users stop rebuilding criteria every trip. Research time drops on repeat sessions.
Increases booking confidence
68% of customers pay more when they feel certain about their choice. (Virdee 2024)
Drives repeat use
Platform becomes the memory layer. Switching cost rises without lock-in tactics.
Supply side — hotels pay
"73% of guests who shortlisted you for Quiet Area reported it wasn't met."
Validated expectation data is a product for hotels — the side that actually pays. No current review system produces this.
→No star rating produces this level of operational insight
→Hotels prioritise fixes by expectation gap, not gut feel
→Creates a B2B analytics product layered on B2C data
→New revenue stream beyond commission — SaaS hotel dashboard
Personalisation Loop · Live
"Recommended for You"
Once the validation loop has enough signal, StaySense surfaces hotels matching the user's validated criteria — with a transparent reason. Trust through explanation, not black-box ranking.
↑ 15%
Rec. CTR target
68%
Pay more when certain
4 trips
To full personalisation
Next Steps
Three things before shipping. One thing I'd reconsider.
01
Validate the motivation gap
A/B test: note-derived binary prompt vs. generic review. n ≥ 500. 30-day window. If completion stays below 15%, the feature needs a stronger value hook.
02
Interview 8–10 high-research bookers
Users who view 5+ listings in one session. Confirm re-research is universal or segment-specific.
03
Maps licensing check
Google Maps Platform restricts caching Street View imagery. Coordinate re-fetch approach needs formal legal clearance.
What I'd reconsider
Whether tags are the right primitive — or whether inferring intent from browsing behaviour (time-on-listing, scroll depth, return visits) beats asking. Passive capture removes the feature's own friction entirely. Needs a separate prototype cycle to evaluate.
The next competitive layer in OTA is memory, not inventory.
Problem is real
Academic literature and OTA data confirm decision fatigue and re-research as documented behaviours.
Design is testable
Every assumption has a metric, test, and success threshold defined.
Business case holds
Consumer personalisation + B2B hotel analytics = two revenue angles on the same data.
