Improving AIS device - Purchase & Checkout Flow
Turned a government compliance purchase that ran entirely through Sales Executives and a Google Form into a self-serve in-app flow: with one registration number doing the work of 18 form fields.
THE CONTEXT
What is AIS 140?
AIS 140 is a Government of India mandate under MoRTH. Every commercial vehicle on a government project like RTO routes, mines, FCI logistics needs a certified GPS device and an AIS certificate to operate legally.
The user isn't choosing whether to buy - they have to. Design challenge is speed, accuracy, and trust not conversion.
🚨
This wasn't a redesign. There was no existing in-app flow to redesign. The entire process ran through Sales Executives, external tools and a Google Form.
CURRENTLY
100% SE-dependent. Zero in-app.
SE collects vehicle details manually
SE Navigates an external portal to find the right plan
SE filles the AIS certificate in a Google Form post-installation.
Wheelseye team processes and sends certificate
Customer had zero visibility throughout
AFTER
In-app, self serve.
Customer selects project in Wheelseye app
Enters vehicle registration number - ULIP resolves plan
Purchases plan in-app, SE assists but doesn't block
17 of 18 AIS certificate fields pre-filled from RC data
Certificate made available in 30 minutes
THE GAP
Moving the flow in-app was a business call. But building it revealed a design problem: AIS plans are not uniform. Every state project has different eligibility rules:
Karnataka RTO → plan varies by vehicle type + age + fitness certificate
UP Project → plan varies by OEM brand (Tata, Ashok Leyland)
Panic buttons vary by seater count: a 5-seater car, 15-seater bus, 40-seater bus each need different plans
Result: hundreds of possible plan combinations.
DESIGNS
Three stages to the right answer
How decisions were made
Ops team wanted more filters. Different states, different rules.
We didn't push back immediately. We mapped every filter to the data it was resolving : vehicle type, age, panic buttons, certificate type.
Then asked: where does this data already exist?
The answer was ULIP - infrastructure we were already using in another module. One registration number resolves what five filters were trying to ask.
The ULIP integration wasn't a new build. It was recognising that a solved problem in one module (Fastag) could eliminate an unsolved problem in another. That's the kind of cross-functional awareness that only comes from understanding the full platform, not just your own screen.
STATUS
Metrics & Learnings
Certificate reviewed by Wheelseye team and delivered within 30 minutes - replacing a manual Google Form process with no defined turnaround time.
600+
Order/month
17 of 18
fields pre-filled
100s -> 1
Plans combinations
LEARNINGS
every time there was friction, the right question was "does this need to exist at all" not "how do we make this better"
Recognising it could solve a different problem is systems thinking, not just screen design
when users have no choice, the bar is speed and trust, not conversion. Get them to the right outcome fast.
this couldn't be designed from a brief. It required understanding how SEs operated, why the Google Form existed & what the ops team feared losing
