← All work Contact

WheelsEye · App-first support

Sixty thousand tickets a month, and a phone call for every one.

How I moved India's largest fleet platform from agent-led support to an app-first, increasingly automated one: the flows, the logic under them, and what changed.

Customer 360 console: one vehicle across GPS, FASTag and Diesel Sensor with an AI summary
Operator app Help and Support with Raise Issue, a named KAM, an active chat and tickets
Role
Product UX designer, end-to-end system design
Scope
Operator app support, ops console, decision logic
Surfaces
Android, iOS, Operator Web, internal console
Shipped
Phase 1 · 22 June · Phase 2 · 25 August

The problem

The app could already do it. Operators still called.

Problem statement

Let operators raise, track and resolve their own issues in the app, so that starting there is easier than calling, for an operator on a highway and for the agent behind them.
  • No self-serve start. For most issue types the only way in was to call, and an agent typed the ticket.
  • ~60,000 tickets a month across GPS, GPS Pro, Diesel Sensor and FASTag, arriving through many channels.
  • CC and KAM teams spent their day creating tickets and answering "any update?" instead of resolving.
Ticket journeys already available in the app 65%
Capability existed
Monthly tickets operators created themselves 45%
The rest came in by phone, typed by an agent

Entry points were fragmented, and several high-volume issue types had no route in the app at all.

What I found

The old Help Centre pushed people to call.

I audited the existing screens before designing anything. Calling was the biggest thing on the page, chat sat inside a long issue list, and a raised ticket said little more than "contact support".

Help Centre · before

The old Help Centre: Call Now with the account manager, recent tickets and a long list of issues

A raised ticket · before

The old ticket sheet for a vehicle number change, telling the operator to contact support if not resolved

The core problem

P1Operators couldn't self-initiateMost issue types had no way to start in the app. Raising a ticket meant calling someone who raised it for you, so the operator never owned the issue.

What made it worse

P2High cognitive loadA frictional first step and chat buried in the hierarchy.
P3Inaccurate ticketsNo hand-holding, so issues landed in the wrong category or twice.
P4No resolution visibilityOperators were blind to escalations and to what was pending on their side.
The old console, scrolling through one order: breach and pending flags, a paragraph of raw installer assignments, then a long list of status changes
One order in the old console, scrolling through its full history.

And behind the phone

Agents couldn't pick up where a colleague left off.

Each order opened into raw installer assignments and a scroll of status changes. Nothing said why a ticket was stuck, so every call started from zero and the second agent re-asked what the first had already learnt.

P5Context lost between agents

The redesign · screen space

One Help & Support page, ordered by intent.

Same content, re-weighted. Each bracket is measured on the shipped screens: how much of the page each job gets, before and after.

Before

Old Help Centre: Call Now leads the page and chat sits inside an issue list
Create ticket via call15% · the first thing you see
Ongoing ticket21% · no status
Create ticket · chat hidden48% · a list to scroll first

Raise via chat

0%→28%From a list item to the top of the page

Call

15%→8%Still there, by name, as a choice

Ongoing tickets

21%→51%With status and the next step
Learn6%
Create ticket via chat28% · raise issue first
Via call8%
Ongoing tickets51% · state + next step

After

New Help and Support: GPS in no-network area banner, Chat with Support and Raise Issue, Call Praveen, active chats and my tickets

Help & Support · central page

One door. A person behind it.

  • Raise Issue is the only primary action; the KAM stays one tap away by name.
  • Live tickets carry their state and next step, so there's nothing to call about.
  • Every card uses the same five states, each with one clear action or proof.
Help and Support on a first visit with no active tickets Help and Support with an active chat to resume and two tickets with their status

The ticket card · five states

In progress

Ticket card in progress

Verifying documents

Ticket card in progress with document under verification

Action needed · re-upload

Ticket card: documents rejected by bank, re-upload document

Resolved · rate it

Ticket card resolved, asking how satisfied the operator is

Rejected · with proof

