One Dispatch Board, Five Customer Portals: Keeping Them in Sync

Your board and their portals only have to agree on 3 states: accepted, scheduled, complete. Everything else can differ. Service companies that try to keep both systems fully aligned spend twice the effort and still drift, because the two are recording different things for different people.

The short version

A dispatcher running five portals is not managing five systems. They are managing one board and reporting into five, and the difference in framing changes what has to be done.

Your board is the truth about your business: who is where, what parts are on which van, what the job cost. Their portal is the truth about their service request: was it accepted, is somebody coming, is it done.

Neither is a copy of the other, and treating them as copies is what produces the doubled work:

• Three states have to agree, and they are the only three
• Everything else in your board is yours and does not belong in their system
• Everything else in their system is theirs and does not belong on your board

The 3 states that have to match

State	What they need to see	What happens if it drifts
Accepted	You have taken the job, within the window	A missed response target on your scorecard
Scheduled	Somebody is coming, and roughly when	The site chases the facilities manager, who chases you
Complete	Work is done, with their evidence attached	The invoice cannot be issued, or is issued and rejected

That is the whole synchronization requirement for most programs. A service company that keeps those three accurate and ignores the rest is doing the job correctly.

What tempts people into more is that portals often have fields for notes, parts, technician names and progress. Filling those is optional in most programs and expensive in all of them, because it is the same information typed a second time for no downstream effect.

Check what is genuinely required per account rather than assuming. Service companies frequently discover they have been filling fields nobody reads.

One person owns the sync, and it is not the technician

The most common failure is spreading portal updating across whoever is nearest.

It looks reasonable and it produces three problems: nobody knows the current state across accounts, conventions differ between people, and when the busiest person is unavailable the updates stop.

What works is one owner for portal state with a named backup, and technicians who update your board rather than the portals. The technician records what happened once, in the system they already use, and the owner reflects the three states outward.

The exception is completion evidence, where check-in and photographs often have to come from the person on site. That is worth accepting as the one thing technicians do in the portal, and it argues for making everything else not their problem.

The daily rhythm that keeps it from drifting

Three touches a day is enough for most service companies, and the timing matters more than the frequency.

1. First thing. New tickets from overnight, accepted or declined, and scheduled where possible. This is the touch that protects response targets
2. Midday. Anything arriving in the morning, plus scheduling confirmations for the afternoon
3. End of day. Completions from today's jobs, with evidence, before anyone goes home

The third one is the one that slips, and it is the one that gates invoicing. A job completed Tuesday and closed out Friday has spent three days not being invoiceable, on terms that were already long.

Where a program has notification settings, using them converts the first touch from a sweep into a response. Many service companies have never turned them on.

What to keep on your board and never in theirs

Being clear about this halves the work.

Yours alone: technician assignment and scheduling detail, parts consumed, purchase orders to suppliers, your costs, your margin, your notes about the customer, and your equipment records.

Theirs alone: their ticket numbering, their site identifiers, their asset references, their approval chain, their scorecard.

The overlap is small and specific: the three states, their references on your job so the invoice is correct, and the completion evidence. Everything else living in one place is not a compromise, it is the correct arrangement.

Where service companies go wrong is trying to mirror their asset list into your equipment records or vice versa. Those two lists serve different purposes and will never agree, because they were built by different people for different reasons at different times.

What breaks at 3 portals and above

The step change is not linear, and it arrives around the third account.

One portal is a habit. Two is a routine. Three is context switching all day: different logins, different words for the same thing, different notification behavior, different rules about what closes a job.

The errors that produces are not carelessness. They are the predictable result of a person holding three rule sets and applying the wrong one occasionally, usually under time pressure at the ends of the day.

At that point the options are to specialize a person per portal, which is expensive and fragile, or to get the tickets onto one board so the rule sets stop being held in a head.

Roopairs is built to work with third-party facilities management software, named alongside manufacturer warranty and non-warranty jobs as a workflow the product is drawn around. That is the structural version of the answer, and it is worth measuring what the current arrangement costs before deciding.

A weekly reconciliation that takes ten minutes

Drift is inevitable and it is cheap to catch if somebody looks.

Once a week, per portal, check two lists. Open tickets in their system with no matching job on your board, and jobs on your board for that customer with no matching ticket state.

The first list finds work you have not accepted or scheduled. The second finds completions never reported, which is invoicing sitting still.

Both are usually short and both contain something worth the ten minutes. A service company that has never run this check will find more on the first pass than it expects, which is itself the argument for making it weekly.

Roopairs runs a product tour where you can see portal jobs and your own work on one board.

What a kitchen operator says

“My service vendor looks everything up on Roopairs, lets me know the issues, what's already been taken care of and what I need to get taken care of, so I can get my kitchen back up and running in a timely fashion.” — a kitchen operator whose service company runs Roopairs

Also worth reading

• Roopairs vs ServiceTitan for Kitchen Repair
• Bi-Directional Sync: The Direction Matters
• 10 tips to hire and grow remote technician teams

Frequently asked questions

What has to be kept in sync between our system and a customer portal?

Three states: accepted, scheduled and complete. Everything else in each system is for a different audience. Service companies that try to mirror both fully double the work and still drift, because the two records were never describing the same thing.

Who should update the portals?

One named owner with a backup, not whoever is nearest. Technicians should update your board rather than the portals, with the exception of on-site evidence such as check-in and photographs, which has to come from the person there.

How often should portals be checked?

Three touches a day for most service companies: first thing for overnight tickets, midday for arrivals and scheduling, and end of day for completions. The end-of-day one slips most and it is the one that gates invoicing.

Should we mirror their asset list into our equipment records?

No. The two lists were built by different people for different purposes and will not agree. Keep your equipment records as your own and use their asset reference on the job only where an invoice requires it.

At what point does this stop being manageable?

Around the third portal, because that is where a person is holding three rule sets and applying the wrong one occasionally. The errors at that point are structural rather than a discipline problem, and better checking does not fix them.

How do we catch drift?

A weekly ten minute check per portal: open tickets in their system with no job on your board, and jobs on your board with no matching state reported. The second list is completions never reported, which is invoicing that has stopped moving.