A Field-Service Scheduling App for a 40-Technician AC Firm in 5 Weeks

A Hyderabad AC-repair firm with 40 technicians was dispatching jobs over WhatsApp groups and a whiteboard in the back office. Two coordinators spent their whole day on the phone, technicians drove criss-cross routes across the city, and customers got "sometime today" for an ETA. During the May heatwave, call volume tripled and the system fell over. We shipped a field-service scheduling app in 5 weeks: route optimisation, a technician mobile app, SMS ETAs, and parts inventory. This is the sprint-by-sprint breakdown, the architecture, and the one number that mattered to the owner. ## The Answer in 60 Words We built a scheduling app with three pieces: a dispatcher web console that auto-assigns jobs by location and skill, a technician mobile app for the day's route and job updates, and an SMS layer that sends customers a live ETA. Route optimisation cut driving time, which lifted jobs-per-technician 27%. Built in 5 weeks across four sprints for roughly ₹9 lakh. The owner's one metric: jobs closed per day. ## The client (specific details) - Sector: AC sales, installation, and repair (residential + small commercial) - Location: Hyderabad, Telangana - Size: 40 field technicians, 2 dispatch coordinators, ₹18 Cr turnover - Stack on day 0: WhatsApp groups, a physical whiteboard, an Excel sheet for parts - The trigger: May heatwave tripled call volume; the whiteboard system collapsed and they turned away jobs they couldn't schedule ## Why this matters now India's summer cooling demand is brutally seasonal — when a heatwave hits, an AC-repair firm's order book triples in a week, then settles. We wrote about the demand-spike pattern for online retail in our monsoon-ops resilience post; field service has the same problem with a physical constraint — you can't autoscale technicians. The only lever is using the ones you have more efficiently. Route optimisation and clean dispatch are the difference between closing 6 jobs a day per technician and closing 8. ## What we built (the four pieces) ## The methodology (how we ran the 5 weeks) ## What a build like this needs (prerequisites checklist) If you're scoping a similar field-service app, this is the shortlist of what has to be in place before sprint 1. Skip one and a sprint slips.

• A clean technician roster with correct phone numbers — the seed data that broke our day-1 login
• Defined skill tags per technician (split AC, window AC, commercial chiller) so auto-assign can match
• A parts master list with reorder thresholds, even a rough Excel one to import
• An SMS provider with a registered DLT template (mandatory in India for transactional SMS)
• Map data for your service cities — OSRM needs an OpenStreetMap extract per region
• One coordinator and two technicians available for ride-along discovery in week 1
• A decision on accounting sync (Tally or Zoho Books) so the data model fits from day one

