The HVAC and plumbing operators we talk to in Bangalore, Pune, Mumbai, and Hyderabad all describe the same Tuesday morning. Forty jobs on the board, twenty-eight technicians on the road, three WhatsApp groups going at once, a spreadsheet that nobody trusts after 11am, and a dispatcher quietly pasting addresses into Google Maps to figure out who's nearest to the 3pm Whitefield call. The software didn't fail. It was never really there.
This post is for owners and operations leads of ten-to-fifty-technician field service businesses in India — HVAC, plumbing, refrigeration, sometimes solar and water purifier servicing. It's the framework we walk through when one of these companies asks us whether to buy a packaged FSM, build custom, or live with the spreadsheet for one more year. It assumes you already know the symptoms; the question is what to do about them without breaking next quarter.
What "dispatch software" actually has to do
The phrase covers six different jobs, and conflating them is most of why this category disappoints buyers. Before any vendor demo, name which jobs you're actually buying for.
- The job board. Today's open jobs, who they're assigned to, what state they're in. This is the thing the dispatcher stares at all day.
- Routing and scheduling. Given today's jobs, technician locations, skill match, and SLAs, what's a sensible plan for the day? In Indian cities, where two kilometres can be forty-five minutes, this is the highest-leverage feature in the category.
- The technician app. What the field engineer sees on the phone — today's stops, address with map link, customer history, what was done last visit, parts they need to carry, and how to mark a job started, paused, or done.
- Customer-facing communication. "Technician on the way," "running late by twenty minutes," "service complete, here's the report and invoice." In India this almost always lives on WhatsApp; treat any product that ignores WhatsApp as half-built.
- AMC and contract tracking. Which customers have an annual contract, what it entitles them to, when it renews, and whether you're hitting the SLA. Almost no packaged product does this well for the Indian context.
- Billing, GST, payments. Job-to-invoice, GST-compliant tax invoices, partial payments, AMC invoicing, integration into Tally or Zoho Books for the accountant. This is where most global products fall over.
A real dispatch decision is six decisions stacked on top of each other. The realistic outcome is that you'll buy a packaged product for two or three of these jobs, accept that two of them will live in a hybrid setup with WhatsApp and Tally, and build a thin custom layer for the one or two that genuinely make your business different — usually customer experience and AMC renewals.
The buy-side reality in 2026
The Indian field service software market has matured. Zoho FSM has become a credible option for operators already on Zoho One, and the Indian-built crop — FieldEZ, FastTrak, ServiceMax for India, FieldCircle, several Bangalore-built products — covers most of the basics. Global products like Housecall Pro, Jobber, ServiceTitan, and Workiz are technically usable in India and a handful of operators run them, usually with custom GST and Tally workarounds.
A useful rule of thumb: if you're under twelve technicians, on a single city, with one service line and a relatively standard AMC structure, almost any of these products will run your dispatch well enough that the differences are noise. Pick the one whose support team picks up the phone in your timezone. Stop evaluating.
The packaged story breaks at three thresholds, in this order. The first is multi-city or multi-branch: the moment you have a Bangalore branch and a Hyderabad branch with different technician pools, different on-call rosters, and different vendor parts suppliers, packaged products start showing seams. The second is mixed service lines: an operator doing HVAC and plumbing and refrigeration has three different job shapes, three different parts catalogs, three different SLA structures, and packaged products are usually strong in one. The third is AMC-heavy commercial books: when a third or more of your revenue is contractual and the rest is one-off jobs, the AMC layer is the thing your business actually runs on, and it's the layer packaged products think least carefully about.
Where the day actually breaks
Before any software decision, sit a dispatcher down and watch a Tuesday. Where the hours go almost never matches what the vendor's pitch deck attacks. The recurring losses we see, in roughly this order:
- Re-dispatching after a no-show or a delay. A 10am job runs ninety minutes long; the 11:30am, 1pm, and 3pm jobs all need to shift. The dispatcher does this in their head and in WhatsApp. Almost no packaged product handles cascading reschedule well, and the ones that do don't push the customer-facing notification cleanly.
- Customer comms during the visit. "He's on the way." "He's twenty minutes out." "He's done." These messages are the customer's entire experience of your company, and they live on WhatsApp because customers won't install your app. Operators who build a thin layer that pushes these into WhatsApp Business automatically — driven by status changes in the dispatch app — see complaint volume drop sharply.
- Parts and inventory at the technician's hand. A technician arriving without the right capacitor or compressor adds a return visit and a refund argument. The fix is partly process (a checklist by job type) and partly software (visible inventory by van, parts pulled to a job in advance).
- AMC visit cadence. A quarterly preventive-maintenance visit on a five-AC AMC, multiplied by 400 contracts, is a planning problem nobody wants to do by hand. It's also the visit type customers most often don't realise they're owed, which is a renewal-loss timebomb.
- Renewal motion. Contracts ending in 90/60/30 days that nobody is calling. This is the highest-leverage thing the dispatcher's manager should be doing on Monday mornings, and it's usually buried in a spreadsheet that's three weeks stale.
Look at this list and notice the pattern: the routing engine is rarely the bottleneck. The lost hours sit in the seams between the dispatch board, the customer's WhatsApp, the AMC schedule, and Tally.
The framework we use
When an HVAC or plumbing operator asks us what to do, we run five questions. About an hour of an owner's time. The answer is usually obvious by question three.
- What does your busiest day actually look like, hour by hour? If the owner can describe it precisely, the gaps are visible. If they can't, the gap isn't software — it's the operating rhythm. Software won't fix that.
- Where do customers complain most? First-time booking experience? On-the-way comms? Invoicing? AMC delivery? The answer points at which layer of the stack to invest in first, and it's almost never "the routing engine."
- What share of your revenue is AMC vs one-off? Above a third, AMC is your real business and packaged products are not enough. Below a third, you can probably run AMC on a side spreadsheet for one more year.
- How many cities, how many service lines, how many technician pools? One of each? Buy a packaged product. More than one of any? Plan for a hybrid.
- What are you willing to own long-term? Custom software needs a retainer relationship and a partner who actually answers in March. Packaged software needs a renewal cycle and an admin who fights with support tickets. Both are real costs. Pick the one that matches your firm's temperament.
If the answers point to "we look like a small, single-city, single-line operator," buy a packaged product and stop. If they point to "we have a real AMC book, multi-city sprawl, and a customer-experience problem we're losing on," consider a hybrid: packaged dispatch core, custom AMC and customer-experience layer on top, integrated with Tally for accounts. We saw this pattern up close in our work with Northridge Mechanical — a forty-technician HVAC operator where the leverage wasn't in better routing, it was in an AMC cockpit and a WhatsApp-driven customer journey nobody had built before.
What a hybrid usually looks like
The operators we've worked with end up with roughly this stack, give or take.
- Dispatch core, technician app, basic routing. Packaged. Zoho FSM, FieldEZ, or — for English-comfortable urban teams — Housecall Pro or Jobber with India workarounds. Don't over-evaluate; pick the one whose support is responsive and stop.
- Customer-facing comms. Custom or near-custom, on top of WhatsApp Business API. Triggered by status changes in the dispatch app. This is the layer customers feel and the layer that buys you reviews.
- AMC management. Custom. A first-class AMC object with visit schedule, SLA, renewal date, customer-specific terms, and a manager-visible cockpit. Renewal automation that fires at 90/60/30 days with the right customer message. Two to four weeks of focused build. Lasts five years.
- Billing and accounts. Tally or Zoho Books, integrated with the dispatch product via a thin sync. Don't try to replace the accountant's tool; integrate with it.
- Owner cockpit. Custom. One screen, four numbers — open AMCs, jobs at risk today, this-week revenue against plan, NPS or complaint signal. Pulled from everything below it. Sent as a Monday morning summary. Cheap to build, expensive to live without.
Notice what's not on that list: a custom routing engine, a custom technician app, a custom GST invoicing system. Those are commoditised, the packaged products are good enough, and building them is a category error.
For canonical reference on the GST invoicing rules every dispatch product needs to respect — particularly e-invoicing thresholds and the contents of a tax invoice for service businesses — the GST Council's official site is the source of truth. Packaged products' interpretations drift; the rule itself doesn't.
When to roll it out
The single most important decision after "what" is "when." For an HVAC operator, the worst time to switch dispatch software is April through June — peak AC season. For a plumbing operator, the worst time is monsoon. The right window is the quarter before your busy period: enough time to pilot, fix the obvious gaps, and have the team running on muscle memory before volume hits.
Eight to twelve weeks is realistic for a thirty-technician rollout: two weeks of documenting the current process before any product touches anything, two weeks of pilot with three to five technicians on a single route or service line, two weeks of fixing what the pilot exposed, then a staged rollout by city or branch. Operators who try to flip the whole team in a weekend lose a month of productivity and a quarter of trust.
What we'd buy first if we were starting today
If we were starting a thirty-technician HVAC company in Bangalore today, we'd run a packaged FSM (Zoho FSM if we were already on Zoho, FieldEZ otherwise) for the dispatch core and technician app, Tally for books, WhatsApp Business API for the customer surface, and we would spend the first six months not customising any of those. We would spend months six to twelve — and roughly six to ten lakhs — building two things: an AMC cockpit with renewal automation, and a customer experience layer that turns dispatch status changes into WhatsApp messages a human would actually want to receive.
By month twelve, the business would feel different on a Tuesday morning. None of it would involve replacing a packaged product. All of it would involve owning the seams between them — and the surface customers actually see.
That's usually the right answer. It's almost never the answer the first vendor on the call gives.
If you run a field service business and want a second opinion that isn't trying to sell you a product, send us a note. We'll tell you when to buy, when to build, and when to do nothing — and we lose work both ways often enough that we mean it.
Sources: