Qserve

Problem

Field service is easy to describe and difficult to model. A single service request touches a customer, a technician, a franchise operator and an admin before it's closed — and each of them needs a different, correct view of the same underlying ticket.

Engineering challenge

The technician journey alone needed to exist as an explicit state machine — assigned, en route, arrived, OTP-verified start, in service, completion requested, OTP-verified completion — coordinated with scheduling, evidence capture and role-based permissions, so that a reassignment or an escalation never leaves the ticket in an ambiguous state.

What I built

• Customer booking flow: service and issue selection, evidence upload, slot selection, review, confirmation
• Technician workflow app built for fast field use — large touch targets, explicit status at every step, OTP verification for both start and completion, photo evidence capture
• Franchise & admin operations: assignment, escalation, payouts, claims, and technician/master-data management
• Workforce scheduling: weekly rosters, holidays, per-date availability overrides and preferred working hours translated into predictable booking-slot availability
• A single authentication model shared across all four actor types, with role-specific capabilities layered on top rather than four separate systems

How it works

Outcome

Turned a process that depended on phone calls and manual coordination into an auditable, state-driven workflow — every ticket has one source of truth for where it is and who's accountable for the next step.

Domain

Selected implementation and client details are intentionally omitted — this work was delivered as client engagement.