Ticket card rejected, showing the current toll rate from NPCI as proof

Raising an issue · FASTag wrong toll deduction

A guided chat that answers before it tickets.

  • The operator starts it. Service, issue, vehicle, then the exact transaction from the last 30 days: tap, don't type.
  • The system checks first. The debit is compared with the current toll rate, assured by NPCI. If it's right, the operator gets an answer, not a ticket.
  • "I still want to raise the ticket" stays available, and then asks for the right proof once, up front.
  • The ticket arrives with the bank's timeline and shows up on Help & Support straight away.
~32%of all tickets are never created. By Phase 2, checks like this one resolve the issue inside the chat, on the spot: vehicle deboard, number change, transfer, name update and false fuelling. Every answer given here is one less ticket in the queue.
Support chat: Namaste, which service related issue do you have? FASTag chosen as the service
What issue do you have? Wrong deduction at toll, replace FASTag, need new FASTag, other issue
Wrong deduction at toll chosen
Select the vehicle you want to raise the issue for
Select Vehicle sheet with a search field and the operator's vehicles A vehicle selected in the sheet, Continue
The chosen vehicle number posted in the chat
Select the dispute transaction from the last 30 days
Select Transaction sheet: toll debits grouped by date with NPCI details
A toll debit selected, Continue
₹100 toll debit posted in the chat
Current toll rate ₹100; the debit is correct as per the latest toll rates, assured by NPCI
Okay chosen
Thanks for choosing WheelsEye; the conversation has ended
I still want to raise the ticket
Please select your issue: toll not debited, paid by cash and FASTag both, vehicle did not cross this toll
I paid by cash and FASTag both, chosen
Upload an image of the payment receipt; it must show vehicle number, date and time, toll plaza and amount
Upload Document: the cash receipt checklist beside the upload area The receipt photo attached with Remove and Submit Document under verification
Documents uploaded successfully
Concern shared with IDFC Bank: ticket created, the bank may take up to 10 days, View Ticket
Help and Support with the new ticket in progress under My Tickets Ticket sheet: extra amount was debited, document under verification, ticket created

Resolve without a ticket · unable to log in

The data said it was self-solvable, so I gave control back.

Operators who didn't get an OTP had to call us to log in. Ticket data showed a handful of causes they could fix themselves.

  • "Having trouble logging in?" lists five fixes, most likely first.
  • Each fix shows exactly where to tap on their own phone, not a paragraph of instructions.
Old OTP screen: Issue receiving OTP? Get Help Having trouble logging in? Five self-fix options Update your app, with a Play Store illustration Check your network connection, with an illustration of mobile data settings Restart your device, with an illustration of the power menu Check spam messages, with an illustration of the spam folder Clear your app cache, with an illustration of storage settings

Catch it where it happens · diesel sensor

Ask "is this right?" on the reading itself.

A wrong fuel reading used to surface as a phone call days later. Now the fuelling card asks, and a "No" turns straight into a structured report. The same path exists in chat.

Diesel filling card: +80 L at a named petrol pump, with 'Is this fueling value correct?' Yes / No
The nudge on the fuelling event.
How much fuel did you get filled? A number pad and Upload Parchi, over the vehicle page
Support chat: Diesel Sensor, wrong fuel filling, select your vehicle
Select Diesel Event: fuelling and theft events by date How much fuel did you get filled? with the number pad 100 L entered; upload an image of the fuel receipt Upload required images: diesel parchi or pump photo The parchi photo attached with Submit Submit required details: parchi done, an older parchi being attached Both documents done, Continue Documents uploaded; ticket created, the team is updating calibration details

After raising · the ticket journey

Every state says what happens next.

One ticket sheet follows the issue from report to rating. The strip under the title always answers the operator's first question: when it will be fixed, what they need to do, or how it went.

  • The current step sits on top as a card; everything that already happened stays below with a timestamp, so nothing feels lost.
  • The technician is a person, not a status: name, phone number, place and time slot are all on the ticket.
  • A failed visit explains itself and turns the strip into Action Pending with one button: Reschedule visit.
  • Rating happens on the ticket, in the strip that showed the expected resolution date, not in a separate survey.
