Twelve sectors. One system, set up differently.

What every regulated sector needs, whatever the industry

Sector pages tend to overstate difference because difference is what sells. In practice, the operations on this page share more than they differ, and the shared part is where most of the value sits.

• Competency enforced at assignment. Whether the ticket is a trade licence, a high-voltage authorisation, a confined space entry or an equipment-class certification, the requirement is identical: the system must know what the job needs and what the technician holds, on the day.
• Evidence produced as a by-product. Every sector here is audited by someone: a regulator, a customer, an insurer. The operations that cope are the ones where the record is created by doing the work rather than assembled afterwards.
• Asset history that outlives people. The technician who knows this installation leaves, retires or is on leave when it fails. What they knew has to be on the asset.
• Work that survives poor connectivity. Plant rooms, basements, remote sites, tower bases. Offline is the normal condition, not an edge case.
• Planned work competing with unplanned. Every sector on this page runs a maintenance programme that is repeatedly interrupted by failures, and needs to see what was displaced.

If a vendor's sector story does not start from these, it is marketing rather than product.

When a vertical product is worth buying

There is a real argument for industry-specific software, and it is worth stating fairly rather than dismissing.

A vertical product is worth it when the regulatory model is genuinely unusual and deeply embedded: where the compliance workflow is the product rather than a configuration of it. It is also worth it when the vendor's domain knowledge shortens your own thinking, which is a real benefit even when the software is ordinary.

Against that: vertical products are smaller, which usually means slower development, fewer integrations and a harder time hiring people who know them. And the boundaries are rarely as clean as the categories suggest. An operation servicing medical equipment inside manufacturing plants belongs to two verticals and is well served by neither.

Configuration you can change beats a vertical edition you cannot.

Our position, stated plainly because it is a commercial position and you should weigh it as one: for most enterprise field service, configuration you control beats a vertical edition you cannot, because the thing that actually varies between sectors is narrow and configurable.

What actually changes between sectors

Having argued that sectors are more alike than different, it is only fair to be specific about where they genuinely diverge.

• Which forms attach to a job. An isolation certificate, a calibration record, a permit to work, a commissioning sheet. Same mechanism, different content.
• What qualification gates the work. The list differs by sector and jurisdiction; the enforcement is identical.
• How the asset is identified. Serial numbers in device service, network structures in power, customer premises equipment in telecom, plant tags in manufacturing.
• The shape of a job. Same-day rounds in telecom, multi-day trips in oil and gas, programme-linked work in construction.
• Who the audience for evidence is. A regulator, a customer, an insurer, or an internal quality function, which changes what the record must show, not whether it must exist.

Enterprise field service is a different problem from trades

The term field service management covers two markets that share vocabulary and almost nothing else, and buying software built for the wrong one is a common and expensive mistake.

Residential and trades work is high volume, short duration, single-site and largely self-contained. The software optimises booking density, quoting speed and payment on the day. Products in this space are excellent at that and reasonably priced for it.

Enterprise field service is lower volume, longer duration, multi-site and contractual. The complexity is in entitlements, competency, asset history, evidence and multi-region coordination. The pages linked from here are about that second problem.

If your work is closer to the first description, we would rather tell you now than eight weeks into an evaluation.

What changes at scale

Requirements that are irrelevant at forty technicians become decisive at four hundred, and they are the ones most often discovered late.

• Multi-entity structure. Separate legal entities, currencies and tax treatments under one operational picture, without running four systems.
• Permission granularity. Who can see commercial terms, who can override an assignment, who can amend a signed record. At scale these stop being conveniences.
• Cross-region resourcing. The ability to lend a technician across a boundary without a negotiation between coordinators is the difference between a network and a set of depots.
• Reporting that survives inconsistent definitions. If regions record differently, group reporting is fiction. Enforcing definitions at capture matters more than the reporting tool.
• Change management. A form change across four hundred technicians needs versioning, staged release and a record of who was working to which version.

None of these are visible in a demo built around a single region, which is why it is worth insisting the demo includes two.

Mixed operations, which is most of them

The twelve sectors on this page are presented separately because that is how buyers search. Real operations are rarely so tidy, and the mixed case is worth addressing directly because it is the one a vertical product handles worst.

A contractor maintaining building services inside a hospital is doing construction-shaped work under medical-grade compliance. A telecom operator running its own power infrastructure spans two of these pages. A manufacturer servicing its own installed base at customer sites is running an enterprise field service operation that no manufacturing product is built for.

In each case the requirement is the same platform with two configurations (different forms, different qualification sets, different evidence obligations) against one set of customers, assets and technicians. Splitting that across two systems creates a reconciliation problem that costs more than either system saves.

Running a sector-specific evaluation

If you are evaluating with a particular sector in mind, generic demos will not tell you much. These are the scenarios worth insisting on.

• Bring your worst job type. Not the routine one. The job with the permit, the two qualifications, the part that is never in stock and the customer who disputes the invoice. Ask them to run it end to end.
• Bring a real compliance form. One of yours, with its conditional logic and its blocking conditions. Watch how long it takes to build and who has to build it.
• Bring a competency scenario. A technician whose certification expires between scheduling and attendance. Ask what the system does.
• Bring an audit question. Pick a visit from your own history and ask them to show how they would produce the full evidence chain for it.
• Bring your integration. The system that owns your finance or your parts, and ask specifically what passes and what happens on rejection.

Five scenarios, run properly, tell you more than a hundred-line feature matrix. They also tend to reveal quickly which vendors have deployed in work like yours.