Incident management: how to set it up

Incident management usually gets set up quickly and badly: four generically named statuses get created and it goes into use. Six months later nobody knows what “in progress” means, half the reports still come in by phone, and there is no way to tell what has missed its deadline.

Here is what is worth deciding beforehand, and in what order.

1. Entry channels

First, because if the report does not come in properly, nothing else matters.

In GMAO Cloud, an incident can originate in three ways: from the backend, from the client access with its description, the affected equipment, and a photo, or from a mailbox that the system empties and automatically converts into incidents, with a separate mailbox per type if needed.

The decision is not to ban the phone, which is impossible. It is that whoever answers it logs it in the same place, and that the automatic channels cover as much as possible. As long as there are three parallel lists, there is no pending list.

2. Types and subtypes

This is where you decide what you will be able to analyze later, so it is worth thinking about it with the final report in mind.

Types and subtypes are what lets you later answer “what kind of failure keeps repeating” and “which area concentrates the problems.” If everything comes in as “breakdown,” that question will have no answer.

The practical rule: few types, clearly distinguished. A list of thirty types gets filled in badly, and a list of four does not discriminate anything. Between eight and twelve usually works.

3. Priority, and what each level means

Having levels is not enough: you have to agree on what falls into each one. Otherwise everything arrives marked urgent and priority stops being useful.

The incident carries its priority, and it is worth defining it by consequence rather than by who is reporting it: what stops the service, what carries risk to people, what has a committed deadline, what can wait.

It helps if assets have their own criticality, because then the incident’s priority does not depend on the tone of the report.

4. Statuses, with their deadlines

Each status can carry an associated maximum time. And there is an SLA entity with its own name, priority, and time limit. Incident timing is also recorded.

That achieves two different things. Anything overdue shows up in a list instead of being discovered when someone complains. And it lets you later measure response time and resolution time separately, which are not the same thing and are both audited in contracts.

Defining five clear statuses with an agreed meaning is a one-hour conversation that avoids months of ambiguity.

5. What sends a notification and what does not

Statuses can carry their associated email, so that a status change triggers a notification to the interested party without anyone writing it. And you can control which statuses are visible to the client and which ones stay internal.

Just as important: you can mark which statuses should not notify. Notifying on every internal movement turns notifications into noise and people stop reading them, which is worse than not having them.

The notification system also covers alerting the technician when work is assigned to them, by push and by email.

6. From incident to work order, without typing it twice

An incident is not a job: it is the request for a job.

From it comes the work order with its technician and its date, carrying over the client, the address, and the affected equipment. And if prior approval is needed, a quote is generated, which in turn creates the work order once accepted.

The work order keeps its origin, so you can always trace back from the work done to the report that triggered it. That link is what later lets you calculate how much it cost to handle an incident, not just how long it took.

7. What the technician brings back

There is a source of incidents almost never considered when setting things up, and it ends up being one of the most valuable: the ones the technician detects while doing something else.

Checklist fields support a minimum and maximum value, so an out-of-range reading gets logged as an anomaly on the spot. That anomaly has to be convertible into an incident with its own priority and owner.

If it gets logged and nothing happens, the technician stops logging it the third time. And rightly so.

What can be measured afterward

With incidents logged by type, priority, timing, and outcome, reports answer questions that would otherwise be opinions:

• Which type of failure keeps repeating and on which equipment.
• Which sites or clients concentrate incidents.
• How long it takes to respond and to resolve, by priority.
• How many hours go into corrective work versus preventive.

That last ratio is the most useful of all. If corrective work does not go down despite having a preventive plan, the plan is looking at what does not fail.

The cost of an incident

There is a question almost no company can answer, and it appears on its own if the setup is done well: how much does it cost to handle a report.

It is not the cost of the repair. It is the full cost: the time of whoever receives and classifies it, the trip, the technician’s hours, the material, and — when it happens — the second visit because a part was missing.

With the incident linked to its work order, and the work order closed with measured time and imputed material, that figure exists. And once it exists, uncomfortable and useful conclusions appear: which type of report consumes more than it seems to, which client generates more load than contracted for, and how much it would really cost to prevent those breakdowns with more preventive maintenance.

That final comparison — what it costs to respond versus what it would cost to prevent — is what lets you size the plan with judgment instead of intuition.

The most expensive configuration mistakes

Too many statuses. If nobody remembers what they mean, two get used and the rest is decoration.

Priority without an agreed criterion. Everything urgent equals nothing urgent.

Notifying everything. People stop reading the alerts, and then the important ones stop getting through too.

Not giving the client access. A good part of the calls do not ask for anything: they ask how things are going. Since licenses are unlimited across all three plans, giving access to your whole client base is not a financial decision.

Where to start

With the minimum: unified entry channels, five statuses with an agreed meaning, and priority defined by consequence. Fine-grained types, SLAs, and per-status alerts get tuned afterward, once there is real usage and you know what is actually needed.

If you want to see it set up around your own case, you can request a demo.