Field Service vs CMMS: Which Do You Need?

I get asked this question in roughly the same shape every few months. Someone is running a maintenance or service operation, they have outgrown spreadsheets and a shared inbox, and they have two shortlists in front of them that overlap confusingly. One list is field service platforms. One list is CMMS products. Both sets of demos showed a work order, a calendar, a mobile app and a parts list. Both salespeople said their product could do what the other one does. The buyer cannot tell which category they are actually in, and that is a genuinely reasonable place to be stuck, because the marketing language of the two categories has converged even though the software underneath has not.

The message up front: a CMMS is built around assets you own and maintenance you perform for yourself. A field service platform is built around jobs you deliver for customers at their sites. Every other difference, billing, contracts, scheduling logic, who the "customer" record even is, follows from that one distinction. Work out which side of it your revenue sits on and the shortlist resolves itself in an afternoon.

1. The one question that settles it

Before any feature comparison, answer this: when a job is finished, does someone outside your organisation receive an invoice for it?

If yes, you are in field service. The job is a unit of delivered revenue. It has a customer, a site that you do not own, a contract or a quote behind it, a price, and a paper trail that has to survive a client dispute. The software's job is to get the right engineer to the right customer site, capture proof of what was done, and turn that into money.

If no, you are in maintenance management. The job is a unit of cost against an asset on your own balance sheet. It has an equipment record, a failure history, a preventive schedule, a cost centre and a budget line. The software's job is to keep your estate running at the lowest sensible total cost and give you the reliability data to prove it.

That is not a simplification I use to move a conversation along. It is the actual architectural divide. The two product categories were written by different people solving different problems, and the data model each one starts from tells you everything about what it will be good and bad at. If you want the broader map of the maintenance-software categories first, the four-way boundary between CAFM, CMMS, EAM and IWMS is drawn out separately and I will not redraw it here. This article sits at a different seam: the one between maintaining your own estate and delivering service to somebody else's.

2. The data-model difference, which is the whole thing

Open the entity model of a mature CMMS and the object at the centre is the asset. Everything hangs off it: location, hierarchy parent, asset class, criticality, meter readings, PM schedule, failure history, bill of materials, warranty. A work order is fundamentally a child of an asset. You cannot really have a meaningful work order in a CMMS that is not attached to something in the equipment register, and if you try, you have broken the reporting.

Open the entity model of a field service platform and the object at the centre is the job, with the customer account above it. The chain is account, then site or service location, then contract or agreement, then job, then the engineer visit, then the billable lines. Assets exist, but they are usually attributes of the customer site rather than the spine of the system. In many FSM products the "asset" is a lightly modelled thing: a serial number, a model, a warranty end date, maybe a service history. It exists so the engineer knows what they are looking at, not so a reliability engineer can analyse a fleet.

Read that table twice, because it is the argument. Nothing in it is a feature gap that a vendor can close in a release. These are different spines. A product built with the job and the account at the centre can bolt on an asset register, and it will be serviceable, but it will not give you a five-level location hierarchy with criticality-weighted PM compliance reporting. A product built with the asset register at the centre can bolt on a customer field, and it will be serviceable, but it will not price a job, apply a contract discount, calculate travel-inclusive billing and produce a client-facing invoice.

3. Who is the "customer", and why that word breaks conversations

A surprising amount of confusion in these selection projects comes from the word customer meaning two different things to the two sets of people in the room.

In an in-house maintenance operation, the customer is internal. It is the production line supervisor whose conveyor stopped, the tenant whose air conditioning is failing, the clinical department waiting on a medical gas repair. The relationship is real and service quality matters, but no invoice crosses a company boundary. The CMMS models this as a requester: a name, a department, a cost centre, sometimes a chargeback code. That is all it needs, because nobody will litigate the response time.

In a service business, the customer is an account with a contract, a credit limit, a billing address, a purchase order number, a rate card, negotiated response times and a commercial relationship that can be lost. The FSM platform models this heavily, because if the customer record is thin the business cannot invoice correctly or defend its SLA performance.

This is why "our CMMS has a customer field" is not the reassurance it sounds like. A field is not a model. Ask instead: can the system hold a rate card per account, apply contract entitlements to determine whether a job is chargeable or covered, and produce an invoice that a client's accounts-payable department will accept? If not, the customer field is a label, not a capability.

