Push to the technician's phone
Assigned work, changes to what they already have, and urgent jobs. It's the channel that actually gets looked at in the field.
Feature
Alerting about everything is alerting about nothing
The problem with notifications isn't that they're missing: it's that there are too many. As soon as a system sends forty emails a day, people set up a rule to archive them and stop noticing any of them.
What is a notification system for?
So information reaches people without anyone having to go looking for it, and without someone else having to remember to pass it on. In maintenance there are three moments when that really matters: when work is assigned to someone, when the status of something another person is waiting on changes, and when a date nobody has in mind is approaching. Everything else — and it's a lot — is noise that ends up training the user to ignore the system.
What happens when there are no alerts
And also what happens when there are too many.
- The technician doesn't know they've been assigned an urgent job until someone calls them.
- The client asks for the third time how their repair is going because nobody has told them anything.
- A certificate expires and it's only discovered once it's already overdue.
- The manager finds out a job has been stalled for two weeks only when looking at a report.
- Or the opposite: so many system emails arrive that nobody opens any of them.
What alerts, and through which channel
Two channels and one rule: every alert has to have a recipient who can actually do something with it.
Email, even to people without an account
Email alerts to system users and also to external addresses, for the client contact who is never going to log in to the portal.
Tied to statuses
Each status of an order or an incident can carry its own associated email, or be explicitly marked not to notify. The workflow and the alerts get defined together.
With the report attached
A behavior exists that sends the order's PDF directly once a given status is reached. The client gets the report without anyone sending it by hand.
Expirations
Documents and certificates that expire, and personal protective equipment reaching the end of its service life. It alerts before, not after.
What's coming up next week
A heads-up about the work planned for the following days, which is when there's still time to organize around it.
The important part is being able to turn them off
A notification system is judged by what it stops sending. That's why alerts are configured per status, not globally: you decide which transitions deserve an email and which don't, and a status can be explicitly marked not to notify even if everything else does. The result is that each company's own workflow determines its alerts, instead of receiving a fixed package you have to put up with. If an alert doesn't make someone do something different from what they were already going to do, it's not needed, and the sensible thing is to remove it.
Shall we look at it with your way of working?
Leave your details and we will get in touch to see whether we fit. No commitment, no lock-in period.
There's a record of what was sent
Every notification is saved with its recipient, its content, and whether it went out by email, by push, or both, plus whether it's been seen. That's useful for two very practical things: settling the classic "nobody told me", which stops being an argument once there's a record; and periodically reviewing what's actually being sent, which is the only way to catch that an alert configured two years ago has fired a thousand emails that nobody reads.
A notification nobody reads isn't a notification anymore
The most common mistake when configuring notifications isn't sending too few, it's sending too many. A system that alerts on every status change of every order generates such a volume of email within two weeks that people set up a rule to archive it, and from that point on the channel is dead: it no longer works even for what actually matters. The practical rule is harsh but it works: only alert about something someone has to act on differently from what they were already going to do. A preventive job due next week isn't an alert, it's a plan, and you check the calendar for that. A certificate expiring in a month is an alert, because it forces someone to act. And everything else — tracking, status, progress — belongs on a screen you check when you need to, not in a notification that interrupts you.
Frequently asked questions
What happens if someone doesn't read an important alert?
That's why critical alerts shouldn't depend only on someone noticing them: whatever isn't handled within a deadline has to be visible on a list someone actually reviews, not sitting and waiting in an inbox. A notification is a nudge, not a control mechanism, and mixing the two up is what makes something get lost exactly on the day it mattered.
Can I decide what each person receives?
Yes, and you should, because the same alert doesn't mean the same thing to everyone. The zone manager needs to know an order has been open for two weeks; the technician doesn't need that information at all. Configuring it by role rather than by person is what keeps it making sense when the team changes.
Can the client be notified too?
Yes, and it's worth being careful about volume. A client who gets a notification for every status change stops reading them within a week and also gets the sense a robot is writing to them. What's appreciated is being alerted at the two or three moments that actually matter to them: that their request has been received, and that the work is done.
What channels are available?
Push notifications to mobile and email. Email can also go to external addresses, to notify client contacts who aren't system users.
Can I choose what triggers an alert?
Yes, and that's the important part. Alerts are configured per status: each status of an order or an incident can carry its own associated email or be marked not to notify. That way your company's own workflow defines its own alerts.
Can the report be sent to the client automatically?
Yes. There's a status behavior that emails the order's PDF once that status is reached, so the report arrives without anyone having to send it.
Does it alert about expirations?
Yes. There are periodic checks for documents and certificates approaching expiration, and for personal protective equipment reaching the end of its service life.
Is there a record of what has been sent?
Yes. Every notification stores its recipient, content, channel and whether it's been seen, which settles arguments about whether someone was notified or not.
Decide what deserves an alert
In the demo we walk through your status workflow and mark which ones justify a notification and which don't.