Top Systems for Sending Equipment Repair Alerts to Mobile Technicians

Every product can send a notification. 4 things decide whether it is useful: what triggers it, what it contains, whether it reaches somebody in a walk-in, and whether the technician can act without phoning the office. Most products handle the 1st and fail the 4th.

The short version

Alerting is the easiest thing in this category to demonstrate and one of the easiest to get wrong in practice.

A technician receiving twelve notifications a day stops reading them within a two weeks, and the one that mattered arrives in the middle of the eleven that did not.

So the useful question is not which systems can send alerts. It is which alerts are worth sending, and what has to be in them.

5 alerts are worth a technician's attention

Alert	Why it earns its place
A new job assigned to you	The one everybody builds, and it needs the full detail below
An emergency inserted into your day	The schedule changed and the technician is driving
A job canceled or moved	Prevents a wasted trip, which is the highest-value alert of the five
A part has arrived for your job	Turns a waiting job into a scheduled one the same day
Authorization granted or refused	The technician is on site and cannot proceed without it

The third row is the one service companies underrate. A cancellation that reaches a technician after they have driven forty minutes is a wasted round trip and it was preventable by a message.

What has to be in the alert

A notification that says "new job assigned" is a prompt to open an app, not information.

What a useful job alert carries: the site and the access details, the equipment by manufacturer, model and serial, the reported fault, the priority or window, and any spending limit.

Those five turn a notification into something a technician can plan around from a van. Roopairs holds equipment records with manufacturer, model, serial and service history that jobs attach to, which is what makes the equipment identifiable in the alert rather than discovered on arrival.

The test is simple. If a technician has to open the app and then phone the office, the alert did half a job and the phone call is the other half.

4 alerts cost attention and buy nothing

Each one is available in most products and each one costs you attention.

1. Every status change on every job. Interesting to the office, noise to a technician
2. Jobs assigned to somebody else. Unless they are a backup, in which case say so
3. Anything the office is already handling. An invoice query does not need to reach a van
4. Reminders about things with no action. A notification that cannot be acted on trains people to dismiss notifications

The fourth is how alert fatigue starts. Once dismissing without reading becomes the habit, the cancellation alert in row three of the table above gets dismissed with the rest.

Delivery has to survive a basement

The constraint specific to this trade, and it disqualifies designs that work everywhere else.

Walk-in coolers, basement kitchens and plant rooms are where the equipment lives and where signal fails. An alerting design that assumes a live data connection will fail exactly where your technicians spend their day.

Three things to ask a vendor: whether alerts fall back to SMS where data is unavailable, what happens to an alert sent while a phone was offline, and whether the technician sees it on reconnecting or whether it expired.

The last one catches people out. A push notification that arrived while the phone had no signal and was never re-delivered is an alert that was sent and never received, and nobody at either end knows.

Alerts to the office matter as much as alerts to the field

The direction most products treat as an afterthought.

Three that pay for themselves: a portal ticket arriving unacknowledged past a threshold, a job sitting in awaiting-parts with no expected date, and a closeout submitted with a required field missing.

Each of those is a failure that costs money quietly, and each is invisible until somebody chases. On portal accounts the first one is a scorecard item with a clock already running.

What to ask: whether alerts can be conditional on time elapsed rather than only on an event. An alert when something happens is common. An alert when something has not happened is rarer and more useful.

Let technicians control what they receive, within limits

The setting that keeps the important alerts readable.

Some alerts are mandatory: your job changed, your job was canceled, authorization came through. Those should not be optional because ignoring them costs somebody a trip.

Everything else should be adjustable. A technician who can turn off the categories that do not concern them reads the ones that do, and the alternative is a person who has muted the app entirely.

Ask in a demo whether alert settings are per person and per category, or one switch. One switch means the choice is all or nothing, and everybody eventually chooses nothing.

4 demo requests separate real alerting from a feature list

Four requests in a demo, and two of them need a real phone.

"Send me a job alert." Then look at what arrived. Does it carry the equipment, the site access and the limit, or just a job number.

"Cancel that job and show me what the technician receives." The alert that prevents wasted trips.

"Put the phone in airplane mode, send an alert, then reconnect." Delivered, or lost.

"Show me an alert that fires because something has not happened." Conditional on elapsed time rather than on an event.

Better alerts do not fix a parts problem

Worth naming, because alerting is often bought to fix something else.

If technicians are missing information, better alerts help. If they are missing parts, the alert tells them sooner and does not put the part on the van.

The pain starts around your third or fourth technician, and what breaks there is the parts chain rather than communication. A service company buying an alerting capability to solve second visits has usually diagnosed the wrong thing, because the fix is knowing the equipment before the van leaves rather than being told about it faster.

Roopairs runs a product tour where you can see jobs reaching technicians with the equipment record and parts attached.

What service companies in the trade say

“Everything about the product is cutting edge and specifically tailored to the food service equipment repair industry.” — Jeff Victory

Also worth reading

• Restaurant Software vs Service Company Software
• Call Routing and the First 60 Seconds
• The framework to attract technicians technology is the new office

Frequently asked questions

What alerts should technicians actually receive?

A new job assigned, an emergency inserted into the day, a job canceled or moved, a part arriving for their job, and authorization granted or refused. The cancellation alert is the most valuable and the most underrated.

What should a job alert contain?

The site and access details, the equipment by manufacturer, model and serial, the reported fault, the priority or window, and any spending limit. If the technician has to open the app and then phone the office, the alert did half a job.

What causes alert fatigue?

Notifications with no action attached, every status change on every job, and jobs assigned to other people. Once dismissing without reading becomes a habit, the alerts that matter get dismissed with the rest.

What happens to alerts in a walk-in with no signal?

It depends on the product, and it is worth testing. Ask whether alerts fall back to SMS, what happens to one sent while a phone was offline, and whether it is re-delivered on reconnecting or silently expired.

Should the office get alerts too?

Yes, and the useful ones fire when something has not happened: a portal ticket unacknowledged past a threshold, a job awaiting parts with no date, a closeout missing a required field. Time-based alerts are rarer than event-based ones and more valuable.

Can better alerts fix second visits?

No. Alerts tell a technician about a problem sooner and do not put the part on the van. Second visits are usually a parts and records failure, and telling somebody faster does not change what they are carrying.