Booking, payment and refund states35 transaction states, one calm pattern
When a booking failed, people couldn't tell if they'd been charged. I mapped every state and gave each one a plain answer.
- RoleAssistant Manager, Product Design
- Worked withEngineering and support
- TimelineDec 2019 to Aug 2020
- PlatformsAndroidiOSMobile webDesktop
The problem
Purchase history showed a booking as confirmed or missing. Real payments fail, cancel and refund in parts.
My role
Sole designer. I mapped every state with engineering and support, and designed what each one says.
Context
The company, the people, the goal
BookMyShow sells movie and live event tickets across India. Every booking passes through three systems, the payment gateway, BookMyShow and the cinema or event partner, and in 2020 status questions about those bookings were the root cause of 25% of support tickets.
Who it was for
- Moviegoers after a failed payment
Money has left their account, no ticket arrived, and they want to know if it is coming back.
- Moviegoers waiting on a refund
A cancelled or failed booking is refunding, sometimes in part, and they want the amount and the date.
- Support agents
They answer the same status questions all day, from information the app never showed.
What success meant
- Business goal
Remove the root cause of the status tickets, a quarter of all support volume.
- User goal
Know what happened to my money, and when it comes back, without calling anyone.
Research
What we did to learn, and what we learned
- Support ticket analysis
3 months of support tickets sorted by topic. A quarter asked about booking, payment or refund status.
- Support agent interviews
5 agents on the questions they hear most and the answers they give that the app does not.
- Transaction mapping with engineering
Every path through the gateway, BookMyShow and the partner, written into one Cases frame until 35 scenarios were listed.
- Audit of purchase history
Walked the existing list and ticket screens state by state. Only successful bookings appeared.
- Competitive audit
How Uber, Swiggy, Amazon and Paytm show failed orders, refund timelines and reference numbers.
- 01
People read money taken as a booking made
How we knowTicket analysis and the agent interviews: a failed booking after payment read as being cheated.
What it changedPayment and booking became two separate facts, said in that order.
- 02
Three systems can disagree about one booking
How we knowThe Cases frame: double gateway responses, partner timeouts, and bookings confirmed at the cinema but not updated at BookMyShow.
What it changed35 system scenarios were grouped into five categories a person understands: initiated, payment, booking, cancellation and refund.
- 03
Refund worry peaks on day 3, refunds take 7 to 10
How we knowRefund tickets spiked about three days after a failure, while gateways take 7 to 10 days to credit.
What it changedThe refund card states the provider's window and a reference number up front.
- 04
Five stock answers covered most status calls
How we knowAgents said five replies covered about 80% of status questions: processing, the timeline, refund on its way, check your bank, here is your reference.
What it changedEach of those answers moved into the ticket screen, so the app says it first.
Principles
The rules every screen followed
- 1
Money first, then the booking
Every failed or cancelled state opens with what happens to the money, before film, time or seat.
- 2
One pattern, every state
A status label, colour, icon and one sentence. A new state fits the pattern instead of needing a new screen.
- 3
The list answers, the ticket explains
The list shows the status and refund amount. The ticket holds the timeline, breakdown and reference.
Process
- 01
List every state
Booking, payment and refund scenarios, mapped until none were left.
- 02
Split two tracks
Payment status and booking status, said separately.
- 03
Write for worry
The copy leads with what happens next.
- 04
Ship everywhere
One pattern on every platform at once.
Key decisions
Decision 01of 03
Two states became every state
A booking showed as confirmed or missing. Every booking, payment and refund state now has its own plain status.
BeforeOnly two answers
Everything else became a support ticket
AfterEvery state visible in the list
Failed, with the refund amountDecision 02of 03
Payment and booking, said apart
One merged status hid cases like charged but not booked. Each one is now said plainly, first.
Confirmed, in greenFailed, said firstRefund amount up topDecision 03of 03
Written for the worried moment
People open purchase history when something feels wrong. Refunds show a timeline and a reference number.
When the refund landsA reference to quoteThe journey after
End to end, as it shipped
- 1Something goes wrong
A payment fails mid-way, or the money is taken and the partner never confirms the seat.
- 2Open purchase history
The booking is in the list with a status dot, a plain label and the refund amount.
- 3Open the ticket
The header says the booking state; the next line says what happens to the money.
- 4Check the amount
The refund breakdown explains any deductions in a partial refund.
- 5Refund lands
The header goes green, with the date, the provider's window and a reference number.
- 6Only then, support
Support and FAQs sit at the bottom, with the booking ID already on screen.
Edge cases
Designed for the messy moments too
- Booking failed after payment
A red header says the booking failed, the line under it says the refund will be initiated, and the amount sits on top.
- Booking cancelled
The list keeps the booking visible with its status and the refund amount being processed, instead of dropping it.
- Partial refund
An expandable refund breakdown shows the amount paid minus handling fees and the BookASmile donation, so a smaller refund is explained.
- Refund processed
The header turns green. A timeline shows when BookMyShow processed it, the provider's 7 to 10 day window and a reference to quote to the bank.
- System edge cases
Gateway double responses, partner timeouts and unclassified booking statuses were listed in the Cases frame, so each had a defined status and message before build.
- Still unsure
Every ticket ends with Support and FAQs next to the booking ID, as the last step rather than the first.
Outcome
The same calm status pattern was reused for later transaction types.
Each state says what happened to the money first, then what happens next.
- 35booking, payment and refund states mapped
- 25%of support tickets, root cause fixed
- 3 wkto ship on Android, iOS, mobile web and desktop
- ShippedThe same status pattern was reused for later transaction types
Reflection
Looking back
What I learned
- A support queue is a map of design gaps. The tickets told us which states the product had no words for.
- The states had to come from the people who own the systems. Support knew them by the tickets, engineering by the code paths.
- Clear beats reassuring. People calmed down when the screen answered their question, not when it sounded kind.
What I would do next
- Track status tickets by state after launch, to find the messages that still send people to support.
- Tell people about their refund around day 3, when worry peaks, instead of waiting for them to open history.
Pulse, from concept to shipped React in 3 weeks