WheelsEye is a fleet management platform in India offering telematics solutions like - GPS tracking, advanced Pro features, diesel monitoring and many more. It serves logistics companies and large fleet owners seeking operational visibility, fuel control, and compliance management at scale - shifting manual operations to digital fleet intelligence.
✦ Solely Led
THE CONTEXT
Why? - a strategic call
Wheelseye has taken a strategic decision to move order creation and fulfillment from a Thor-led, sales-driven model to an app-led hybrid distribution model, where Sales (SE/KAM) assist customers but transactions are executed digitally.
Today, selling is almost entirely agent-driven:
•. SEs and KAMs generate leads and pitch products
Negotiate pricing, apply discounts and punch orders in Thor
Post order they collect documents and coordinate installation.
The customer app plays a minimal role until after installation, they do have a 'My Order' page where they can see the invoice and price breakdown, BUT nothing more than that.
THE GAP
Product understanding is largely verbal and execution quality depends heavily on individual sales judgment. The Self-Buy flow unlocks independent plan selection, checkout and onboarding.
💰 Revenue leakage
Order splitting, fake vehicle numbers, and pricing manipulation were hard to catch in a fully human flow.
👨🏻💼 SE as bottleneck
Every order required a sales executive to be present. Scale was capped by headcount, not demand.
🙅🏻♂️ No customer ownership
Fleet owners had zero visibility into their own order, they called the SE to find out what was happening.
📝 Opaque pricing
Customers didn't know if the price was fair. Trust was built on the SE's personality, not the product.
THE CHALLENGE
Sales assited, not Sales dependent
The goal wasn't to remove the sales executive, it was to stop the transaction from depending on them. The SE stays in the loop for context, trust, and attribution. But the customer completes the order themselves.
CORE DESIGN Decisions
User friendly
Fleet owners not digital first users. They're truck operators used to negotiating face-to-face. Clear flow without calling support
Pricing is transparent from login
No negotiation. No asking. Personalised price shown on first open + progressive disclosure of relevant features.
App executes
Transaction happens in the app. SE assists but never blocks.
Sales has visibility, not control
SE monitors in Thor. Customer owns the order.
DESIGNS
From download to device installation
STATUS
Work in Progress & Learnings
✦ This project is currently in progress.
LEARNINGS
As this was the first attempt at enabling customers to purchase directly without Sales Executive involvement, I had to understand how the existing business operated end-to-end and not just the user interface.
How Sales Executives sold plans
What information customers needed before purchasing
How onboarding was handled
Drop-off points in the sales process
Package selection
Technical dependencies and limitations
KYC requirements
Vehicle onboarding
Device onboarding
Focused on creating a scalable foundation
Build a realistic first-cut Self-Buy experience
Deferred non-essential improvements to future iterations
What's being built next
Bulk order flow
Token payments
Drop-off and resume handling
Upsell experience design
THE GAP
✦ Mentored + Collaborated
Repeatable queries that didnt need a human agent
30-40% Inbound Calls were informational queries
Fleet operators often knew what they wanted to find, but couldn't navigate to it quickly enough and would call customer support.
Top Informational Query Types
🚛 GPS pricing & feature explanations
💳 Renewal payment queries
🔄 Recharge status / pending queries
📡 Device status / offline questions
💰 Toll & wallet deduction explanation
My Role: Direction & Mentoring
Defined scope, constraints, and UX principles for the intern to work within
Ran weekly critique sessions on flows and interaction details
Made final calls on ambiguous UX decisions and edge cases
Intern Ownership
UI research and market study
First-pass explorations for empty states and loading patterns
Documentation of chat patterns for developer handoff
RESEARCH
Key Design Decisions
1
Challenge
What should the AI confidently answer vs. gracefully decline, scope needed to be clear upfront
Decision
Defined a strict "answerable" answers which were tied to existing data modules like trips, fuel, alerts.
Rationale
An AI that over promises and fails breaks trust faster than one that's honest about its boundaries from the start.
2
Challenge
Intern was designing screens without a strong understanding of what and how operators actually ask query.
Decision
Created a set of 12 "real operator questions" as design constraints intern had to validate every flow against them
Rationale
Grounding the intern for in real user scenarios, preventing generic chat UX patterns that wouldn't fit a B2B fleet app.
