Running a lift maintenance company on a generic FSM platform is like using a general-purpose accounting package to manage an engineering firm's project pipeline. It works, up to a point. Then you hit the edges, the things your business actually needs, and the workarounds start stacking up.
The pattern is consistent: companies outgrow generic tools not because of volume, but because of specificity. Elevator maintenance has requirements that most FSM vendors simply haven't built for, because their primary market is HVAC, plumbing, and electrical contractors. Lift companies are a smaller segment, and the vertically specific features get deprioritised.
This guide walks through the eight capability areas that matter most when evaluating elevator maintenance software, the questions to put directly to vendors during demos, and the red flags that tell you a platform wasn't built for this industry.
Why generic field service management software falls short
Generic FSM software is built around a workflow that goes: customer calls in, dispatcher creates a job, technician gets assigned, job completes, invoice raised. That sequence works for most trades. For elevator maintenance, it breaks down in three places.
No shaft-level asset tracking
A generic FSM platform tracks assets at the location or equipment level. You can record that a building has two lifts. What you can't do is maintain independent service histories, compliance records, and component logs for Shaft 1 and Shaft 2 as distinct entities. Parts consumption, governor tests, door operator replacements, buffer inspections, these all attach to the shaft, not the building. Without shaft-level granularity, your maintenance records don't reflect how the equipment is actually managed.
No emergency call identification
EN 81-28 requires that every elevator has a two-way communication device, and those devices dial out using a SIM card or VoIP line. When a trapped passenger activates the emergency phone, your operations centre receives a call from a phone number. A generic FSM platform has no way to map that inbound number to a specific shaft and building. Your dispatcher has to consult a separate spreadsheet, look up the number, identify the location, then manually search for the asset. This typically takes 3–5 minutes. EN 81-28 and the rescue SLA you've committed to in your service contract don't give you 3–5 minutes of identification overhead.
No trapped passenger rescue workflow
Trapped passenger rescue is a time-critical, multi-step process with a defined SLA, typically 60–90 minutes from initial contact to passenger out of car. Generic FSM tools have no concept of this. There's no built-in timer, no escalation path when the primary technician doesn't acknowledge, no automatic notification to the building owner at the 30-minute mark, and no structured log that proves you met the SLA for liability purposes.
These aren't gaps you can paper over with custom fields and clever workflow configuration. They're architectural limitations.
The 8-capability evaluation framework
When assessing any platform marketed as lift maintenance management software, these eight capabilities separate purpose-built solutions from repurposed generics.
1. Phone-to-shaft asset mapping
The emergency phone in every elevator has a registered number. When that number calls your operations centre, the software should identify, without any manual lookup, the exact shaft, the building, the active service contract, the SLA clock that just started, and the nearest qualified technician.
This capability depends on a database of phone number-to-asset mappings maintained in the platform. It's not a feature most generic tools offer because their customer base doesn't have elevator emergency phones. Ask the vendor specifically:
"When an EN 81-28 emergency phone activates and calls our dispatch number, what does your system display, and how quickly?"
If the answer involves any manual step, looking up a number, switching to a different screen, consulting an external list, the platform isn't built for this.
2. EN 81-28 compliance tracking
Monthly functional tests of the two-way communication device are a legal requirement. Annual independent inspections are mandatory. After any modification to the communication system, retesting is required.
Your software needs to:
- Log each monthly test with result, date, and technician signature
- Generate a test record that satisfies the format inspectors expect
- Alert when a monthly test is overdue on any shaft
- Maintain the full test history per shaft for the duration of the service contract (minimum 5 years recommended for audit purposes)
This is different from general PPM (planned preventive maintenance) scheduling. The test log format, the regulatory context, and the inspector's expectations are specific to EN 81-28. A platform that describes this as "you can use our custom form builder" is telling you they haven't built it properly.
3. Trapped passenger rescue workflow with SLA timers
From the moment the emergency phone activates, the clock is running. A properly built elevator platform handles this as a structured workflow:
- T+0: Emergency call received, shaft identified automatically, rescue job created
- T+0–2 min: First technician acknowledged and dispatched
- T+30 min: Automated notification to building owner/facilities manager if passenger not yet released
- T+60/90 min: SLA breach alert, escalation to operations manager
- T+resolution: Structured close-out log with trapped duration, cause code, and corrective action
Ask vendors:
"Show me what happens in your system from the moment an emergency phone call comes in to the moment the passenger is confirmed out of the car."
Walk through it in the demo. If they can't demo a complete flow, it doesn't exist.
4. Shaft-level service history
A building with six lifts has six maintenance histories, not one. Door operator failures in Shaft 3 are not the same failure as a governor issue in Shaft 6. The components, the technician notes, the parts consumed, and the compliance status are distinct.
A platform that stores maintenance history at the building level forces technicians to search through all jobs for a location to find what happened to a specific shaft. This is time-wasting in routine maintenance visits and genuinely dangerous in fault diagnosis, you can miss a recurring failure pattern because the history is mixed across multiple shafts.
Test this directly: ask the vendor to show you the service history for a single shaft in a building that has multiple lifts. If the view defaults to building-level and requires filtering, that's a signal the data model wasn't designed for shaft-level tracking.
5. Modernisation project tracking
Full replacements and modernisation projects run differently from routine maintenance. You're managing a project with a scope of work, a parts list (controller, traction machine, door operator, new car, rope set), a commissioning programme, and a handover inspection. Some of these projects run 4–8 weeks with multiple visits from multiple technicians.
Generic FSM platforms handle reactive jobs and PPM visits reasonably well. They typically fail on:
- Multi-phase project job structures
- Bill of materials tracking per shaft being modernised
- Progressive sign-off workflow (installation complete → commissioning → final inspection → handover certificate)
- Retaining pre-modernisation history linked to the same shaft asset
If your business does substantial modernisation work alongside routine maintenance contracts, this capability gap costs you real time in job administration.
6. Elevator-specific parts inventory
An elevator maintenance company's parts store looks very different from a plumbing or HVAC storeroom. You're holding:
- Door operators (brand-specific: Fermator, GAL, Wittur)
- Governor assemblies
- Buffer units (hydraulic, polyurethane, spring)
- Traction machine components (brake liners, sheave sets)
- Car and counterweight suspension ropes
- Control boards (often proprietary to the original manufacturer)
- Safety gear sets
- Door contact boards and cam assemblies
Parts need to track not just quantity but:
- Compatibility (which elevator models and shaft types they fit)
- Batch/lot numbers for traceability
- Supplier lead times (some components are 8–12 weeks from the manufacturer)
- Consumption per shaft (not per building)
Ask: "Can your parts inventory track which shaft a component was consumed on, and link that consumption to the specific job?"
7. Offline mobile capability in machine rooms
Elevator machine rooms are not WiFi-friendly environments. Many are in basements, inside concrete shafts, or at the top of buildings with no signal. A mobile app that requires a live connection to load job details, capture technician notes, or log parts consumption is a tool technicians will stop using.
The minimum requirement for offline capability:
- Job details and asset history preloaded before the technician leaves the depot
- Ability to complete checklists, log parts, add notes, and capture signatures without a connection
- Background sync when connectivity is restored, without data loss or duplicate records
Ask the vendor to show you their offline mode in the demo. Specifically: disconnect the device from the network, complete a mock job including parts logging and signature capture, reconnect, and verify the data synced correctly. If they can't demo this in under 10 minutes, the capability is either immature or non-existent.
8. Multi-building contract management
Elevator maintenance companies rarely manage a single building. A medium-sized operation might hold maintenance contracts for 200–800 shafts across 80–200 buildings. Those contracts have different terms: monthly visits for some, quarterly for others; different SLA commitments; different billing cycles; different contact trees for emergencies.
The software needs to:
- Store the contract terms per customer and per site
- Generate scheduled visits automatically according to the contract frequency
- Alert when a contracted visit hasn't been completed before its due date
- Track compliance against the contract (number of visits completed vs. required, for example)
- Bill from the contract structure rather than from individual jobs
This is contract-aware scheduling, which is a different capability from ad hoc job creation. Many generic platforms bolt this on as an afterthought and deliver something that requires heavy manual administration.
Questions to ask every vendor
Beyond capability demos, these specific questions tend to reveal whether a platform was built for elevator maintenance or retrofitted from something else:
"Can your system identify which specific shaft is calling when an emergency phone activates?" If the answer is anything other than "yes, automatically, within seconds," dig into how they expect you to handle the manual gap.
"How do you track EN 81-28 compliance test logs across a portfolio of 400 shafts?" You're looking for a built-in compliance module with per-shaft test history, automated overdue alerts, and export formats that work with your inspection body.
"Does your mobile app work fully offline in elevator machine rooms, including parts logging and signature capture?" Request a live demo with the device disconnected. If they can't do this in the demo, it won't work in a basement.
"Can technicians log parts consumption per shaft, not per building?" This tests whether the asset model is shaft-level or building-level. The answer tells you a lot about the underlying data model.
"Show me a trapped passenger rescue job from the moment the call comes in to the signed close-out record." If they can show you the complete flow, automatic identification, SLA timer, escalation alerts, structured close-out, you're looking at a platform built for lift companies. If they need to "configure that workflow," it's not there yet.
"How do you handle a six-shaft building where each shaft has a different maintenance contract and a different SLA?" This tests contract-to-asset granularity. The answer should be "each shaft has its own contract terms" not "we manage contracts at the building level."
Platform comparison framework
Rather than rating individual vendors, it's more useful to assess platforms against a capability matrix. When you sit through demos, score each platform across these dimensions:
| Capability | What to Look For | Red Flag |
|---|---|---|
| Asset model | Shaft-level records, independent histories | Building-level only, or "custom fields" workaround |
| Emergency call identification | Automatic number-to-shaft mapping, sub-10-second display | Manual lookup, external spreadsheet required |
| EN 81-28 compliance | Built-in test log module, automated overdue alerts | Generic form builder, no standard compliance template |
| Rescue workflow | Structured flow with SLA timers and escalation | "You can configure a job type for this" |
| Offline mobile | Genuine offline mode with sync, demonstrated in demo | "Our app works on mobile" without offline demo |
| Parts inventory | Elevator-specific component tracking, shaft-level consumption | Generic stock module with no elevator component context |
| Modernisation projects | Multi-phase job structures, BOM tracking, commissioning sign-off | Single-job model only |
| Contract management | Per-shaft terms, automated visit scheduling, contract billing | Building-level contracts, manual scheduling |
Score platforms on a simple 0–2 scale per capability (0 = not present, 1 = partial/workaround, 2 = built for purpose). A platform scoring below 12/16 will require constant workarounds in daily operation.
Red flags during evaluation
These responses during a vendor demo should prompt harder questions:
"You can configure that with our workflow builder." Configuration is not the same as purpose-built capability. Workflow builders produce brittle solutions that break when a user does something unexpected and generate maintenance overhead for your operations team.
"Most of our customers use it like this." If "most customers" are HVAC or plumbing companies, the product has been designed for their workflow. The edge cases your business needs, EN 81-28 compliance logs, shaft-level histories, emergency phone mapping, may not be on the product roadmap.
"We're building that in the next release." Roadmap promises mean nothing unless you're buying with an SLA-backed feature delivery commitment. Evaluate on what exists today.
"Our API lets you build whatever you need." This means the platform can't do it out of the box. You're being asked to fund and maintain bespoke development on top of a platform you're also paying a licence fee for.
The demo runs entirely on sample data. Insist on seeing the platform in a configuration that approximates your business: multi-shaft buildings, EN 81-28 test records, emergency call workflows. If the vendor won't configure a real demo environment, their reason is usually that doing so would expose limitations.
Migration considerations
Switching platforms is disruptive. For elevator maintenance companies, the migration complexity is higher than for other trades because the data you're moving includes:
- Shaft-level maintenance histories, some going back years
- EN 81-28 test logs that inspectors may request retroactively
- Emergency phone number-to-shaft mappings (losing these means your operations centre goes dark until they're re-entered)
- Component histories (when was the governor last tested, when was the traction machine last serviced)
- Service contract terms and renewal dates
Before committing to any platform, get clear answers on:
Data import format. Can the vendor accept your existing data? What format do they expect? Who bears the cost of transformation if your current system exports in a non-standard format?
Phone number mapping migration. This is often overlooked. Confirm the new platform can bulk-import your emergency phone number registry before you go live. A manual re-entry process for 400+ shafts takes weeks.
Historical compliance records. EN 81-28 test logs and inspection certificates need to be accessible in the new system, not just archived in the old one. Ask how the vendor handles this, native import, PDF attachment, or linked external storage.
Parallel operation period. For the first 2–4 weeks after go-live, you'll likely be managing some work in the old system and some in the new. Establish how long you need to maintain both and build that into the project plan.
Technician training timeline. Technicians who are comfortable with the old system will resist change. Plan for at least two full training sessions per technician group, not a single 30-minute demo.
FAQ
What's the difference between elevator maintenance software and generic FSM software?
The core difference is the asset model and the compliance layer. Generic FSM tools track assets as equipment at a location. Elevator maintenance software tracks shafts as independent entities with their own service histories, compliance records, and emergency phone mappings. The compliance layer in a purpose-built lift platform handles EN 81-28 test logs, inspection certificates, and trapped passenger rescue workflows as first-class features, not workarounds built on top of a generic job management system.
Does our company need elevator-specific software, or can we use a general FSM tool?
That depends on the volume and complexity of your portfolio. If you manage fewer than 30 shafts and your primary need is job scheduling and invoicing, a general FSM tool may be sufficient. If you manage 100+ shafts, hold EN 81-28 compliance obligations, respond to trapped passenger calls, and need shaft-level service histories, a general tool will cost you more in manual workarounds than a purpose-built platform costs in licence fees.
How long does it typically take to migrate from a spreadsheet or generic system to a specialist elevator platform?
For a company managing 200–400 shafts, budget 8–12 weeks from contract signature to go-live. The bulk of that time is data preparation, mapping your existing asset records, phone numbers, service histories, and contract terms into the new system's format. Platforms that provide a dedicated implementation team and data migration tooling can compress this to 6 weeks. Pure self-service implementations rarely complete in under 3 months without cutting corners on historical data.
What should we do if a vendor claims their platform handles all our elevator-specific requirements?
Verify through demonstration, not claims. Ask them to walk through each of the eight capability areas in this guide using their actual software, configured with elevator scenarios. A vendor who can't demo trapped passenger rescue workflow end-to-end, or who can't show shaft-level service history for a multi-shaft building, hasn't built what they're describing.
How important is mobile offline capability in practice?
More important than most vendors acknowledge. Elevator machine rooms, particularly those in older buildings, basements, and concrete structures, routinely have no mobile signal. A mobile app that can't function offline means technicians are writing notes on paper and entering them when they get back to the van. That introduces transcription errors, delays, and data gaps in compliance records. For EN 81-28 monthly test logging specifically, offline capture with tamper-proof sync is the only reliable approach in environments with poor connectivity.
For a detailed look at EN 81-28 requirements and how to build a compliant testing programme, see our EN 81-28 Compliance Checklist. If you're specifically focused on reducing rescue response times, How to Reduce Trapped Passenger Rescue Time covers the operational side in detail. For a broader view of FSM software evaluation across verticals, the Field Service Management Software Buyer's Guide provides the cross-industry framework.
View RemoteOps pricing or explore the elevator and escalator industry page to see how the platform handles shaft-level asset management.