CMMS for elevator maintenance

Elevator maintenance has three particularities that set it apart from almost everything else: the schedule isn’t set by the company but by regulation, every unit is an identified asset with its own registration number, and part of the alerts — entrapments — cannot wait.

That shapes how the system needs to be set up, whether you’re the maintenance company or the one hiring the service.

Every unit, an identified asset

This is the first thing, and it’s usually poorly handled in spreadsheets, where what exists is “the building,” not each individual unit.

In asset management every elevator has its own record: serial or registration number, model, manufacturer, installation date, cost, warranty expiration, exact location, and whatever custom fields are needed — number of stops, load capacity, drive type, speed — each with its own unit.

Units are grouped by model and family, which lets you define the inspection schedule for a type of machine once and apply it to every unit of that type, instead of configuring each one individually.

And with a QR code in the cabin or in the machine room: the technician scans it and lands on the right record, with the history and documentation right there, without depending on an internal numbering scheme that each maintenance company writes its own way.

The inspections set by regulation

Worth clarifying before anyone goes looking for it in the menu: legal maintenance is not a module in GMAO Cloud. It’s handled through the general preventive maintenance mechanism.

The inspection schedule required by regulation gets linked to the unit, its model, or an entire family, the frequency is defined, and the system generates the work orders on its own, with a technician and a date, checking beforehand whether the day is a holiday and whether that person is available.

A single unit can have several schedules at once, which is exactly how this sector works: the periodic inspection is one thing, the inspection by an approved control body is another, and neither replaces the other.

To be precise, because it matters: the software records and proves what was done. The ones accountable to the regulation are the maintenance company and the owner of the installation.

Checking with actual values

An elevator inspection without a record of what was checked is closer to a visit than an inspection. And in an audit or after an incident, what gets requested is the detail.

Checklists support fields with their own type, label, and minimum and maximum values — clearances, cable condition, safety gear and governor operation, emergency lighting, two-way communication — so a reading outside range is logged as an anomaly on the spot, not as a margin note.

On preventive orders, the app won’t let you close the order until the checklist is complete, which in this sector is exactly the guarantee that matters.

Without coverage, which is the norm

A machine room, a pit, or the inside of a shaft are places with no signal.

The app stores orders, assets, and documents on the device itself, and every action taken offline — changing status, logging time with the timer, consuming materials, completing the checklist, capturing a signature — enters a queue that clears once coverage is back. If one fails to sync, it’s flagged with its reason instead of being lost.

Without that, the technician writes on paper and transcribes it later, and the values end up rounded and the hours underreported.

The alerts that can’t wait

An entrapment isn’t just another incident. The system needs to be able to distinguish it and measure it.

Incidents carry their type and subtype, priority, client, address, and affected unit, and statuses can each carry their own maximum time. There’s also an SLA entity with its name, priority, and limit, and the incident’s timings are logged.

That allows two things: what’s overdue shows up on a list instead of being discovered when the client complains, and afterward you can measure separately how long it takes to respond and how long to resolve — which aren’t the same thing, and in this sector both get audited.

Alerts can come in from the backend, from the client’s access with a photo, or from an email inbox that the system converts into incidents.

The documentation, which is half the job

Maintenance log book, inspection reports from the control body, certificates, manufacturer manuals, service contracts, insurance policies.

The document manager attaches documents to the unit, the building, the client, the provider, or the order, decides who can see them — client, technician, provider — and sets an expiration date, with a daily check for anything about to expire and its corresponding alert. Certificates carry their number, scope, issuer, and holder.

Across a fleet of units, that expiration alert is what prevents the one problem money can’t fix afterward: an inspection that lapsed without anyone noticing.

If you’re the maintenance company

The preventive plan isn’t an internal decision: it’s the contract. If it calls for twelve visits a year and only eleven happen, that’s a contractual problem before it’s an operational one.

That’s why the report signed at the unit — with its measured times, materials, and the signature captured on screen — is what backs up the invoice. And client access cuts down on the calls that only ask how things are going: the building community or manager can see the status of their orders, download the reports, and check upcoming inspections.

Since licenses are unlimited on all three plans, giving access to every building community and property manager isn’t a financial decision. There’s more detail in third-party maintenance.

If you’re the one hiring the service

Here the problem is the opposite: verifying that you’re getting what you’re paying for.

Registering the maintenance company as a provider means their orders get recorded in your system, with their times and documentation, instead of in a folder of theirs. And the annual plan executed report answers the uncomfortable question: how many visits were scheduled and how many actually happened.

What to look at afterward

Reports on executed plan, anomalies, response and resolution times by priority, cost per unit, and downtime.

The most revealing one is usually the cross-reference between anomalies and model: when a fault repeats on the same model across the whole fleet, it stops being a breakdown and becomes an argument with the manufacturer.

If you’d like to see it with your own fleet, you can request a demo.