GPS showing no info, ticket initiated by CC: expected resolution 22 Apr 2026, technician will be assigned shortly Visit scheduled at the Mini Truck Union, Naharpur, 22 Apr 8AM to 12PM; searching for a skilled technician near you Technician assigned with name and contact number; technician will visit on 22 Apr 2026 Action Pending: technician couldn't reach your location due to an unexpected issue; Reschedule visit button Visit completed successfully; issue under review by the support team Issue resolved; rate your experience with five stars in place of the resolution date Issue resolved; your rating: four stars

Status where the problem lives · contextual touchpoints

Operators shouldn't have to go looking for a ticket.

Each product shows its own tickets where the operator already is: on the vehicle's map, on the diesel page, on the FASTag page, and on home.

  • The ticket follows the asset, not the menu. Each page shows only the tickets that belong to it.
  • Open it in place. The same ticket sheet opens over the page, so context is never lost.
Vehicle map with a Ticket chip beside Play and Share GPS No Info ticket sheet over the vehicle map Home vehicle list with '1 ticket in progress' on a vehicle card Active tickets sheet on home: technician visit failed, reschedule Diesel vehicle list with a ticket in progress on one vehicle My Diesel Details with a Ticket in progress row above the fuel chart Sensor needs cleaning ticket sheet over the diesel page Fuel timeline with the ticket shown above it FASTag list with the tag's status on each vehicle My FASTag Details led by a Documents Rejected By Bank banner and Re-upload now

Escalation nudge on home

When we're waiting on the operator, say so on home.

A single strip above the bottom nav carries whatever needs the operator now, with its own action. It sits on both the new and the old home layouts.

  • One strip, one action: Upload again, View & pay, or the OTP the technician needs to close the job.
  • Time is shown, not promised vaguely: "12 PM – 2 PM", "2h 34m".
New home layout with a nudge strip above the bottom navigation Old home layout with the same nudge strip

The five nudge cases

Nudge cases: documents rejected by bank, technician will reach you today, installation in progress, OTP to end escalation, ₹2,400 payment pending
Each case brings its own action into the strip.

Closing the loop · feedback

Low ratings come with a reason.

  • Rating is the last message of the chat, not an email a day later.
  • A low score opens six specific reasons (technician late, too many follow-ups, visit scheduled too late…), pick up to two.
  • "Others" takes a voice note or text. For operators who'd rather speak than type, that's the difference between feedback and silence.
Ticket created; please rate this conversation, five stars Two stars: please tell us more about what went wrong, select up to 2 reasons Two reasons ticked and Others open Holding the mic to record, with a lock to keep recording Recording in progress with delete, pause and send Voice note recorded, ready to play back Others filled in as typed text Typed feedback ready to submit

AI for the agents · Customer 360

The call drops. The context doesn't.

Calls broke off mid-way, and an operator who rang back reached a different agent who started cold. An AI summary now does the handover: why the ticket is stuck, what changed, and the one thing the agent on the line can unblock.

  • The old console had no place for AI. It was built around one order: a wall of installer assignments and status changes on a single long scroll. A summary dropped in there would have been one more block for the agent to scroll past mid-call.
  • So the console was rebuilt around the caller. The agent searches the mobile number and the page opens on that operator. The AI summary gets a fixed rail that stays in the same place on every screen.
Customer 360 opened on one operator: all vehicles in a table, with the AI Summary in a fixed right rail One vehicle across GPS, FASTag and Diesel Sensor; the AI Summary rail stays in place Ticket drawer with the timeline; the AI Summary lifts into a floating card beside it Raise Ticket modal, with the AI Summary still readable beside it
Close FASTag Select vehicle / chassis Not listed · connect CC Closure ticket already open? Show the existing ticket FASTag balance? Confirm balancebank account only Confirm the taghas zero balance Move to another tagor a bank account? Document upload Document upload Pick new tag OTP confirmation OTP correct? Re-enter OTP Create ticket · end chat YES NO DECIMALSZEROPOSITIVE BANKTAG NO YES
Close FASTag, redrawn from my flow: every branch ends in the same verified step.

