From whatsapp chaos to a Ticketing system
'/%3e%3cpath%20d='M25%205L25%2049.5028'%20stroke='url(%23paint1_linear_796_10008)'%20stroke-width='10'%20stroke-linecap='round'/%3e%3ccircle%20cx='57'%20cy='23.5'%20r='4.5'%20fill='url(%23paint2_linear_796_10008)'/%3e%3ccircle%20cx='57'%20cy='42.5'%20r='4.5'%20fill='url(%23paint3_linear_796_10008)'/%3e%3cdefs%3e%3clinearGradient%20id='paint0_linear_796_10008'%20x1='51'%20y1='42'%20x2='18.5'%20y2='42'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%23EE9E1D'/%3e%3cstop%20offset='1'%20stop-color='%23FFC205'/%3e%3c/linearGradient%3e%3clinearGradient%20id='paint1_linear_796_10008'%20x1='29.75'%20y1='32.5014'%20x2='19.75'%20y2='32.5014'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%23EE9E1D'/%3e%3cstop%20offset='1'%20stop-color='%23FEC107'/%3e%3c/linearGradient%3e%3clinearGradient%20id='paint2_linear_796_10008'%20x1='61.5'%20y1='23.5'%20x2='52.5'%20y2='23.5'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%23EE9E1C'/%3e%3cstop%20offset='1'%20stop-color='%23FFCF39'/%3e%3c/linearGradient%3e%3clinearGradient%20id='paint3_linear_796_10008'%20x1='61.5'%20y1='42.5'%20x2='52.5'%20y2='42.5'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%23EE9E1C'/%3e%3cstop%20offset='1'%20stop-color='%23FFCF39'/%3e%3c/linearGradient%3e%3c/defs%3e%3c/svg%3e)
B:Live, EV Mobility Platform·2 MONTHS
I owned end-to-end UX for the admin dashboard (Ticket Master, Ticket Management, User Management, Settings) and the rider-facing Help & Support experience in the EZY app, plus I designed a new design system for the platform from the ground up. With a team this small, I wasn’t just producing screens; I was in every scoping conversation, contributing to product logic, and negotiating trade-offs directly with engineering.
- Avni Garg (Me)Product Designer
- PrasenjitAVP of Product
- Sneha JhaAssociate Product Manager
- GovindSenior Developer
- DivyanshuSenior Frontend Developer
1. Who, Why & What
B:Live manages EV fleets for delivery riders across cities. When something went wrong, a payment failure, a vehicle breakdown, a document issue, this is how it got “handled.”
Riders called or WhatsApp'd whoever they personally knew at B:Live.
Issues were noted in spreadsheets, forwarded manually, or simply forgotten.
Zero digital record, no history, no status.
Most issues died for one reason: no ticket was ever assigned to anyone.
I ran research on two tracks over the first three weeks.
User interviews across every role that touches a support issue, riders, fleet operators, hub managers, deployment managers, and recovery managers. Historical complaint analysis, going through past issues raised via calls and WhatsApp to understand real categories, frequency, and where they died.
Then I made research a habit, not a phase: recurring one-hour weekly sessions with all POCs, for three consecutive weeks, so every decision could be validated against real workflows before it hardened into spec.
Admin
Oversees the whole support operation.
Needs to change routing rules (categories, departments, reasons) themselves, and reassign stuck tickets with the change always logged.
Rider
Raises issues about payments, vehicles, documents. Low patience, on the road.
Needs a simple way to raise an issue and see it's being handled, without calling someone they know personally.
DM Manager
Personally allocated to specific riders, who call them for everything.
Needs their own riders' tickets to reach them directly, with enough context to respond like someone who already knows them.
Recovery Manager
Oversees the whole support operation.
Needs immediate visibility into dues-linked tickets (immobilization, payment, blocked closures) with an unambiguous payment-status reason on close.
Research pointed to one core insight: the product isn't a ticket list it's an ownership machine. Every ticket needed exactly one accountable owner, automatically.
Ticket Master
Admins can configure categories, link them to departments, and define resolution reasons, so tickets are automatically sent to the right team.
Ticket Management
The operational workspace with a strict lifecycle and full audit logs.
Automated assignment engine
Category → Department → Team member, with city-based segregation and a DM exception.
Rider-facing Help & Support
In the EZY app, with FAQ deflection before ticket creation.
User Management
Because assignment logic needs to know who works where, in which city, in which role.
2. Product Scoping
User story
3. Design Evolution
Auto-assignment vs. manual triage.
Early scoping leaned toward manual assignment by an admin. But a Deployment Manager told me riders call him, and only him, for everything; manual triage would just digitize the old bottleneck.
I made the case that assignment had to be automatic and rule-based: category → department → round-robin, with a DM exception so riders with a trusted contact keep them.
This is my favourite decision in the project; the system optimizes for load balance by default, but yields to relationship continuity when it exists.
Live chat inside tickets.
I proposed a live chat between the ticket raiser and assignee; otherwise clarifying conversations would leak right back to WhatsApp, recreating the exact problem we were solving.
Engineering couldn’t commit to real-time chat within the 2-month window, so v1 shipped with a comments section + full activity log instead, keeping chat on the roadmap.
Kanban vs. table view
I explored a kanban board; visually, four lifecycle stages map beautifully to columns. But testing with actual users in our weekly sessions was clear: these are operations people who live in spreadsheets. They wanted dense, scannable rows, and didn’t want to spend a minute longer in this tool than necessary. Engineering agreed, for effort reasons.
Lesson: a view that matches the user’s mental model beats a view that matches the designer’s.
Shipped: a table view with layered filters, date range, designation, category, department, and dependent assignee filtering.
Ticket criticality / priority
An immobilized vehicle and a document query aren’t the same emergency; I proposed a criticality level so urgent tickets wouldn’t just sit in round-robin order. Both PM and engineering pushed back: with the assignment engine, city rules, and the DM exception already in scope, priority logic (and the SLA behavior it implies) was too much for the timeline.
We agreed to land it in the next version, alongside AI integration, auto-classifying tickets, inferring criticality from descriptions, and eventually suggesting resolutions from historical data. I lost the v1 battle, but the proposal shaped the roadmap.
Design system, built out from Align UI
The dashboard had no usable design system, so alongside this project I built one for the entire platform, not just this module. I started from Align UI, a purchased component library, as the foundation, but a library alone is just raw components. I designed and assembled the actual system B:Live needed: tokens adapted to B:Live’s brand (color, type, spacing, elevation), components customized and extended into tables, filters, modals, dependent dropdowns, status tags, uploads, and empty states, and reusable patterns, table + filter bar, detail view + activity log, confirmation/guardrail states, built from those components.
4. Outcome 🏆
ResolvedSupport went from “WhatsApp someone you know and hope” to a system where every issue has a record, an owner, a status the rider can see, and a documented resolution. Service quality improved across the board, and for the first time, B:Live has the data to keep improving it.
What’s next: v2 is scoped to bring ticket criticality/priority levels and AI integration, auto-classifying tickets, inferring urgency, and suggesting resolutions from the historical data this platform is now, for the first time, actually capturing.