Redesigning the ride: an agent that gives Meera her attention back
Booking a cab has become a chore of six decisions before the ride even starts. This case study reframes the brief from "simplify the flow" to a harder, more honest question — who should get to make each decision, and what happens when they get it wrong.
It looks like an interface problem. It isn't.
On the surface, booking a cab is a friction problem — too many taps, too many screens between deciding to travel and getting in the car. Leadership's question was simple: what if an agent did all of it instead?
But every decision removed from the rider doesn't disappear. It has to be made by something else — the agent, a fixed rule, or a support person. That reframes the whole brief. This isn't "design a simpler booking flow." It's "design who gets to make each decision."
Four questions carried the most weight through the whole project:
- 01
How much can an AI agent be trusted to decide on someone's behalf — and how does that trust grow over time?
- 02
What happens to the rider, the driver, or the business when the agent's decision is wrong?
- 03
Is it fair to always pick the most expensive option or the highest-rated driver just because it's the easiest default?
- 04
Why do drivers call in the first place — and does removing the rider's decisions actually fix that, or just move the problem somewhere else?
What I learned from my own bookings
Real ride-hailing is fraught with supply problems and hardware bottlenecks that a wireframe never surfaces. I booked three real rides across two days and logged exactly what went wrong.
Booking itself was fast. The driver called on arrival — I couldn't pick up in a connectivity dead zone in the lift.
Zero supply during peak office hours. I opened three apps at once, held two live bookings out of anxiety, then cancelled one with a fabricated reason.
Pin was correct. The driver still couldn't find the specific gate in a gated society — even after I called to explain directions myself.
- Pickup pin ≠ reachable pickup
- Available ≠ bookable
- Driver calls are a symptom, not the problem
- When supply fails, cognitive load shifts to the rider
She doesn't want a faster ride. She wants to stop thinking about the booking entirely.
Meera Krishnan
- Daily reality
- Back-to-back meetings across the city — Indiranagar, Koramangala, Whitefield, ORR — often all in one day.
- What matters
- Time and attention are the scarce resources, not money. She's frequently on calls when a ride needs booking.
- Core frustration
- Booking a cab shouldn't require six decisions. She wants to stop thinking about the ride at all.
- Trust baseline
- Zero trust in automation on day one. Every bit of agent autonomy has to be earned, ride by ride.
The reframe that shaped everything downstream: the problem isn't too many steps, it's too many decisions. Removing one doesn't delete it — it hands it to the agent, a fixed rule, or a support person, and each of those has a different failure mode.
Every design decision in this project had to survive four tensions in the room:
- Trust
Trust vs. convenience — how much can an agent decide on someone's behalf, and how does that trust grow?
- Cost
Failure cost — what happens to the rider, driver, or business when the agent's decision is wrong?
- Fair
Fairness — is it fair to always pick the most expensive option just because it's the easiest default?
- Friction
Driver friction — do drivers call because riders chose wrong, or because the system gave them bad information?
Every decision is tested against three people, not one
Five rider stories, one driver story, one business story — all had to pass before a decision earned its place in the inventory.
Meera — the rider
"Show me its choice before booking, so a wrong call costs me seconds, not a missed meeting."
"Just book it, so I get my attention back."
"Let the ride adapt when my schedule changes, without starting from scratch."
"One glance, not a choice, so I don't leave the conversation I'm in."
"Need almost nothing from me, so a bad night doesn't get worse."
The driver
"Give me gate and pickup info before I arrive, so I don't have to call and ask — less friction for both of us."
The business
"Match the default vehicle to the trip, not always the top tier, so the bill stays fair and rides stay spread across drivers."
Every choice the current app asks of Meera
This was the heart of the project. For each decision between "deciding to travel" and "sitting in the car": what we do with it, what the default is, what it's based on, and what happens when it's wrong.
| # | Decision | Action | Default | Based on | When it's wrong |
|---|---|---|---|---|---|
| 01 | Where am I going? | Default | Calendar + chat context → next meeting location | Calendar API + location history | Correct destination shown, one-tap confirm |
| 02 | Exact pickup point | Default | GPS + learned gate/entrance preferences per venue | GPS + venue memory | Agent proposes pickup; rider adjusts pin if wrong |
| 03 | Vehicle category | Remove | Rider's historical tier for this trip type; upgrades only on an explicit signal (flight buffer, night safety) — never by default to "nicer" | Trip history + an explicit upgrade signal, not distance or passenger count | Category shown before confirm; upgrade always shows its reason |
| 04 | Now or later? | Remove | Now, unless calendar shows a meeting in progress → waits for the gap | Calendar state | Books immediately; if running, asks "Book when meeting ends?" |
| 05 | Payment method | Remove | Saved default — corporate card in work hours, personal otherwise | Time of day + calendar event type | Auto-charged to default; monthly statement shows the split |
| 06 | Apply coupon/offer | Remove | Best available offer auto-applied | Available-offers API | Always applies the best discount; no action needed |
| 07 | Accept surge pricing | Default | Books automatically under 1.5×; asks confirmation above it | Surge multiplier threshold | Quick notification: "Surge 1.8× — ₹480 vs usual ₹310. Book anyway?" |
| 08 | Confirm the booking | Keep | — human in the loop, always | Trust & safety requirement | Rider always confirms — single tap or voice |
| 09 | No vehicle in preferred tier | Remove | Offers a transparent tier-up with reason and wait shown; never books silently, never requires checking other apps | Real-time supply + her calendar buffer | Keeps searching preferred tier and notifies when available |
| 10 | Driver call — pickup ambiguity | Remove | Best-known gate info sent from venue memory; a one-tap "share live location" fallback replaces further calls | Venue database + past rides + live-location fallback | A call may still occur on genuinely new venues — the goal is faster resolution, not zero calls |
| 11 | Driver arrival / handoff signal | Default | Silent in-app + notification signal, not just a phone call, so a connectivity gap doesn't strand the handoff | Arrival trigger + fallback-channel logic | If unacknowledged, agent tries a call as a second channel, not the first |
| 12 | Walk to a different spot | Remove | Agent negotiates pickup via chat before confirming | Pickup feasibility check + live-location fallback | If it still fails, resolution is one tap — not a walk-and-call cycle |
| 13 | Driver can't reach pickup | Remove | Driver flags it in-app; agent reassigns without treating it as a driver cancellation or penalizing them | Reassignment logic + no-penalty rule | Rider sees "Pickup adjusted, new ETA 3 min" — never asked to solve it herself |
| 14 | Share ride status | Default | Auto-shares with emergency contacts on late-night rides | Time of day + safety rules | Rider can toggle off; on by default after 10pm |
| 15 | Pay toll in cash | Remove | Toll amount added to the digital fare automatically | Route toll data | No cash needed — shows as a line item on the receipt |
| 16 | Rate and tip | Keep | Quick one-tap rating after exit; tip optional | After-ride exit | Simplified to thumbs up/down + optional tip, five seconds max |
Trust isn't one dial. It's two.
A single "rides completed" counter looks tidy, but it doesn't survive the obvious follow-up: what if ride 11 happens to be the one where she's catching a flight? Trust needed two independent axes instead of one.
Route familiarity
Has the agent booked this exact route or time pattern correctly before? This governs whether it can book without asking at all.
Situational stakes
How much is at risk if this specific booking goes wrong? This governs whether even a trusted route still gets a check-in.
- Flight departures
- Unfamiliar destinations
- Low battery or late-night conditions
How the ramp feels, ride by ride
Route familiarity sets the baseline. Three phases describe how much Meera hands over as the agent earns it, and she can see and change all of it in settings.
Collaborative
The agent suggests; Meera confirms everything. Full visibility into why each choice was made builds a baseline of trust.
Routine guard
The agent defaults the low-risk choices and handles route corrections and quiet-ride briefs. Meera confirms booking and surge only.
Autonomous agent
Routine commutes are handled silently. Meera confirms the overall booking context, and can tweak or cancel at any time.
From intent to a completed ride
The agent handles routine decisions on its own, checks in when it matters, and gets better with every ride. Guiding principle: give Meera her attention back, not every decision.
Meera's intent
She says where and when, however's easiest — voice, calendar, or a saved place. She can always change or stop.
Context & confidence
Weighs calendar, location, and past outcomes against her price, safety, and consent guardrails.
Acts, informs, or asks
- Act routine, low-risk, silent
- Inform done, shown, undoable
- Ask unclear or high-stakes
Learns for next time
Every ride refines gates, defaults, and trust — never beyond what she's allowed it to do.
Walking Meera's day
Six use cases, designed against her real week, from a 7:55 AM call to a 9%-battery midnight arrival. Each one uses the same logic: act when it's routine, inform when it's done, ask when it's unclear or high-stakes.
The under-30-second path
Calendar shows a 9:30 at Prestige Tech Park, and GPS confirms she's home in Indiranagar. The agent has booked this route before, so it proposes and she confirms in one tap, then goes straight back to her call.
- 0sAgent detects calendar shows the 9:30 meeting and GPS confirms she's home. No rider input needed.
- 2sNotification arrives Sedan arriving in 4 min at Gate 2. ₹340, corporate card, one-tap confirm.
- 5sShe taps confirm a single tap on the call, back to the conversation in under 5 seconds.
- 5–30sAgent handles the rest pickup pin corrected to Gate 2, gate pass requested from security, driver told she's on a call and will get a silent arrival signal instead of a phone call.
Free time detected: suggest, never decide
The meeting wraps 20 minutes ahead of schedule. The agent works out that Meera has about 60 usable minutes before her 1:00 PM in Koramangala and surfaces an option. It never books discretionary time on its own.
- 5sFree time detected next meeting is 25 minutes away, so about 60 usable minutes.
- 3sNearby spot suggested Third Wave Coffee, 8 minutes away, with high-speed WiFi.
- 3sOpen for other options she can enter a different drop location instead.
- 5sMeera decides go to Third Wave, keep the original plan (book at 12:15), or enter a custom destination.
When stakes are high, lead with the answer
A tight flight buffer is exactly the situational-stakes trigger from the trust model. The agent doesn't hand her a menu. It shows one recommended ride with the reason, so a single tap keeps her in the conversation she's in.
- 0sCalendar + flight sync flight departure detected, latest leave time and buffer calculated automatically.
- 2sSmart upgrade Prime Sedan selected because of the flight buffer, with the reasoning shown. The cheaper Sedan stays one tap away.
- 5sRide confirmed driver briefed with gate info, ETA locked, pickup pin corrected to the terminal entrance, toll (₹125) included in the fare.
Late-night arrival: extra safety by default
Meera lands at KIA after a delayed flight, with a dying phone and nothing she wants to decide. The agent has tracked the flight and the pre-booked ride is already waiting at a well-lit pickup zone.
- 0sFlight tracked the agent monitors flight status and delay, and the pre-booked ride is ready the moment she lands.
- 0sDriver already waiting pre-assigned driver at the arrival bay, with no searching in an unfamiliar terminal at midnight.
- 5sSafety defaults active ride details pre-shared with her emergency contact, route locked, toll pre-paid.
Mysuru weekend trip: a different decision set
A multi-stop trip with colleagues switches the agent into an intercity decision set automatically: route, rest stops and an experienced driver, with the price locked upfront.
- 2sIntercity route detected the agent recognises Mysuru and changes the decision set.
- 3sRoute optimized best departure time, highway rest stops and an intercity-experienced driver pre-selected.
- 5sBooking confirmed price locked at ₹4,200, comfort preferences applied, toll and fuel estimates shown upfront, return trip pre-planned.
Preferred tier unavailable: honesty over convenience
This case comes straight from my own Booking 2. A supply failure pushed me into multi-booking out of anxiety, and I ended up cancelling on a driver with a made-up reason. The fix isn't a silent upgrade. It's showing the real trade-off.
- 0sSupply checked the agent searches the preferred tier and finds zero availability nearby.
- 3sTransparent alternatives wait vs. cost shown honestly (Sedan in 6 min, ₹460, or Prime Sedan in 3 min, ₹480). No silent upgrades or downgrades.
- 5sMeera chooses one active request only. If she keeps waiting, the agent searches in the background and suggests the next best option after 5 minutes.
The driver is a person with their own incentives
Removing rider decisions means nothing if it just moves the friction onto the driver. Fixing the call problem meant redesigning what the driver sees too.
Today's friction
- Receives an imprecise GPS pin
- Has to call the rider to find the gate
- Waits without knowing if the rider is even coming
- Prefers the rider cancels, to avoid the penalty themself
- Has no context on rider preferences
With agent resiliency
- Receives a gate photo and exact entrance
- Pickup info is pre-communicated via agent chat
- Arrival signal sent automatically, rider acknowledgement visible
- Agent reassigns without penalty if pickup can't be reached
- Rider preferences shared quietly — quiet ride, no calls
Key principle: reducing driver calls means solving the problems that cause them — not just blocking the channel.
What happens when defaults are wrong
Two were required by the brief; the third I chose myself, because my own fieldwork made it the one I trusted least.
Wrong gate default
THE FAILUREAgent defaults to the main gate at a new campus; the driver goes the wrong way.
RECOVERYDriver flags it in-app, the agent recalculates ("Main Gate is staff-only, navigating to Gate 3") and offers a one-tap "Remember Gate 3" memory update.
IMPACTA 2-minute delay, fixed permanently. Directly evidenced by my own Booking 3.
Silent driver cancellation
THE FAILUREDriver cancels mid-meeting; Meera can't check her phone.
RECOVERYAuto-reassignment within 60 seconds, with a silent notification if it works ("Driver reassigned, Sedan, ETA 5 min. Still on track for your 6:05 flight"). If unresolved, the agent escalates with a transparent tier-up offer (Prime Sedan, +₹180) rather than going silent.
IMPACTDirectly evidenced by my own Booking 2 — the exact anxiety that drove multi-app booking.
Network drop at 9%
THE FAILUREKIA airport, patchy network, phone nearly dead.
RECOVERYRide data is cached locally and the ride is secured the moment the flight lands ("Go to Airport Bay 3. Code: 4921"). The agent acts on flight data, not on Meera's phone.
IMPACTMy own chosen case — evidenced by Booking 1's connectivity dead zone.
Validating trust and performance
Every threshold below traces back to something my own bookings actually surfaced — not an assumption.
Success metrics
What to maximizeTotal friction from deciding to go, to a confirmed ride.
Calls may still occur on genuinely new venues — the goal is shorter resolution, not a false promise.
Active screen time, down from constant screen-checking and decision-making.
How often defaults are accepted without override — the core trust metric.
Cases the agent genuinely couldn't resolve — payment, safety, repeated cancellation.
Danger signals
What to limitDerived from Booking 3 — static gate info wasn't enough.
Riders feel forced to verify every step, so trust is eroding instead of building.
Derived from Booking 2's supply failure and multi-app anxiety.
Trust model failing during the critical early phase.
Trusted riders (ride 11+) stepping in on bookings the agent was cleared to handle, so the autonomy tier is miscalibrated.
Missed flights, safety issues, payment errors — the tightest bound on this board.
Test first
Priority experimentsNotification vs. explicit re-confirm — does silent rebooking cause concern if found late? Directly tests the anxiety from Booking 2.
Deploy at Prestige Tech Park, Bagmane and Embassy (5 high-traffic Bengaluru IT parks); measure driver-call drop and pickup time delta.
A/B automated calendar prediction against a manual query screen; track suggestion acceptance and wrong-destination rate.
What I'd defend under questioning
The decision I'm least certain about is still the vehicle-tier default — optimizing for what Meera would tolerate costs money and, at scale, concentrates rides on top-rated drivers. Defaulting to her own history and requiring an explicit signal for any upgrade is the most defensible answer I found, but it's a bet, not a certainty, and I'd want real ride data before I trusted it fully.
The throughline across every section here is the same: removing a decision only moves it somewhere else, and the job of this design is to make sure it lands somewhere it can be made well — by a confident agent, a fair default, or an honest ask back to Meera.