System-level · the logic under each chat

Every design started as a decision tree.

Before any screen, I mapped each high-volume issue as a tree: every question, every branch, every dead end closed. The chat screens are that tree, drawn for an operator.

Check in the treeWhere it runsWhat it prevents
Duplicate checkBefore any intakeA second ticket for an issue that's already open
NPCI toll rateWrong toll deductionTickets for debits that were correct
Balance branchFASTag closureRefunds sent down the wrong path
RC via OCR + VahanVehicle number changeInvalid details reaching an agent
OTPAny irreversible stepChanges without the owner's consent
Slot + pre-paymentField visitsWasted technician trips

Impact · Phase 1, four weeks after launch

Tickets operators raised themselves went from 40% to 60%.

Weekly share of tickets created through the app and web, 25 May to 27 July. Phase 1 launched on the Play Store on 22 June with 21 of 78 issue types, covering ~74% of volume.

0%20%40%60%80% Phase 1 target · 70% Live · 22 Jun 38% 47% 60% 25 May8 Jun22 Jun6 Jul27 Jul
40% → 60%tickets created in-app, 22 Jun → 13 JulMeasured
−14%Customer Care inbound calls vs the Apr–Jun averageMeasured
~₹40 lakhestimated annual saving from fewer calls, at ₹25 a callEstimate
−10%ticket-status follow-up calls, from real-time visibilityMeasured

Behaviour change like this usually takes about three months to settle; these are early indicators, not the full business impact.

Impact · Phase 2, live 25 August

From agent-assisted to app-led and automated.

Coverage

98% of ticket volumeVehicle number change, FASTag closure, AIS escalations, name change and login issues added.

Real-time resolution

~32% of all ticketsResolved inside the chat the moment the operator asks, so no ticket is ever created: vehicle deboard, number change, transfer, name update and false fuelling.

Resolution speed

Same-day non-ops: 50% → 66%Automated resolution already saves 25% of the resolution team's bandwidth.

Workload · estimate

~25% fewer CC/KAM callsAt steady state across Phase 1 and 2, roughly ₹80 lakh a year.
ProblemWhat I designedWhat moved
P1 Couldn't self-initiateTHE CORE PROBLEMOperator-started flows for 98% of volume: guided chat, self-fix for login, and nudges on the diesel card and home.40% → 60%tickets operators raised themselves Measured
P2 High cognitive loadOne Help & Support page ordered by intent and a tap-only chat.Chat 0% → 28%of the page, measured on the screens Design measure
P3 Inaccurate ticketsChecks built into the tree: NPCI toll rate, OCR, Vahan, duplicates.~32%resolved in real time, no ticket Measured
P4 No resolution visibilityTicket journeys, contextual touchpoints and the home nudge.−10% · −14%follow-up calls · inbound calls Measured
P5 Context lost between agentsCustomer 360 with an AI summary and one timeline per ticket.Shippednot measured separately yet Qualitative

Reflection & what's next

The design was never the hard part. The habit was.

For supported flows, CC and KAM teams now route operators to the app instead of creating tickets for them, and agent-created tickets are limited to genuine exceptions. Getting there took internal rollout as much as screens.

If I did it again, I'd design the agent-side habit change alongside the operator flows from day one.

  1. 22 Jun
    Phase 1 · Android21 issue types, ~74% of volume. iOS on 20 July, Operator Web in August.
  2. 25 Aug
    Phase 298% coverage and real-time resolution for ~32% of tickets.
  3. Next
    An AI support agent, available 24×7Answer information queries first, then the long tail of 55 issue types, and eventually make the app the default for the ~1.25 lakh monthly inbound calls.