4. Billing: the capability CMMS products usually do not have

If there is one hard dividing line, it is this. Field service platforms must be able to bill. Maintenance management systems usually cannot, and in most cases were never intended to.

Billing in a service business is not a single feature. It is a chain of capabilities that has to work end to end, and a gap anywhere in it means the finance team goes back to spreadsheets:

• Rate cards and price books, per customer or per contract, with different labour rates for standard hours, out of hours, callout and specialist skills.
• Chargeable versus covered determination: the same job is free under a maintenance agreement, billable at full rate for a non-contract client, and billable at a discount for a contract client whose entitlement has been used up. The system has to decide this, not a person.
• Time capture that survives an argument: engineer arrival and departure timestamps, travel separated from on-site time, with the detail a client will ask for when they query the line.
• Parts sold at price, not issued at cost, with markup rules and the audit trail from van stock to invoice line.
• Quotes and variations: the engineer finds additional work, raises a quote from the mobile app, the client approves, the scope and the price both change.
• Progress and milestone billing for installation or project work that spans weeks.
• Clean handoff to the finance system, whether that is an ERP, Business Central, or an accounting package, with no re-keying.

A CMMS captures the raw ingredients of most of this, because it tracks labour hours and parts consumption. What it does not do is price them, apply commercial terms, or produce a document you can send to a client. Some enterprise EAM products have a service-billing module, and if you already run IBM Maximo or Infor EAM at scale that is worth investigating before you buy a second platform. But for the mid-market CMMS tier, MaintainX, Limble, Fiix, UpKeep, eMaint, billing a customer is simply not what the product is for, and asking it to is how you end up with an implementation that both teams resent.

5. Contracts and SLAs: against a client, or against yourself

Both categories talk about SLAs, and both mean something real, but they are structurally different objects.

In an in-house maintenance operation, the SLA is an internal target. Priority one responded within two hours, priority three within five working days, PM compliance above ninety percent. Missing it produces a difficult conversation and a corrective action. It does not produce a financial consequence, and nobody outside the organisation audits the evidence.

In a service business, the SLA is a clause in a signed agreement. It has response and resolution windows defined per priority and often per asset class, exclusions, business-hours definitions, allowances for client-caused delay, and a credit or penalty regime when it is missed. The client's own team will measure it independently and will challenge the numbers. That changes the software requirement entirely: the platform has to stop and start clocks accurately, hold the pause reasons, keep the evidence, and produce a performance report that survives scrutiny in a contract review meeting.

The contract object itself differs too. A CMMS contract record usually means a supplier contract: the lift maintenance company we engage, their scope, their expiry, their rates. An FSM contract record means a customer agreement: what we owe this client, how many visits are included, what is covered, what the escalation path is, when it renews, what it is worth. Same word, opposite direction of obligation. The SLA matrix design pillar covers how to structure the priority and response grid itself, and the AMC and maintenance contract management pillar covers the annual-contract mechanics that dominate service businesses in this region.

6. Scheduling: travel and skills, versus plant availability

Scheduling is where the two product families diverge most visibly, and it is the difference people notice first when they try to use the wrong tool.

CMMS scheduling optimises around the asset and the plant. The binding constraints are when the equipment can be taken out of service, when the shutdown window opens, whether the permit to work and the isolation are in place, whether the production schedule allows access, and how to level a year of PM workload so it does not all fall in one month. Geography is barely a factor because the technicians and the assets are on the same site. The planner's skill is sequencing work into availability windows and balancing the PM calendar.

FSM scheduling optimises around the engineer and the map. The binding constraints are drive time between appointments, which engineer holds the licence or manufacturer certification for that equipment, what parts are on which van, the appointment window promised to the customer, the SLA clock already running, and how to reoptimise the whole day when a priority-one callout lands at eleven in the morning. This is a genuinely hard combinatorial problem, and it is why FSM vendors invest heavily in routing and dispatch engines. A CMMS has no reason to solve it and generally has not.

Try to run a multi-site reactive service business on a CMMS scheduler and you will discover the gap within a month: there is nowhere to put travel time, no way to see the day on a map, no automatic reshuffle when an emergency arrives, and no skills-matching beyond a trade code. Try to run a refinery turnaround on an FSM dispatch board and you will discover the mirror-image gap: nowhere to model the isolation dependency, no shutdown window, no permit linkage, no PM workload levelling across a twelve-month horizon.

