Free GMAO Cloud demo: how to make the most of it

A maintenance software demo can be two very different things. It can be a presentation built on a sample dataset, where everything works because it’s set up to work. Or it can be half an hour about your equipment, with your checklists and your periodicities, where you immediately see what fits and what doesn’t.

The second one is the one that’s actually useful, and it largely depends on what you bring prepared. This article is about that.

What to bring

You don’t need the full inventory. This is enough, and it completely changes the conversation:

• Two or three real assets, ideally different from each other: one critical, one under mandatory maintenance and one ordinary.
• What’s done to them and how often. The checklist of checks, even if it only lives in someone’s head. It’s what lets you see preventive maintenance actually being generated.
• A typical breakdown case, one of the ones that repeat. It’s useful to see the full circuit from issue to a closed work order.
• How requests reach you today. Phone, email, WhatsApp, a shared spreadsheet. It determines how the intake should be configured.
• What report you’re asked for. The one you have to submit every month or quarter and currently put together by hand.

What you’ll see in the demo

The useful walkthrough follows the order things actually happen in, not the order of the menu.

How work comes in. The issue with its type, priority, customer, address and affected equipment; and the channels it can arrive through, including customer access and the mailbox the system turns into issues automatically.

How preventive maintenance is generated. The checklist tied to the asset, its model or an entire family, with its periodicity. Two details worth noticing here: it can be configured by family — two hundred identical pieces of equipment, one configuration — and the system checks holidays and technician availability before generating the order.

How the technician works. This is the part you absolutely have to see, ideally with a technician present. In the app: the stopwatch inside the order, material consumption from the warehouse, the checklist that won’t let a preventive order close if something’s missing, photos, the customer’s signature on screen, and offline operation with later synchronization.

What’s left afterward. The equipment’s history and the reports: cost per asset, hours per technician and per customer, downtime, MTBF and MTTR, the annual preventive plan executed.

What your customer sees. Their own access: their orders, their job reports to download and their upcoming preventive visits on a calendar.

Questions worth asking

The ones that are hard to answer well afterward and save you headaches if asked beforehand.

How is it priced, and what happens if we grow? In GMAO Cloud licenses are unlimited across all three plans, so adding your team, customers and subcontractors doesn’t change the price. With a per-user model, it’s worth doing the math with your headcount three years from now.

What has to be set up before this is useful? There’s always startup work: assets, checklists and periodicities. Ask how long it takes, who does it and how much of it the vendor supports.

Does it connect to our ERP, and with exactly what scope? The generic answer is usually yes. The useful one is what data travels and in which direction, because not every connector works both ways. The integrations page has the detail for each one.

How do we get our data out if we ever leave? It’s an uncomfortable question, and it’s exactly the one to ask.

What happens to old versions? What happened to customers the last time there was a major version change, and who handled the migration.

Who should attend

Not just whoever signs off. The demo is usually watched by whoever plans, but the system gets fed by whoever’s in the field.

It’s worth having three roles present: the maintenance manager, who looks at planning and reports; a technician, who is the one who’ll spot in two minutes whether the app is going to waste their time; and whoever answers the phone or handles requests, who really knows how work comes in today.

Signs the demo went well

It’s not that you liked the interface. It’s three more concrete things.

You saw your own case, not an example. If by the end of the session your assets are set up with their checklist and periodicity, and there’s a preventive order generated with a date and an owner, you’ve seen the system. If you saw a presentation with sample data, you’ve seen a brochure.

Someone said something couldn’t be done. That’s a good sign. All software has limits, and a vendor who states them during the demo is one that won’t surprise you in month three. Be wary of the systematically affirmative answer.

The technician didn’t pull a face. It’s the most predictive indicator of all, because the system gets fed by them. If they asked questions — how hours get logged, what happens if coverage drops, whether they have to type something twice — it means they’re imagining themselves doing the job, which is exactly what you want.

What not to expect from a demo

That it settles the whole decision. A demo shows whether the tool fits how you work; it doesn’t say whether how you work is the right way, and that’s sometimes the important conversation.

A CMMS doesn’t fix a process that doesn’t exist: if nobody today decides who handles what and at what priority, the system will record the same disorder with more precision. And it doesn’t guarantee compliance with any regulation either: what it does is leave proof of what was done, with its date and its author.

After the demo

The most useful thing you can do is a bounded trial: a small group of critical assets with their checklists and periodicity, over a few weeks, with orders genuinely being closed out in the field. It’s the only way to know whether the team will actually use it, which is the question that decides the project.

You can request the demo here or write to us telling us about your case.