Skip to content
GMAO CLOUD
en

Guide

The app is the part that’s evaluated worst and decides the most

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.

Why the app makes or breaks the project

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.

What to test, and how

Six tests you can run in a demo, and they tell products apart fast.

  • 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.

  • Count the taps

    How many it takes from opening the app to closing a simple work order. Multiply that by a day’s worth of jobs.

  • Fill in a long checklist

    With twenty items and a photo. This is where you see whether the screen was designed to work with or to demo.

  • Log material used

    With item search included. If it’s a hassle, the technician won’t log it, and your cost per work order will be fiction.

The offline question, made precise

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.

And a test that isn’t technical

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.

Shall we look at it with your way of working?

Leave your details and we will get in touch to see whether we fit. No commitment, no lock-in period.

We reply within one working day.

What sets a field app apart from a shrunken management app

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.

Data captured where it happens is different data

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.

Frequently asked questions

Do technicians need company-owned phones?

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.

What should I test in a maintenance app?

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.

What exactly does "works offline" mean?

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.

Who should test the app?

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.

Why does it matter so much?

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.

Try it in airplane mode

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.