Put the phone in airplane mode
And ask them to close a whole work order: status, hours, material, checklist and signature. It’s the test that most products fail.
Guide
In a demo it’s shown by someone who knows it, with good coverage, no gloves and no rush. In other words, none of the conditions it’ll actually be used in.
Because it’s where the record gets created, and the value of a CMMS is exactly proportional to the quality of that record. All the configuration, all the reports and all the integrations you set up rest on job sheets someone fills in on site, often in a hurry and often without coverage. If that step fails, nothing else matters: you’ll have a very complete system fed with incomplete data. That’s why the app deserves more attention in the evaluation than it usually gets, which is typically one slide in a presentation.
Six tests you can run in a demo, and they tell products apart fast.
And ask them to close a whole work order: status, hours, material, checklist and signature. It’s the test that most products fail.
How many it takes from opening the app to closing a simple work order. Multiply that by a day’s worth of jobs.
How many steps it takes to see what was done last time. If it’s more than two, the technician won’t check it.
Technical documentation has to be on the device, not behind a download.
With twenty items and a photo. This is where you see whether the screen was designed to work with or to demo.
With item search included. If it’s a hassle, the technician won’t log it, and your cost per work order will be fiction.
Almost every product claims to work offline, and it means very different things. You need to ask three specific questions. What gets stored on the device: only the open work order, or all work orders, assets and documents? What actions can be done without signal: only writing text, or also changing status, consuming material and signing? And what happens if something fails while syncing: is it lost, retried, or flagged with the reason so someone sees it? The third is the one that tells the most, because it reveals whether the product was designed for the bad case or only for the good one.
Have one of your own technicians use it, not you. Five minutes with the app in the hands of whoever will actually work with it says more than an hour of a well-rehearsed demo, because they’ll do exactly what they do day to day: search fast, type little and understand the screen without anyone explaining it. If it’s hard for them, it’ll be hard for the whole team, and no office-side argument will fix that. It’s also the cheapest way to get the project an ally inside the team before it even starts.
Leave your details and we will get in touch to see whether we fit. No commitment, no lock-in period.
Many of the apps sold as maintenance apps are just the desktop screen crammed into a phone, and it shows within two minutes: nested menus, long forms, lists you have to filter. A tool actually built for the field is recognized by specific things. It opens straight into today’s work, with nothing to search for. Buttons are big because they’re used with gloves and one hand. It auto-fills everything the system already knows, so the technician only enters what only they can know. It works without coverage, because the places where maintenance happens are exactly the places with no signal. And it never asks you to confirm anything three times. None of these traits shows up on a feature comparison table, and together they decide whether the app gets used or stays in someone’s pocket.
There’s a difference in quality, not just convenience, between logging work at the moment and writing it up later that afternoon. The time is the real one, not the approximate one. The photo exists, because taking it there costs two seconds and taking it later isn’t possible. The reading is what the instrument actually showed, not what someone remembers. The material is what was actually consumed, not what someone thinks was consumed. And above all, the detail nobody ever writes up afterward shows up: what was noticed in passing, what’s worth checking next time, the warning that a part is close to its limit. That detail is exactly what turns a history into something useful two years from now, and it’s the first thing lost when the record happens somewhere else, at some other time.
Not necessarily, but it’s worth deciding explicitly instead of letting it slide. A company phone avoids the conversation about personal data and about what happens when someone leaves; a personal device lowers the cost of getting started. What doesn’t work is not deciding at all, because then both exist side by side and nobody knows what happens when a phone gets lost.
Closing a whole work order in airplane mode, counting how many taps it takes, looking up the equipment’s history, opening a manual with no connection, filling in a long checklist, and logging material used.
It depends on the product, which is why you need to ask three things: what’s stored on the device, what actions can be done without signal, and what happens if something fails while syncing. The third is the one that tells the most.
One of your own technicians, not you. Five minutes in the hands of whoever will actually use it says more than an hour of demo, and the project gains an ally inside the team along the way.
Because the value of a CMMS is proportional to the quality of the record, and the record happens in the app. If that part fails, you’ll end up with a very complete system fed with incomplete data.
In the demo we put the phone with no coverage and close a whole work order. It’s the test we recommend running with every provider.
Accessibility
Saved in this browser. Light or dark theme is set from the footer.