From alert to close-out: the full circuit

Almost every description of a CMMS is a list of modules. That’s not very useful, because it doesn’t explain the one thing that decides whether the system is actually going to work: what exactly happens between someone noticing something is wrong and that job being closed, billed, and provable.

This is that journey, step by step.

Step 1: it comes in somewhere

The first point where information gets lost. An alert sent by messaging app to a technician, another by phone to the team lead, and another by email to admin are three jobs nobody can count together.

In GMAO Cloud an incident can be created from the backend, from the client portal with its description, the affected equipment, and a photo, or from a mailbox that the system empties and automatically converts into alerts.

What you can’t do is ban the phone. What you can do is have whoever answers it log it in the same place.

Step 2: it gets prioritized

The incident carries its type and subtype, its priority, the client, the address, and the affected asset. And statuses can carry their own maximum time, with an SLA entity that defines priority and limit.

That way, what’s overdue shows up in a list instead of being discovered when someone complains. And it separates what’s urgent from what’s just noisy, which isn’t the same thing even if everything arrives flagged the same way.

Step 3: or it’s born on its own

The other half of the work isn’t requested by anyone: it’s generated by the plan.

The checklist is attached to the asset, to its model, or to a whole family, the frequency is defined, and preventive maintenance generates the orders on its own, checking beforehand whether the day is a holiday and whether the technician is available.

And if the wear depends on usage, the asset can carry a counter with a limit and a warning percentage: when a reading that exceeds the threshold is logged, the order is generated automatically.

Step 4: it gets distributed

The calendar shows what’s happening each day and whose it is, and the diagram-based planning view shows each technician’s load across the weeks. The most useful thing on that screen is what has no owner, because that’s what’s going to fall through.

When something needs to be moved — which happens every day — it gets dragged to another day. And technicians can pick up unassigned work themselves, because they know whether it’s on their way.

Step 5: it gets carried out where it happens

In the app the technician opens the order and has the equipment history, its documentation, and any open anomalies right in front of them. They start the stopwatch, draw material from the warehouse, fill in the checklist — for preventive jobs they can’t close without it — take photos, and collect the client’s signature on screen.

Everything works without connectivity: orders, assets, and documents are stored on the device, and actions go into a queue that empties once signal is recovered. If one fails, it gets flagged with its reason instead of just disappearing.

This is the step that decides the project. If there’s friction here, logging gets pushed to the end of the day and stops being accurate.

Step 6: it closes, or it stays open with a reason

An order can be marked as waiting on parts or as needs a return visit. They’re two different statuses and both necessary: without them, those jobs live in a notebook.

And a status change can carry its own associated email, so the relevant person finds out without anyone having to write the notice.

Step 7: if a quote is needed

When the work isn’t covered by contract, the quote manager closes the circuit: the quote is born from an order and generates another one when accepted, with its client, payment method, and PDF and email template. Nothing needs to be typed twice.

Step 8: material gets replenished

What’s consumed comes off stock when the order closes. When an item reaches its minimum stock level, it gets replenished through the purchasing workflow, with its supplier, destination warehouse, and line items.

Step 9: the data flows out to the ERP

A closed job shouldn’t have to be typed in twice to get billed. Closed orders with their hours and consumption are exactly what the ERP needs.

Integrations documents the scope of each connector, which isn’t the same across the board: it’s worth checking before assuming the data flows through automatically.

Step 10: the history remains

And this is the part that can’t be recovered afterward. On close, the order has recorded the actual times, the material, the photos, the completed checklist, and the signature.

Reports rest on that — cost per asset, hours per technician and client, downtime, MTBF and MTTR, plan completion — as does the ability to prove what was done in the face of a complaint or an inspection.

Who sees what throughout the journey

A cross-cutting aspect worth deciding up front, since it affects every step: not everyone sees the same thing.

The technician sees their orders, the equipment history, and the documentation relevant to them. The team lead sees their team’s work, not the company’s three hundred open orders. The client sees their own: their sites, their assets, their orders, and the documents marked as visible to them. And the supplier sees the orders assigned to them.

Each document has its visibility set up once, which removes the need to manually decide what to show every time someone asks for something.

And one detail that shapes all of it: if adding a new user costs money, accounts get shared, and at that point the whole circuit stops being traceable. In GMAO Cloud licenses are unlimited across all three plans.

Where the circuit breaks

Almost always in two places.

At step 1, if alerts keep coming in through parallel channels. Then the list of pending work is never complete.

At step 5, if the logging doesn’t happen in the field. Then the data exists but isn’t accurate, and everything that follows describes a reality that never happened.

If you’d like to see the whole circuit applied to a case of your own, you can request a demo.