Nearly every field-service business in India runs on a WhatsApp group, and anyone who sneers at that has never run one. It is instant, it costs nothing, every technician already has it, and it needed no training, no rollout and no consultant. Software that wants to replace it should start by admitting it is competing with something genuinely good.
The honest question is not whether WhatsApp is bad. It is when it stops being enough — and that moment is not about how many customers you have. It is about how much your team can still hold in their heads.
What WhatsApp dispatch gets right
Be fair about this, because the failure mode of most software rollouts is contempt for the thing being replaced.
- Zero adoption cost. Nobody has ever needed to be taught WhatsApp. Nobody forgets their password.
- Instant and two-way. A dispatcher can send a job and get a reply in twenty seconds from a man on a scooter.
- Rich by default. A photo of a nameplate, a voice note describing a noise, a location pin — all in one thread, all effortlessly.
- Universal. Customers are already there. So are your suppliers, your karigars, your landlord.
- Works on a weak network in a basement, which is more than can be said for a lot of enterprise software.
For a two-van operation where the owner personally knows every customer, WhatsApp plus a diary is not a compromise. It is close to optimal, and swapping it for a system nobody wanted is how small firms end up worse off with a monthly bill attached.
The failure modes: no state, no history, no accountability
WhatsApp's problem is not that it is a chat app. It is that a chat is a stream, and dispatch is a set of things with states. Those two shapes do not fit.
A job has a state — open, assigned, in progress, completed. A chat has only chronology. So the question "what is still open right now?" cannot be answered by looking at anything; it can only be answered by scrolling and reconstructing, which is a task whose difficulty grows with your success. At four technicians the reconstruction takes a minute. At twelve it is a full-time job, and that is the actual reason firms hire a coordinator whose entire role is remembering.
- No state: nothing tells you which jobs are open, which are unassigned, and which have been sitting untouched since Tuesday.
- No ownership: a job posted to a group belongs to everyone, which means it belongs to nobody until someone claims it.
- No history you can retrieve: last year's visit to that machine is in the thread, technically, along with forty thousand other messages.
- No handover: the technician who leaves takes his chat and his context with him.
- No escalation: nothing gets louder because it is late. A message from Monday looks exactly like a message from an hour ago, only further up.
- Silent search failure: you can search for a word, not for "every job at this site in the last two years".
The group chat scales perfectly until the day one person can no longer hold the whole board in their head. That day arrives without an announcement.
Where the customer's asset history is supposed to live
The deepest cost of chat-based dispatch is not disorder. It is that you are throwing away the most valuable thing your business generates.
Every visit produces knowledge: this machine, at this site, had this fault, and this fixed it. Accumulated over five years across a few hundred assets, that is a genuine competitive asset — it is the reason your technician diagnoses in ten minutes what a competitor takes an hour to find. In a chat thread, that knowledge exists for about two weeks and then is effectively gone.
The right home for it is the asset itself: the unit at the customer's site, with its serial number, make, model, install date and warranty, carrying its own service history. Jobs hang off that asset. So do preventive visits and reminders. Then the history is not a memory, it is a record — and a new technician on his first day at that site is as informed as the man who has been going there for four years.
Billing from a chat thread, and the invoices never raised
Ask an owner running on WhatsApp whether he thinks some completed work never gets billed and he will say probably a little. Then ask his accountant. The gap is always larger than the guess, and it is structural rather than dishonest.
The path from work to money has too many handoffs. The technician finishes, sends a message, and moves on. In the evening somebody reads the day's messages and writes what happened into a book. At month-end somebody else turns the book into invoices. Every one of those steps drops things — the extra part fitted on site, the second visit, the small chargeable job done for an AMC customer as a favour that was never a favour, just uninvoiced.
Close the loop instead and the leak stops. Service and part lines go onto the job as work happens, so the job already contains what it is worth. A gap-free numbered GST invoice with the CGST/SGST split is generated from those lines rather than typed from a notebook. A Razorpay-secured UPI pay-link goes to the customer while the fix is still fresh, and the dues board shows what is outstanding without anybody adding up columns. The work and the bill stop being two separate acts of memory.
What to look for in field service software, in order of value
Most buying decisions in this category go wrong the same way: the buyer is shown a map with moving dots, is impressed, and buys a product that does not do the four things that would actually have made money. Judge in this order.
- Jobs with real states. Open, assigned, in progress, completed, against a site and an asset, with service and part lines. If the software cannot answer "what is open right now" on one screen, nothing else matters.
- Sites and assets. Customer, then premises, then the specific unit — with serial, make, model, install date, warranty and history. This is the layer that makes everything above it useful.
- AMC contracts with preventive visits laid across the term. Recurring revenue is the reason to buy, and unscheduled visits are the reason it leaks.
- Spare parts with live stock, auto-deduction when a part goes onto a job, and low-stock alerts. This is where both margin and second visits hide.
- Billing that comes out of the job — GST invoice, tax split, pay-link, dues board — instead of a separate typing exercise.
- Reports you would actually open: jobs by status, visits due, the AMC roster, parts stock, outstanding invoices.
Notice what is not at the top. Live GPS tracking, elaborate route optimisation and a customer app are fine things, and none of them fixes a business that cannot say what is open. Buy the boring layer first.
Technician adoption: the feature that decides success
Every failed rollout in this category failed at the same place. The office adopted the software and the field did not, so the group chat carried on in parallel and the system held a partial, misleading version of reality — which is worse than no system, because now you trust a screen that is wrong.
Field staff are not resisting change out of stubbornness. They are on a bike in the sun with a customer waiting, and they will use whatever is fastest. If updating a job takes longer than sending a WhatsApp message, WhatsApp wins, permanently and correctly.
- Judge every screen by how it feels standing up, one-handed, on a patchy network.
- Adding a part must be as fast as saying it aloud. Same for closing a job.
- Do not ask the field for data the office wants and the technician gets nothing from — that is the fastest way to teach people to enter garbage.
- Run one crew for two weeks before the whole team. Fix what annoys them, then expand.
- Keep WhatsApp for talking. It is a superb conversation tool. It was never a system of record.
That last point is the one that gets rollouts over the line. Nobody has to give up the group. They have to stop using it as the only place a job exists.
AMCs and recurring revenue as the buying case
If you need one reason to move off chat that a spreadsheet can be built around, it is the AMC book. Breakdown work is unpredictable and gets forgotten quickly. Contract work is known a year in advance, which makes it the only part of the business you can genuinely plan — and the only part that can be lost through pure administrative neglect.
Contracts built from service plans, with preventive visits auto-laid across the term, mean every visit you sold exists as a dated, assignable row. Automatic service, renewal and warranty-expiry reminders mean repeat work stops depending on a customer remembering to call you. And an optional UPI AutoPay mandate on the contract means the renewal collects on the due date instead of becoming a chase.
Do that arithmetic on your own numbers before you look at any demo. Count the contracts that lapsed last year without anyone noticing, and the visits you sold but did not deliver. That figure is the business case, and it is usually not close.
Rolling it out in one region first
Do not migrate everything. Pick one branch, one city or one crew, and run it properly for three or four weeks alongside the existing chat. Enter the customers, sites and assets for that region only — a hundred assets entered accurately beats two thousand imported badly, and the second option poisons trust in the data on day one.
- Week one: customers, sites and assets for one region, entered by hand and checked.
- Week two: every new job for that crew opens in the system, even the ones that arrive by phone.
- Week three: parts go onto jobs, and invoices are generated from jobs rather than typed.
- Week four: load the AMC contracts for that region and let the preventive visits lay themselves out. This is the week the value becomes obvious to the owner.
- Only then decide whether to expand — and let the crew who tried it explain it to the next one.
WhatsApp is not the enemy. Running your business as a stream of messages, when it is actually a set of assets with states and dates and money attached, is the enemy. Keep the chat. Give the jobs a home.