Keeping customer details current on every device

Last updated: September 2026

Copies drift, records do not

Most small trades businesses keep customers in phone contacts, which means every phone holds a copy. Copies drift: a number changes, one person updates it, the others do not, and the office rings a dead line for six months.

Worse, a copy leaves with its owner. When someone moves on, their handset takes the only current version of forty customers with it, along with the messages that explain what was agreed.

The answer is not better copying. It is having one record, held centrally, that everyone reads from rather than duplicates.

What “one record” actually means

• Update once, visible everywhere. A number changed in the office is the number in the van thirty seconds later, because there is only one of it.
• Nothing stored on the handset. No local copy means no stale copy and nothing to wipe when a phone is lost.
• Access controlled by role, so the person who can change a customer is not necessarily everyone who can see one.
• History attached, so the record is not just a phone number but the work you have done at each address.

Where Dispatch fits

Customers, jobs, quotes and invoices live on the server, and every device reads the same record. Open it on a laptop in the office and on a phone in a van and you are looking at the same thing, not two copies that have to be reconciled.

Because it runs in a browser, there is nothing installed on the handset and nothing cached on it. A lost phone is a lost phone rather than a data incident, and a new starter is working on their own device within a minute of accepting an invite.

Who can change what follows the three fixed roles, which are set out on the roles and permissions page: owners and office admins manage customers, while field technicians see the jobs assigned to them and the detail they need to do the work.

Firestore, Storage and all compute run in the UK, in London. The one exception, stated properly rather than glossed over, is that authentication records such as email address and password hash sit on Google global infrastructure, because that service offers no region control.

The calendar question

People often mean something narrower by syncing: they want their jobs in the phone calendar they already use.

That is available and deliberately limited. An engineer can subscribe to a private calendar feed or receive an email invite per job, and it is one way, out of the app only. Changes made in a personal calendar do not come back.

Only the job number and the site postcode travel. Names, addresses, phone numbers, notes and photographs stay in the app where the permissions are, which is the right trade-off for a work calendar that might be shared with a partner. Syncing jobs to your calendar covers the setup and the caveats, including that calendar apps decide for themselves how often to check.

What about when someone leaves?

This is the strongest practical argument for central records. When an engineer leaves, their access is removed and the customer records, the job history and the customer message threads stay with the business, because they were never on the handset.

It is also why job chat posts as the business rather than as a named individual: a customer who replies a month later is messaging the company, not a person who no longer works there.

The corollary is worth planning for too. Remove access on the day someone leaves, not eventually, and remember that anything they kept in a personal phone was never yours to begin with.

A practical clean-up

If your customer list is currently four phones and a spreadsheet, do not attempt a grand merge. Add each customer properly as their next job comes in, and within two months the ones who matter are all in there.

Then make one rule stick: a number changed anywhere gets changed in the system, not in a phone. It is a small discipline, and it is the difference between a list you can trust and four you cannot.