← Back to work
Case file 04 · Field ops · Shipped

When dispatch runs on phone calls

One place for field crews, supervisors, and the office to see the same job.

Product
HeavyOps
Role
Lead Product Designer
Platform
iOS · Android · Web
Field Operations Workforce Management Dispatch Payroll Equipment Learning Management Time & Attendance
Thursday, 6:30 AM · Dispatch office

A new job came in overnight. Four workers. One excavator. On site by 8:00 AM.

The dispatcher didn't open a system. He started making phone calls.

Supervisors confirmed available workers over WhatsApp. Equipment location was checked through paper logs because no one knew where the excavator had last been assigned. Workers wrote down their hours at the end of the day, leaving payroll to reconcile clock-in and clock-out discrepancies later.

The people doing the work weren't technical. If recording something took longer than a quick call or a note on paper, they skipped the system altogether.

Everyone had information. Nobody had the same information.

Dispatch, attendance, equipment, and payroll all depended on manual updates, creating delays, duplicated work, and costly mistakes every day.

HeavyOps replaced those disconnected processes with one system crews could actually use in the field.

HeavyOps mobile app showing weekly timesheet with logged hours and active work timer for a field task
Product UI · Timesheet & work timer
User flow · Homepage hub · Create & assets paths
01

The problem

Managing field operations wasn't just a scheduling problem. It was a coordination problem.

Every department solved its own problem. Nobody had the same picture of what was happening.

02

Understanding the work

Instead of jumping into modules, I wanted to understand how work actually moved through a normal day.

I worked with the CEO and talked to supervisors and field workers about dispatch, attendance, equipment handoffs, and how payroll data got collected.

The same themes appeared repeatedly:

Dispatch depended on conversations

Job assignments happened through calls and WhatsApp because there wasn't a trusted scheduling system.

Payroll started with inaccurate data

Workers often submitted hours long after work finished, leading to manual corrections before payroll could be processed.

Equipment lacked visibility

Managers knew what equipment they owned but struggled to know exactly where it was or who was responsible for it.

Training wasn't part of operations

Learning records existed separately from scheduling, so supervisors couldn't easily verify whether someone was qualified before assigning specialised work.

03

Research synthesis

Across interviews and workflow mapping, one thing kept coming up.

The problem wasn't dispatch. It wasn't payroll. It wasn't equipment. It was coordination.

Every workflow depended on someone remembering to update someone else. That's when delays, duplicated work, and manual reconciliation started.

That changed the product direction. Instead of separate features, we built one experience centred on the worker.

04

The design challenge

Software people could use while working. Not sitting behind a desk.

Standing outdoors. Wearing gloves. Walking around machinery. Often with poor network coverage.

Every tap had to save time, not add to it.

05

The solution

Instead of treating Dispatch, Payroll, Equipment, Learning, and Attendance as separate products, I designed them around one job workflow.

Dispatch

Supervisors assign work from one shared schedule based on worker availability, role, and location instead of making multiple phone calls.

Time & Attendance

Workers clock in and out directly from their mobile device, creating more reliable attendance records for payroll.

Task Management

Daily activities, inspections, and follow-up work remain attached to the job instead of disappearing inside chat conversations.

Equipment Management

Equipment travels with the job assignment, giving supervisors visibility into where assets are being used and who is responsible for them.

Learning

Training and certifications live alongside the worker profile, making qualification checks part of the scheduling process instead of an afterthought.

HeavyOps mobile screens showing work order dashboard and training course library
Product UI · Work orders & training
06

Journey transformation

Before · Fragmented coordination
Dispatch receives a new job
Supervisor phones available workers
Worker confirms over WhatsApp
Equipment assigned separately
Worker writes attendance manually
Tasks communicated verbally
Timesheets submitted at day's end
Payroll corrects errors
Managers chase equipment history
Reports compiled manually
After · One shared workflow
Dispatch creates a job
Assign available crew
Assign equipment
Worker receives assignment instantly
Clock in on arrival
Complete assigned tasks
Clock out
Attendance flows into payroll
Equipment history updates automatically
Managers see live job status
HeavyOps mobile screens showing work order list and assets list with equipment details
Product UI · Work orders & assets
07

Key design principles

08

Business impact

HeavyOps wasn't built to replace paperwork. It was built to cut the cost of bad coordination.

Less dispatch friction

Supervisors coordinated crews from a shared schedule instead of calls and group chats.

Better payroll accuracy

Clock-in and clock-out happened closer to when work actually happened, so payroll had fewer corrections to make.

Equipment visibility

Assignments linked to jobs and workers, so asset use was easier to track.

Faster workforce readiness

Training records showed up during scheduling, so supervisors could check qualifications before assigning specialised work.

One view of the job

Dispatch, attendance, equipment, tasks, and learning ran off the same workflow. Less duplicated effort, fewer phone calls, more time on actual work.

09

Reflection

The coordination lesson

Every feature looked useful on its own. The real value was connecting them. When scheduling, attendance, equipment, payroll, and learning share the same context, teams stop coordinating by phone and start working from the same picture of the job.

That was the problem HeavyOps was solving.

↑ Back to work