Cookbook
Run a field service operation with sites and assets, not just accounts
Work does not happen at an account. It happens at a site, to a specific piece of equipment, and a CRM with one level of hierarchy cannot say that. This is the model that can.
The modelling decision
Three levels, not two. The account signs the contract. The site is where somebody drives to. The asset is the thing that breaks, and it is the thing everything else is actually about: service intervals belong to it, failures belong to it, and its history is what tells you whether to repair it again or replace it.
Most CRMs give you accounts and contacts, so sites become a text field and assets become a spreadsheet. Then "what is overdue at Avonmouth" is a question nobody can answer without ringing the site manager.
Here the levels are real records, and your own types can point at each other, so the chain holds: an asset belongs to a site, and a site belongs to an account.
You
The morning question
You
Agent
Every line names the asset and the place a van has to go. That is only possible because the site is a record rather than a string: ask the same question of a flat model and you get six asset tags and no addresses.
Two of the six are at the same site, which is the other thing this model gives you for free. One visit, two jobs, and nobody had to notice by eye.
What is actually down right now
You
Agent
Both are also on the overdue list above, which is the correlation worth looking at every time it appears. Equipment that goes down while overdue is an argument for the service interval, and it is an argument you can only make if the two facts live on the same record.
The shape of the estate
You
Agent
One site in Scotland is a routing problem and a margin problem, and seeing it stated is usually the first step to either winning another one nearby or pricing the travel properly.
Two things worth knowing
- Ask by the names you declared. A field and a relationship are both addressed by the name you gave them, so one site's assets is a filter on the site. There is a prefixed form used for fields added to built-in records, and if you carry it across you are told which spelling this type wants.
- Count by site directly. Assets per site across the whole estate is one question, answered by the database rather than by listing and tallying. Ask by the name you declared the relationship under. Above a couple of hundred sites you are told the answer is too long to be a report, which is the point at which you wanted a filter anyway.
Verify it
- Ask for one site's assets. You should get that site's, not the account's. If a filter on the site returns everything, the chain is not connected and every list above is wrong in the same direction.
- Move an asset between sites. It should leave one list and join the other. This happens constantly in real estates and is where a spreadsheet quietly stops being true.
- Service something and push its date forward. It should leave the overdue list. If the list never shrinks, dates are being recorded somewhere the question does not read.
- Count assets against the last physical audit. Once. An estate list that has never been walked is a list of what somebody installed, not what is there.
Run it again
Overdue every morning, and it should be a short list or the intervals are wrong. Out of service continuously, which is what a channel notification is for. The estate breakdown quarterly, when somebody is deciding where to put an engineer.