Close work orders 25% faster at Vodafone Idea
Client: Vodafone Idea is an India-based mobile network, similar to Verizon in scale, serving 200 million subscribers across mobility, fiber, transmission and enterprise.
(role)
Sr. Product Designer
Owned design end-to-end: research, testing, prototyping & handoff.
(SERVICES)
Enterprise SaaS Field Operations Native Mobile
(Team)
(TIMELINE)
6 months
(Overview)
Goal is to speed up the work order flow for field engineers. In network repair, a tower stays down until an engineer reaches it, so the time between dispatch and completion is critical. The current flow ran on WhatsApp, leading to missed and duplicated jobs. I re-examined the entire flow, identified and removed non-critical steps, and restructured the dispatch message. An 18 minute job closes in 13.5.
(result)
4.5 minutes
Time saved per work order: 18 min→13.5 min
89%
Daily active use, 30 days post launch
75%
Error rate reduction
Before: Four group chats, 61 unread, and a work order somewhere inside them. A job assigned by message, with no state and no record.
After: Every job arrives with a site ID, a domain tag and one action. The acknowledge button is what replaced the reply that said "ok".
Let's break down the problem
(Problem 1)
Missed Dispatch.
A field engineer repairs the physical network rather than working from an office, covering cell towers, fiber lines and transmission equipment across a zone. For example, if a tower's battery fails, every subscriber in that cell loses signal until someone drives out and replaces it.
Problem: field engineers need to receive jobs instantly and unambiguously, because a tower stays down for as long as the job takes to land. The dispatch ran across four group chats, so a job could be missed entirely, and nobody knew until something broke.
Engineer’s world: outdoors, one hand free, weak signal, no time to think.
Manager's world: a desk, 2 monitors, 200 engineers to account, before 9am.
(Problem 2)
Towers were waiting.
As a result of these issues, 12% of work orders came out wrong, duplicated or missed. Faults sat unrepaired while managers assumed they were handled, affecting network uptime and the operator's ability to compete on coverage.
Over 14,000 repair jobs a day were missed, duplicated, or delayed because work was managed through Whatsapp group chats. Every missed job meant a subscriber could be left without service.
(Process 1)
Optimizing the work order flow
Four distinct stages: finding the job in a group chat, acknowledging it by reply, reporting status by phone from the site, and logging completion in a shared sheet at night. Altogether this was taking about 18 minutes per work order, and I had to figure out how to reduce that time.
Mapping the four stages gave us the first clear architecture: map + searchable engineer list, with key details defined upfront.
(Process 2)
The status call was redundant because 88% of jobs ran without a problem. The call was made on every job to catch something that happened in 12% of them, and it pulled the engineer off the tower to make it. Each call took about 2.5 minutes.
Completion was logged the same way, hours later, from memory, adding another minute and arriving too late to be trusted. Finding the job across four chats and replying to acknowledge it took a minute before any of that.
Three of the four stages were bookkeeping, not repair. Moving all of them into the work order itself takes 4.5 minutes out of an 18 minute job, which is 25% faster.
Wireframing the two paths a job can take. The top row accepts, the bottom rejects, and both close inside the work order instead of on a phone call.
(User Goals)
As a field engineer, I want to receive a job & know exactly what it is without reading back through a chat, so I can get to the site and fix it.
Field Engineer
As a zonal manager, I want to see where 200 engineers are & what is blocked, without calling anyone, so I can move a job before a tower stays down.
Zonal Manager
(Iterations)
1.One app for both users 🚫
One responsive web app, cheaper and one codebase, which is what the client asked for. Building native was a significant effort, but photo proof closes every job & a task nobody is notified about just waits.
2.Zones on a map 🚫
The city wide zone map let managers click each zone to see engineers, open jobs, and workload. Engineer level details were too heavy to render, so we prioritized a lighter field ready version first.
3.Two surfaces, one work order ✅
Native apps for the field and a desktop board for the back office, with assignment moved out of chat into a structured work order. The one-app version gave the manager a view the engineer could not use one-handed. The map gave the manager a better view and gave the engineer nothing. Splitting the surfaces was what let both of them be right.
(Learnings)
Most engineers simply report that jobs went fine, while blocked jobs need clear details and fast support. I optimized the main flow for the 88% and gave extra care to the 12% exception cases.
Engineer level zone maps were too complex for this version, so I focused on the work order flow. Escalation routing remained manual because rules differed by zone and were undocumented.
(Solution 1)
Chat message → Work order
The first solution converted the chat message into a structured work order with clear states and required fields, replacing four disconnected channels. Accept, hold, resume, proof, and close now lived in one place, saving 2 minutes.
Constraint: every step was designed for one-handed use, direct sunlight, work gloves and weak signal. Touch targets stay at 44px or larger, and every screen holds contrast in daylight. (WCAG 2.1 & Apple HIG)
8 states a chat message never had
The same states on the engineer's phone
(Solution 2)
Phone call → Live board
The second solution was to replace the follow-up call with a board. The manager was calling 200 engineers to find out what the work order already knew. By surfacing status as it changed, we removed the call and the 90 minute evening report with it. (Saved 2.5 minutes)
Pro tip: the board had to work on a phone too. A manager is not always at a desk when a ticket lands.
200 engineers, 4 domains, one dashboard
Same board on the phone
(Solution 3)
672 open tasks → Searchable work orders
The third solution was to make 672 open tasks easy to find. Instead of scrolling through the board, managers could search by priority, domain, site ID, or ticket number, with recent searches and frequently used tags surfaced upfront.
Results were actionable, not just readable. Managers could select multiple jobs and unassign them in one action, with a remark attached, instead of fixing each one separately.
Quick search on the tags a manager already uses
4.5 min saved per work order, 25% faster, across 120,000 daily jobs.
Taking the chat hunt, the status call and the evening sheet out of the job removed 4.5 of its 18 min. Across 12,000 engineers closing 10 jobs each, that is 9,000 engineer hours a day returned to repair work.
(From the team)
"Working with Rachana on the Vodafone project was great. She understood the reasons behind the flaw in the process, talked to the people in the field, and continuously streamlined the process till it worked. It was very inspiring to see her sense of ownership and her ability to question an existing process."
- Ornellius Saldanha (Lead Designer)
