Your client, from their own access
With the description, the affected asset and a photo. It's the channel that gives the best information, because the form asks for exactly what's needed.
Feature
A request that isn't logged doesn't exist
A text to the supervisor's phone, an email to someone on holiday, and a call nobody wrote down. Three requests, and only the loudest one gets handled.
What is an incident?
In maintenance, an incident is the notification that something is wrong: the request someone makes before any work has been assigned. It's not the same as a work order, and confusing the two is the root of many management problems. The incident is what the requester sees and expects a response to; the order is what the organization does about it. An incident can result in several orders, in just one, or in none at all — because it was a false alarm or because it was already resolved — and keeping them separate is what lets you measure two different things: whether you respond fast, and whether you fix things properly.
What gets lost before work even starts
Work doesn't get lost while it's being done: it gets lost earlier, at the intake.
- Requests that come in through four different channels and never end up on the same list.
- A two-word description that forces a phone call just to understand what's wrong.
- Two people from the same site reporting the same issue, and two technicians sent out.
- Nobody knows how long it took to respond, so the commitment can never be reviewed.
- The requester asks again because they never got any sign that something is being done.
Where a request comes in from
The idea is that it shouldn't matter: they all end up in the same place.
By email
An inbox that empties itself and turns messages into incidents of whatever type you assign. For the clients who are going to keep writing emails no matter what you tell them.
The technician themselves
What they notice in passing while doing something else. It's the most underused source of requests in most operations.
Your in-house team
The usual phone call, logged where it belongs instead of on a sticky note, with the requester identified.
Classifying is for deciding
It's not bureaucracy: it's what lets you prioritize without reading everything.
Your own type and subtype
Your own taxonomy of requests, not a fixed list. It's what later lets you find out what people are actually complaining about.
Maximum time per priority
Each priority level carries its own maximum response time, and each status can have its own too. The commitment stops living in the contract and starts living in the system.
Zone, site and asset
The incident is anchored to where it happens and what equipment it's on, which is what lets you spot that three different reports are actually the same problem.
Assigned handler
Who's responsible for making sure the incident moves forward. Without a named owner, requests just sit there waiting for someone to pick them up.
Warranty and downtime cause
Flagged at intake, not at the end. They change who pays and what analysis can be done afterward.
Linked quote
When what's requested needs approval before it can be carried out, the quote hangs off the incident itself.
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.
From request to work, and back
An incident moves through its own statuses, which you define and which can trigger an automatic email: the requester finds out it's been received, that it's been assigned and that it's been resolved without having to ask. When it's time to act, the incident generates one or more work orders, and the link is maintained both ways: from the order you can see which request it came from, and from the request you can see what it turned into. On top of that, the order's statuses can push the incident's status forward, so closing the work closes the request without anyone having to remember to do it in two places.
Who sees what
Statuses are flagged separately as visible internally, visible to the client and visible in the apps. That lets you run an internal workflow with all the detail your team needs — "pending quote", "waiting for site access", "referred to manufacturer" — and show the requester a version they can understand, without having to choose between a bare-bones workflow and exposing your internals. Communications on each incident are logged too, so the conversation stays attached to the request instead of scattered across emails and calls.
Frequently asked questions
Does every incident have to end up as a work order?
No, and forcing it just creates noise. Some requests get resolved with a phone call, some turn out to be duplicates, and some don't need attention at all. What does need to be recorded is that they came in and how they were closed: the volume of requests that never become an order says a lot about where communication is breaking down.
Can I receive incidents by email?
Yes. You can configure an inbox that gets checked automatically and turns incoming messages into incidents of whichever type you assign. It's the practical route for clients who are going to keep sending emails.
What's the difference between an incident and a work order?
The incident is the notification that something is wrong; the order is the work the organization carries out. An incident can generate several orders, just one, or none. Keeping them separate lets you measure the response to the requester on one hand and the execution on the other.
Can committed response times be tracked?
Yes. Each priority carries its own maximum time, and statuses can have their own too, so the commitment lives in the system and not just in the contract.
Does the client see every internal status?
Not unless you want them to. Each status is flagged separately as visible internally, to the client, and in the apps, so you can run a detailed internal workflow and show an understandable version to the outside world.
Is the requester notified automatically?
Statuses can carry an associated email, so whoever opened the request gets a signal when it's received, when it's assigned and when it's resolved, without anyone having to write it by hand.
Tell us where your requests come in from
In the demo we set up your channels, your types and your response times to see what would be getting lost today.