CRM for service businesses: tickets, SLAs and field teams
What should you know about service CRM development for businesses with tickets, SLAs and field teams?
Service CRM links tickets, SLAs, schedules and field apps so a customer issue moves from call to closure without re-keying. The build centres on the installed asset rather than the contact, runs SLA clocks automatically, and gives technicians an offline-capable app so closure and parts data come from the field.
Service CRM development is about one flow: a customer reports a problem, it becomes a ticket with an SLA clock, a technician is scheduled, the visit happens, parts are used, the ticket closes, and the customer and the contract both reflect it, with nobody typing the same thing twice. Most businesses that maintain equipment, run facilities, or provide on-site support do this across a helpdesk tool, a scheduling spreadsheet, a WhatsApp group of technicians and an accounting package, and re-key at every hand-off. This article sets out what a service management system must do, why the asset or contract rather than the contact is the central object, and how the field app makes or breaks the whole thing.
Why sales CRMs and helpdesks do not fit service businesses
A sales CRM models a contact at a company moving through a pipeline. A helpdesk models a ticket with a queue. A service business needs both, plus objects neither has: the installed asset with its history, the contract that defines what the customer is entitled to, the SLA that starts a clock when a ticket opens, the technician with skills and a location, and the parts consumed on a visit. Bolting these onto a helpdesk produces custom fields nobody maintains; bolting them onto a sales CRM produces a pipeline that does not mean anything. The decision logic is set out in custom CRM versus off the shelf; service businesses score high on the object-model and integration signals, which is why hybrid or custom builds are common. TheEazy CXM, our sister product, covers the customer-facing ticket side for many; the asset, contract and field layers are where custom work concentrates.
Service management software: the modules and their links
| Module | What it must do | What it feeds |
|---|---|---|
| Customer, site and asset | Customers with multiple sites; installed assets with serials, warranty, install date, service history | Ticket context; contract entitlements; parts compatibility |
| Contracts and entitlements | AMC and warranty terms, covered assets, visit allowances, response and resolution SLAs by priority | SLA clocks; billing for out-of-contract work |
| Ticket intake | Phone, email, WhatsApp, portal and IoT alerts into one queue; auto-link to asset and contract; priority rules | Scheduling; SLA tracking |
| SLA tracking | Response and resolution clocks per ticket, paused for customer waits; escalation before breach | Manager alerts; contract reporting |
| Scheduling and dispatch | Assign by skill, location, availability and SLA; route the day; reschedule on the fly | Technician app |
| Field technician app | Day's jobs, checklists, photos, parts used, customer sign-off, offline capture | Closure; parts consumption; invoicing |
| Parts and invoicing | Van stock, parts requests, consumption against tickets, chargeable versus covered work, invoice generation | ERP or accounting integration |
The asset is the centre, not the contact
Every ticket is about something: a lift, a chiller, a printer, a solar inverter, a network switch. When the asset is the central object, the ticket inherits its site, its contract, its history and its likely parts. The technician arrives knowing the last three visits and what was replaced. Managers can see which assets consume disproportionate visits and which contracts are unprofitable. When the contact is the centre, none of that exists and the technician rings the customer from the car park to ask what the problem is. This choice is settled first in scoping.
SLA tracking CRM: clocks that run themselves
SLA tracking fails when it depends on people updating statuses. The clock must start when the ticket is created, run against the priority and contract terms, pause automatically when the ticket is waiting on the customer, and alert the right person before the breach rather than after. Response and resolution are separate clocks. Business hours and holidays come from the contract, not a global setting, because a hospital's 24×7 cover and an office's business-hours cover are different products. Breach reporting per contract is what the account manager needs at renewal, and it is only credible if the clocks ran without manual intervention.
Escalation that reaches a person
An escalation rule that sends an email to a shared inbox is not an escalation. Escalations go to a named person by WhatsApp or push notification, with the ticket, asset and remaining time, and they are acknowledged. If not acknowledged within a set time, they move up. The discipline is in making them reach a phone.
Field service CRM: the technician app
The technician app is where the service CRM succeeds or fails, and the rules are the same as for any field app: fast, offline-capable, and asking for as little as possible. The day's jobs in order, navigation to the site, the asset's history, a checklist for the job type, photos before and after, parts used from van stock with a barcode scan, the customer's signature or OTP, and a close. Every capture is stored locally and synced when there is signal, without duplicates. The technician should be able to complete a routine job in the app in under two minutes of interaction; anything more and the WhatsApp group returns. We built the dispatch platform and offline-first driver app on the same principles for a logistics operator, and the in-app copilot for a field-service SaaS shows how AI assists a technician in the app itself.
Where AI removes work in a service CRM
Three places. First, ticket intake: an AI pipeline reads emails, WhatsApp messages and voice notes, identifies the customer, site and probable asset, drafts the ticket and sets a suggested priority, with the coordinator confirming rather than typing. Second, technician assistance: a copilot in the app answers questions from manuals and the asset's history, and drafts the visit report from the checklist and photos. Third, auto-logging: calls with the customer are summarised onto the ticket, so the history is complete without anyone writing it. Each runs in shadow mode first and inside policy; the AI never closes a ticket or promises a visit time on its own. The design of the logging layer is in auto-logging: AI that keeps your CRM data complete.
Parts, invoicing and the ERP boundary
Parts used on a visit are the link between service and money. The app records consumption against the ticket from van stock; the system decides whether the work and parts are covered by contract or chargeable; chargeable work produces an invoice with GST e-invoicing handled as described in GST and e-invoicing integration. Stock replenishment and the ledger belong to the ERP or accounting package, integrated by API. Keeping that boundary clear avoids building a second inventory system inside the CRM.
A worked example
A company maintaining HVAC and electrical equipment across commercial sites in several cities ran tickets in a helpdesk tool, scheduling in a spreadsheet, technicians on WhatsApp and invoicing in an accounting package. SLA breaches were discovered at contract review; parts used were reconstructed from memory at month end. The build put the asset and contract at the centre, with the helpdesk retained for customer email and integrated so tickets carried asset context. SLA clocks ran from contract terms with escalation to area managers by WhatsApp. Scheduling considered skills, location and remaining SLA time. The technician app went live with one city first, offline-capable, with parts scanned from van stock and customer sign-off on the phone. Chargeable work flowed to the accounting package as invoices. Coordinators stopped ringing technicians for status, month-end parts reconciliation became a report, and contract renewals came with breach data the account managers could defend.
Team and timeline
A service CRM build needs a product lead who has spent a day with technicians and a day with coordinators, two engineers, a mobile engineer for the technician app, a designer for the dispatch board and app, and on the client side a service head for process decisions and an operations coordinator who will own data quality. Asset and contract data must be cleansed before phase one.
Scope and phases are fixed in a Sprint Zero at $3,250 / ₹2,00,000, credited to the build. ERP and CRM development starts at $28,000 / ₹18.4L for phase one; the technician app is a React Native mobile module from $17,500 / ₹11.2L; AI intake and copilot features follow as a SaaS copilot module from $19,500 / ₹12.8L. Phase one, covering assets, contracts, tickets and SLAs, typically goes live in eight to ten weeks, with the app and scheduling in the next phase. The pricing page lists Care Plans; businesses with 24×7 contracts usually take the Standard or Enterprise plan.
Before you start: a checklist
- Inventory the installed assets with serials, sites and current contracts
- Write down every contract type and its response and resolution terms by priority
- List all ticket intake channels and their current volumes
- Define escalation paths with named people, not shared inboxes
- Audit technician devices and connectivity at typical sites
- Decide the boundary with the ERP or accounting package for parts and invoicing
- Agree which city or team goes live first and how the parallel run is reconciled
- Set the first management metric: SLA attainment by contract
Glossary
- AMC: annual maintenance contract, defining covered assets, visits and SLAs
- Response SLA: the time by which a technician must acknowledge or arrive after a ticket opens
- Resolution SLA: the time by which the issue must be fixed, often paused for customer waits
- Van stock: parts carried by a technician, consumed against tickets and replenished from stores
- Entitlement: what a contract covers: assets, visit counts, parts, hours
- Offline-first: an app that stores actions locally and syncs when connectivity returns
Related reading
See AI in CRM: what a copilot should do for sales and service teams, agent assist and our custom enterprise software service. For designing the technician app, the Nielsen Norman Group's research on mobile usability is the primary reference we use for interaction budgets in the field.
Centre the system on the asset, let the SLA clocks run themselves, and build the technician app as if the whole project depended on it, because it does.
Frequently asked questions
What does service CRM development cost?
▾
Phase one under ERP and CRM development starts at $28,000 / ₹18.4L, with the technician app from $17,500 / ₹11.2L as a separate module. A ten-day Sprint Zero fixes the exact scope and price.
Can we keep our existing helpdesk?
▾
Often yes. Keep it for customer-facing email and portal tickets, and integrate it so each ticket carries asset, contract and SLA context from the custom system. The field app and scheduling are built custom.
How do SLA clocks handle 24×7 contracts and holidays?
▾
Business hours and holidays are attributes of each contract, not a global setting. Clocks run against the contract's terms, pause for customer waits, and escalate to named people before breach.