Field Service CRM Where the Customer Record Is the Job History
Most CRMs were built for sales teams: a pipeline, an opportunity, a deal that closes. Field service works the other way round. The relationship usually starts after the sale, most of the value is in repeat work, and the record that matters is not the contact — it is the site, the equipment on it, and everything that has been done there before.
Running this manually today?
See how Fieldproxy handles it — a walkthrough on your own workflow, not a canned demo.
Book demoWhat a field service customer record has to hold
- Sites underneath the customer, because a customer with eleven buildings is eleven different operational realities
- Assets and equipment at each site, with their own history, warranty and access notes
- Full service history, visible to the engineer on arrival rather than to the office afterwards
- Contracts and agreements, what they cover and when they renew
- Commercial terms — rate cards, payment terms, purchase-order requirements
- The awkward facts: which engineer not to send, which gate code, which contact actually authorises work
Why a sales CRM bolted onto service disappoints
When the CRM and the job system are separate, the customer record and the operational truth drift apart within months. The office looks at one system, the engineer at another, and the fact that this site has had the same fault three times in a year is visible in neither because it lives in three unconnected jobs.
The practical cost is felt at the door. An engineer who cannot see the site history arrives without context, asks the customer questions the company already knows the answer to, and occasionally repeats a repair that was tried in March.
A record shaped like your business
Fieldproxy holds customers, sites, assets and history in one model, built to your structure — however many levels it needs, and whatever a site or asset record has to contain in your trade. What the engineer sees on arrival is part of that design rather than a fixed screen.
Things usually fixed elsewhere and yours here:
- The customer, site and asset hierarchy, however deep it needs to be
- What a site and an asset record hold
- What the engineer sees on arrival, and in what order
- Contract and agreement structures with renewal handling
- Commercial terms, rate cards and PO requirements
- Who can see and change what
Two approaches to the same problem
| A sales CRM plus a job system | One service-shaped record | |
|---|---|---|
| Structure | Contacts and deals | Customers, sites and assets |
| History | Split across systems | One place, visible on site |
| Recurring faults | Invisible across separate jobs | Visible against the asset |
| Engineer context | Whatever the job ticket says | The full history of that site |
What you can run on it
- Customers, sites and assets with full service history
- Contracts and agreements with renewal tracking
- Quotes and opportunities where a pipeline genuinely applies
- Engineer-facing site history in the mobile app
- Commercial terms, rate cards and PO handling
- Reporting on customer profitability, recurring faults and retention
Common questions
What is a field service CRM?
It is the customer record for a service business — customers, their sites, the equipment on those sites, and the full history of what has been done. It differs from a sales CRM in that the pipeline is the least important part and the service history is the most.
Do we still need a separate sales CRM?
Usually not, and keeping both is the main cause of the two records drifting apart. Where there is a genuine new-business sales motion, that pipeline can live in the same model rather than in a second system.
Can it handle customers with many sites?
Yes, and the hierarchy is the point. Each site carries its own equipment, access rules, history and sometimes its own commercial terms, while the customer holds the relationship.
What does the engineer see on arrival?
Whatever you decide they should see — normally the site, the asset, what was done last time, what is under warranty and any access or safety notes. This is configurable because the right answer differs sharply by trade.
Will it show recurring faults?
Yes, provided history is attached to the asset rather than the address, which is precisely what separate job records fail to do.
See your customer record as it should be
Bring a multi-site customer with a messy history. That is the fastest way to see the difference.
Book a walkthrough