The work order taxonomy itself differs, which is worth being deliberate about during configuration. The work order types pillar sets out the maintenance-side taxonomy; on the service side you also need job types for installation, commissioning, survey, quoted remedial and warranty claim, which are commercial categories rather than maintenance ones.

7. Mobile: both need it, for different reasons

Neither category is viable without a decent mobile application, so mobile is not a differentiator in itself. What it is used for differs sharply, and comparing the apps against the wrong checklist is a common selection error.

One overlap deserves emphasis because it is the single most common cause of technician rejection in both categories: offline capability. Not "degraded offline mode with a sync warning", genuinely offline, with a queue that reconciles cleanly and does not lose a completed job. Test this properly during evaluation, with the device in airplane mode, completing three jobs and then reconnecting. I have watched more mobile rollouts fail on sync reliability than on any user-interface complaint.

8. The organisations that genuinely need both

Most organisations need one of the two. A minority genuinely need both, and it is worth being precise about which minority, because "we need both" is also the most common way a selection project doubles its budget for no benefit.

You genuinely need both when you have two distinct operations under one roof:

• A manufacturer that also services what it sells. The plant maintenance operation needs a CMMS or EAM around its own production assets. The aftermarket service division needs FSM around customer-owned installed base, warranty claims and service contracts. These are different departments with different P&L treatment, and forcing them into one system serves neither.
• An FM service provider with its own estate. Covered in detail in the next section, because it is the most common genuine case.
• A utility or infrastructure operator with a chargeable connections business. The network assets sit in an EAM. New connections, metering visits and chargeable customer work sit in FSM, because they are billable jobs at customer premises.
• A large landlord or developer that also sells maintenance services to third parties. The owned portfolio needs CAFM. The third-party service book needs FSM billing and contract management.

You do not need both when you have one operation and somebody has mistaken a feature gap for a category gap. An in-house maintenance team that wants better technician routing does not need an FSM platform; it needs a CMMS with a decent planner and a sane work order flow. A small service company that wants asset history on its customers' equipment does not need a CMMS; it needs to use the installed-base module of its FSM product properly.

9. The FM service provider case, in detail

This is the scenario I am asked about most, and the one where the answer is genuinely "both", so it deserves working through properly.

A facilities management contractor holds maintenance contracts across a portfolio of client buildings. They employ mobile and static technicians. They are measured on contractual SLAs with penalty regimes. They invoice monthly against contract value plus additional works. And, critically, they are often contractually obliged to maintain an asset register for each client building, because the client wants the asset data and the lifecycle record, and frequently wants it handed back at contract end.

That combination creates two irreducible requirements. The commercial one is pure field service: multi-client contracts, entitlement checking, SLA clocks with client-specific business hours, billable additional works, engineer routing across a city, and invoicing that reconciles to contract value. The technical one is pure CAFM or CMMS: a per-building asset register with hierarchy and criticality, statutory compliance schedules, PM regimes derived from a standard such as SFG20 , condition data and lifecycle replacement planning.

Larger providers solve this in one of three ways, and I would rank them in this order:

• A CAFM platform with genuine multi-client and commercial capability. The FM-specific enterprise products, Planon among them, were built for exactly this shape and handle multi-client contracts, SLA regimes and additional-works billing natively alongside a full asset register. If the product genuinely does both, one system is the right answer and the integration problem disappears. Validate the billing chain hard, because this is the claim most often overstated.
• FSM for delivery, CAFM or CMMS for the estate, integrated. Two best-of-breed systems with a clean boundary. More capable on each side, and the pattern I would choose where the service book is large and the asset data obligations are heavy. It costs you an integration to build and maintain, and it requires the discipline to keep the boundary rule.
• FSM alone, with per-client asset registers kept lightly. Workable for smaller providers whose contracts do not demand deep asset data. It becomes untenable the moment a client asks for condition surveys, lifecycle forecasts or a compliance audit trail across five years.

The pattern I would actively discourage is CMMS alone with billing done in spreadsheets, which is where a surprising number of mid-sized providers sit because the CMMS was bought when they had four contracts. For the FM-operation view of the CMMS side specifically, see CMMS for facilities management; for the FSM side as a discipline, the field service management practitioner's guide covers the operating model in full.