## The architecture (and the route-optimisation decision) The stack was deliberately boring: a Next.js dispatcher console, a React Native technician app, a Node API, and Postgres with PostGIS for geo queries. The one decision that needed thought was route optimisation. Three options, and we picked the middle one. | Approach | Cost | Quality | Why we chose / skipped | |---|---|---|---| | Naive nearest-job | ₹0 | Poor at scale (zig-zag routes) | Skipped — fine for 5 jobs, breaks at 40 | | Google Routes API optimisation | ~₹0.40/route call | Very good, traffic-aware | Skipped — cost scaled badly at 200+ daily routings | | Self-hosted OSRM + heuristic | ₹1,200/mo server | Good enough; we tune the heuristic | Chosen — fixed cost, full control, no per-call billing | We made the same boring-stack, fixed-cost choice building the logistics fleet-tracking dashboard — the geo-query patterns carried straight over. For the data model, we reused approaches from our 14-branch diagnostics-lab CRM. ## The sprint breakdown (copy this for a similar build) ## Common mistakes in field-service builds Symptom: "Technicians won't use the app." Cause: forms built for an office, not a one-handed technician on a ladder. Fix: every field action should be 1–2 taps. Photos over typing. We cut a 6-field form to 2 taps and adoption jumped. Symptom: "Auto-assign produces routes drivers hate." Cause: the algorithm ignores tribal knowledge — building access, parking, which technician knows which complex. Fix: auto-assign suggests, the coordinator confirms. Never fully automate away the human who knows the city. Symptom: "SMS ETAs make customers angrier, not happier." Cause: an ETA that's always wrong is worse than none. Fix: send a window ("between 2 and 4 pm"), not a precise time, and update it when the technician marks the previous job done. Symptom: "Parts inventory is always wrong within a week." Cause: technicians forget to log parts used. Fix: make logging parts a required step to close a job — no parts form, no job-closed status, no payment trigger. Symptom: "The route optimiser bill keeps growing." Cause: per-call routing API at scale. Fix: self-host OSRM at a fixed monthly cost once you cross ~50 routings a day. ## The outcome The 27% lift in jobs-per-technician was the number the owner cared about — it's pure margin during peak season when every extra job is demand he was previously turning away. We delivered this through our mobile app development team, led on the project by Vivek, our co-founder. We've shipped field-service variants since for a Pune lift-maintenance firm and a Coimbatore generator-service company. The mobile patterns trace back to our own product work on TalkDrill, our in-house React Native app whose case study sits in our portfolio — the same offline-tolerant sync model handles a technician in a basement with no signal. We sanity-checked our route-optimisation choice against field-service-management community threads, where self-hosted OSRM is a common recommendation for firms that outgrow per-call routing pricing. ## The India-specific details that bite Two things about building field-service software in India that a generic playbook won't warn you about. First, transactional SMS needs a DLT-registered template — under TRAI rules you can't just send free-text SMS at scale; every ETA message template has to be pre-registered with your telecom operator, and approval takes a few days. We registered ours in week 2 so it was live by the week-4 SMS testing. Second, addresses are a mess. Indian addresses often lack precise geocoding — "near the second water tank, Kukatpally" is a real one we got. We added a "drop a pin" step in the technician app and let the customer share a live location over WhatsApp, because forcing a clean address would have failed on day one. These two details have sunk field-service builds that assumed a Western address-and-SMS model. ## What we'd do differently We under-scoped offline mode in sprint planning. Hyderabad has dead zones — basements, older buildings — and the first technician app assumed connectivity. We patched in offline job-caching in week 5, which was tighter than it should have been. On the next build we scoped offline-first from sprint 1. The lesson: for any India field-service app, assume the technician loses signal several times a day and design for it on day one. ## FAQ ### How long does a field-service scheduling app take to build? For a 40-technician firm with route optimisation, a technician app, and SMS ETAs, we shipped in 5 weeks across four sprints. A simpler build — dispatch and a technician app without route optimisation — can land in 3 weeks. Complexity scales with route logic and inventory depth. ### Should I use Google's routing API or self-host? Under about 50 routings a day, use Google Routes API — it's traffic-aware and you avoid running a server. Above that, the per-call cost climbs past a self-hosted OSRM server (around ₹1,200/month fixed). We chose OSRM for the 40-technician firm doing 200+ daily routings. ### Why build the dispatcher console before the technician app? Because the coordinator was the bottleneck, not the technicians. Always build for the constraint first. The two coordinators on the phone all day were the limiting factor; freeing them delivered value before a single technician opened the app. ### How do you get field technicians to actually use the app? Keep every action to 1–2 taps and favour photos over typing. Our first job-update form had 6 fields and technicians ignored it; cutting it to 2 taps and a photo fixed adoption. Field-test with real technicians before full rollout. ### What does a build like this cost? Roughly ₹9 lakh for the 5-week fixed-scope build covering all four pieces. The firm's payback was inside the first peak month, driven by the 27% lift in jobs closed per technician. Ongoing run cost was about ₹1,200/month for the OSRM server plus SMS charges. ### Does the app work when a technician loses mobile signal? It needs to. We learned this the hard way and now scope offline-first from sprint 1. The technician app caches the day's route and job data, queues updates locally, and syncs when signal returns — the same model we use on our in-house mobile products. ### Can this integrate with our existing accounting software? Yes. We sync closed jobs and parts consumption to Tally or Zoho Books so invoicing and inventory stay in one place. We typically wire this through an n8n flow on the same pattern as our Razorpay-to-books reconciliation builds.