10. Decision table by organisation type

This is the table I would put in front of a steering committee. Find the row that matches the organisation and start there. Treat the recommendation as a strong default rather than a rule, and only depart from it if you can name the specific reason.

If your organisation appears in a "both" row, read that as permission to buy two systems only after you have written down the boundary and the integration scope. If it appears in a single-system row, the honest advice is to stop shortlisting the other category, because carrying both shortlists to a final round doubles the evaluation effort and usually produces a compromise choice that is weak at both jobs. The CAFM, CMMS or EAM selection guide narrows the maintenance-side choice once you know you are on that side, and how to choose field service management software does the same on the service side.

11. Integration patterns when you run both

Assume you have concluded you need both, and you have accepted the boundary rule. The integration then has a small number of workable shapes. I would choose between them on how much asset depth the service operation actually needs in the field.

• Pattern A: asset reference sync, one way. The CMMS or CAFM is the master of the asset register and pushes a read-only subset, asset ID, description, location, criticality, to the FSM platform so jobs can be tagged to a real asset. Job outcomes flow back as history records against the asset. This is the lightest pattern, covers eighty percent of cases, and is where I would start.
• Pattern B: work order handoff. PM work generated by the CMMS schedule is pushed into FSM for dispatch and mobile execution, and the completion, labour, parts and readings flow back to close the CMMS work order. Useful where the PM regime is genuinely owned by the estate system but the delivery workforce lives in FSM. The integration is bidirectional and needs careful status mapping, which is the part teams underestimate.
• Pattern C: financial roll-up only. The two systems stay largely independent and meet in the finance layer: FSM invoices out, CMMS reports cost, and both post to the ERP or accounting system. Appropriate where the two operations genuinely do not share assets, such as the manufacturer-with-service-arm case.
• Pattern D: shared master data hub. Customers, sites, employees, skills and parts are mastered centrally, often in the ERP, and both systems consume them. Worth the effort only at genuine enterprise scale, where master-data drift between systems has already caused a real problem.

Whichever pattern you choose, a few implementation rules save a great deal of pain. Nominate a single master for every shared entity and write it down. Integrate on stable identifiers, never on names or descriptions. Map statuses explicitly, including the awkward ones such as on hold awaiting parts and awaiting customer access, because that is where the reconciliation breaks. Build the integration with an error queue and somebody whose job it is to clear it, since an unmonitored integration silently diverges and you will discover it during a client audit. And resist the temptation to sync everything: every additional synchronised field is a permanent maintenance obligation.

The idea to walk away with

A CMMS is for assets you own. A field service platform is for jobs you deliver. That single distinction generates every other difference: what sits at the centre of the data model, who the customer record represents, whether the system captures cost or revenue, whether contracts point inward at suppliers or outward at clients, and whether the scheduler optimises around plant availability or around travel and skills.

Feature-by-feature comparison will not resolve this, because the categories have converged on surface features while remaining structurally different underneath. Ask the revenue question first, pick the category, then compare products within it. And if the honest answer is that you have two operations, buy two systems deliberately, with the boundary written down before the contracts are signed: FSM owns delivery, the CMMS or CAFM owns the estate record.

Final thoughts

The expensive version of this mistake is rarely dramatic. Nobody discovers in week two that they bought the wrong category. What happens instead is that the finance team quietly builds a spreadsheet to do the invoicing, or the engineering team quietly builds a spreadsheet to hold the asset hierarchy, and everyone lives with it because the system is already paid for. Two years later those spreadsheets are the real system of record and the platform is a data-entry chore. That is what choosing the wrong centre of gravity looks like in practice.

So spend the time on the question rather than the shortlist. Map where your work actually comes from, who receives the output, and who pays for it. Then test the one thing the other category cannot do, billing for FSM, asset depth and PM compliance for CMMS, and test it live with your own data rather than the vendor's demo dataset. If you get that right, the rest of the selection is comparatively ordinary work. For shortlisting mechanics once the category is settled, the CMMS shortlisting guide and the CAFM buyer comparison both set out a scoring approach you can reuse on either side of the divide.

Related reading: Field service management: a practitioner's guide, CAFM vs CMMS vs EAM vs IWMS, What is a CMMS: a complete buyer's introduction, CMMS for facilities management, Which of CAFM, CMMS or EAM is right for you, How to choose field service management software.