Facility Management Software: How to Choose

Most facility management software selections go wrong long before anyone looks at a demo. They go wrong in the first week, when somebody writes "we need an FM system" at the top of a requirements document without deciding which kind of FM system they mean. From that point on the shortlist is arbitrary, the demos are incomparable, the scoring is theatre, and the product that wins is usually the one whose salesperson was most reassuring rather than the one that fitted the operation. I have sat on both sides of that process across CMMS, CAFM, EAM and ERP implementations, and the pattern is consistent enough to be predictable.

The message up front: the single most valuable decision in an FM software selection is not which vendor to buy, it is which category of product your organisation actually needs. Get that right and even a mediocre product in the correct category will serve you. Get it wrong and the best product in the wrong category will be abandoned within two years. Decide the category first, weight the modules second, and only then go looking at vendors.

1. Why the term is overloaded, and what buyers are actually shopping for

The phrase "facilities management software" survives because it is convenient for marketing and useless for procurement. Facilities management as a discipline covers everything from unblocking a toilet to modelling a twenty year lifecycle replacement plan for a portfolio of buildings. No single product does all of that well, so vendors pick a centre of gravity, build outwards from it, and then describe the whole thing with the broadest available label.

When a facilities manager says "we need FM software", what they usually mean is one of five quite different things:

• A helpdesk and service request system. The pain is that requests arrive by phone call, WhatsApp message, corridor conversation and email, nothing is logged, nobody knows what is outstanding, and the FM team has no evidence of the volume it absorbs. The need is intake, triage, assignment, status visibility and a record.
• A maintenance management system. The pain is that planned maintenance lives in spreadsheets, statutory tasks get missed, corrective work is not tracked to closure, and there is no asset history. The need is an asset register, PPM scheduling, work order lifecycle and maintenance history.
• A space and occupancy system. The pain is that nobody can say with confidence how much space the organisation holds, who occupies it, how densely it is used, or what a move will cost. The need is floor plans, space allocation, occupancy data and move management.
• A contractor and vendor management system. The pain is that most of the actual work is delivered by third parties whose performance nobody measures, whose permits nobody tracks, and whose invoices nobody can reconcile against work done. The need is contractor onboarding, work allocation, SLA measurement and verification.
• All of the above as a single integrated suite. This is where integrated workplace management systems live, and it is a legitimate need for large, mature, multi-building organisations with the internal capability to run it. It is also the category most often sold to organisations that needed one of the four simpler things.

These five are not points on a maturity ladder where the suite is simply the best version. They are answers to different questions. An organisation whose real problem is that requests vanish into the ether does not need occupancy analytics, it needs a helpdesk that works on a phone and an FM team disciplined enough to close tickets. The formal category definitions, what separates CAFM from CMMS from EAM from IWMS, are worked through properly in the CAFM vs CMMS vs EAM vs IWMS comparison, and the decision logic between them in which of CAFM, CMMS or EAM is right for you. I am not going to restate that taxonomy here. This guide assumes you have read it and now have to choose a product.

Two more terms you will meet on vendor sites deserve a short translation. "Computer aided facility management software" is the older European label for what most people now call CAFM: building and space centric, floor plan aware, helpdesk plus maintenance. "Integrated facility management software" is ambiguous and worth challenging on every call, because it sometimes means a technically integrated software suite and sometimes means software aimed at organisations that buy integrated facilities management as a bundled service contract. Those are different products. The service delivery model itself is covered separately in integrated facility management explained; here it matters only because the label appears on software that does not always deserve it.

2. Which product do you actually need: a decision table

Before any shortlist, work through this table honestly. The test is not which row sounds most impressive, it is which row describes the thing that is currently costing you time, money or reputation. Pick the row that hurts, not the row you aspire to.

3. The functional modules and how to weight them

Once the category is settled, the work is to decide which modules carry real weight and which are pleasant extras. Almost every vendor will tick almost every box on a feature list, which is why feature lists are close to worthless as a selection tool. What separates products is depth in specific modules, and depth only matters where you will actually work.

The eight modules that account for most of the value in facility management software:

• Helpdesk and service requests. Multi channel intake, categorisation, automatic routing, priority and SLA assignment, requester self service and status visibility. Judge it on how few taps it takes an ordinary building user to raise a useful request, and on whether the triage rules can be maintained by an FM administrator rather than a consultant.
• Work order management. The lifecycle from raise to assign to execute to verify to close, with labour and material capture, parent and child work orders, and rework linkage. Depth here shows in the awkward cases: a job that needs two trades on different days, a job that becomes a project, a job a contractor executes but your supervisor must verify.
• Asset register. Hierarchy, classification, attributes, location, criticality, warranty, documents, cost history. This is the module that quietly determines whether the system is useful in year three. A thin asset register cannot carry PPM, reliability analysis or lifecycle planning later.
• PPM scheduling. Calendar based and meter based schedules, task lists and checklists, seasonal and statutory regimes, workload levelling, and a forward view your team can actually resource. Ask specifically how a schedule that was missed is handled, because the naive answers cause compliance problems.
• Space and moves. Floor plans, space classification, allocation to departments or cost centres, occupancy capture and move scenarios. Weight this heavily if you are an occupier with churn, and lightly if you run a single industrial site where space barely changes.
• Contractor and vendor management. Contractor records, insurance and competency expiry, portal access scoped to their own jobs, SLA performance by vendor, and a verification step before payment. If subcontractors deliver most of your work, this module is not optional and it is where many otherwise good products are weakest.
• Compliance and statutory records. Certificates against assets, inspection regimes, expiry alerting, permit to work, audit trail and evidence packs. Judge it by whether you could satisfy an external auditor from the system alone, without a parallel folder structure.
• Reporting and analytics. Out of the box operational reports, an accessible query or report builder, scheduled distribution, and clean data export or a documented API. A product whose reporting requires a vendor change request for every new question becomes a bottleneck fast.

Weighting is where organisation type matters more than anything else. The same module list, weighted for a school estate, a hospital, a landlord and a service provider, produces four different shortlists.

Notice what does not vary: PPM scheduling and compliance are high for everyone, because every operator has statutory obligations and a planned regime. What varies most is space, client reporting and lifecycle planning, and those three are exactly the modules that push a buyer towards or away from a full suite.

4. In house team, service provider, landlord: three different products

The most consistent selection error after category confusion is buying a product designed for a different kind of organisation. The three main shapes need genuinely different software, and the differences are structural rather than cosmetic.

The in house FM team serving one organisation. Your users are colleagues. Your priority is low friction intake, credible planned maintenance, statutory compliance evidence, and enough reporting to defend your budget internally. You do not need contract profitability or client billing. You do need the helpdesk to be so easy that people use it instead of stopping you in the corridor, because unlogged work is the root of every other problem you have.

The FM service provider delivering to clients. Your software is part of what you sell. You need multi client separation so client A never sees client B, per contract SLA regimes because every contract was negotiated differently, client facing reporting that stands up in a monthly review meeting, and a view of whether each contract is profitable. A product built for in house teams will bend into this shape badly, usually by cloning the whole configuration per client, which becomes unmaintainable by the fourth contract. The SLA structures underneath this are worked through in the SLA matrix design guide.

The landlord or asset owner with occupiers. Your split of responsibility is the defining complexity. Some assets are yours, some are the tenant's, some are shared, and the software must know which so that the right party is billed and the right party is chased. You also care about lifecycle condition and capital planning in a way an occupier does not, because you own the fabric. Ask every vendor how they model landlord versus occupier responsibility on a single asset, and how recharge works. The vague answers are informative.

5. Single site, multi site, multi client: what changes

Scale changes which questions matter, and it changes them discontinuously rather than gradually. A product that is excellent on one site can be unworkable across thirty.

On a single site, almost everything is tractable. One location hierarchy, one team, one set of SLAs, one calendar. Selection can focus almost entirely on usability and on maintenance depth, and a simpler product is usually the better choice.

Multi site introduces problems that do not exist at one site: whether standards are enforced centrally or set locally, how a technician covering three buildings sees their day, whether reporting rolls up consistently when each site has named things differently, and how permissions keep a site manager inside their own estate while a regional manager sees several. The naming and hierarchy discipline matters more than any feature, and it is worth reading the multi site CAFM architecture guide before you write requirements, because the architectural decisions constrain which products can serve you at all.

Multi client tenancy is a different order of requirement again, and it is the one buyers most often assume is present. Genuine multi client support means data separation enforced by the platform, not by discipline; per client configuration of SLAs, categories and approval rules without cloning; client users who can only see their own estate; and reporting that can be issued per client and consolidated internally. Ask to see two clients side by side in a live demo tenant. A vendor who can only show one client at a time is telling you something.

6. Integration: HR, finance, BMS and access control

FM software is never an island, and integration is where implementations lose months. Four integrations come up in almost every selection, and each has a characteristic failure mode.

• HR and identity. People join, move and leave, and if the FM system holds its own user list it will drift within months. What you want is single sign on against the corporate directory and, ideally, automatic provisioning and deprovisioning. The failure mode is a manual user list nobody maintains, which quietly becomes a security finding and a licence cost.
• Finance and ERP. Purchase requisitions, purchase orders, goods receipt, invoice matching and cost posting. The decision to settle early is where the master record for suppliers, cost centres and budgets lives, because two systems each believing they own the supplier master will cost you every month. Usually finance owns it and FM consumes it. The mechanics are covered in the CAFM to ERP integration guide.
• BMS and building systems. Alarms from the building management system becoming work orders is the classic requirement and the classic disappointment, because an unfiltered alarm feed will bury your helpdesk. The design work is in filtering, deduplication and mapping alarms to assets and to actionable jobs. The reference pattern is in the BMS to CAFM integration architecture.
• Access control and permits. On secured or industrial sites, contractor access, induction status and permit to work need to line up with the work order. Weak handling here is a genuine safety exposure, not just an inconvenience, and it is worth asking how the system prevents a job being dispatched to a contractor whose induction has lapsed.

The question I would put to every vendor is not "do you integrate with X", because the answer is always yes. It is: show me the API documentation, tell me which direction data flows, tell me what happens when the target system is unavailable, and tell me who supports the integration in year two. Integration that exists as a professional services project rather than a documented interface will become your problem the moment the implementation partner leaves.

7. Mobile and technician adoption

A facility management system succeeds or fails at the point where a technician standing in a plant room decides whether to use it or to write on a scrap of paper and update it later. Everything upstream, the reporting, the compliance evidence, the analytics, depends on data captured at that moment. This is the part of the evaluation most often delegated to a five minute demo slide, and it deserves a day.

What actually determines technician adoption:

• Offline capability that works. Basements, risers, lift shafts and plant rooms have no signal. The app must queue work offline and sync cleanly, including photos, and it must handle the case where two technicians updated the same job while offline.
• Few taps to complete a job. Count them in the demo. A PPM task with a ten point checklist, a photo and a signature should not take fifty interactions. If it does, your checklists will be completed in the van at the end of the shift, which is the same as not having them.
• Asset identification in the field. QR or barcode scanning that opens the asset record, its history and its open jobs. Typing an asset number into a phone is how the wrong asset gets updated.
• Language and literacy reality. In many operations, particularly across the Gulf, technicians work in a second or third language. Icon led interfaces, translated labels and picture based checklists are not nice to have, they are the difference between accurate data and fiction.
• Device reality. Test on the actual phones your team carries, in the actual buildings, with the actual gloves. Not on the vendor's tablet on conference wifi.

8. Data migration and the asset register trap

Two sources feed a new FM system: spreadsheets, and a legacy system. They fail differently. Spreadsheets are incomplete but honest, and their gaps are visible. Legacy systems are complete looking and often quietly wrong, carrying a decade of duplicate assets, retired locations, and codes nobody can explain. Migrating a legacy system uncritically is how an organisation pays to move its data problems into a more expensive home.

What I would advise on migration scope is deliberately narrow. Bring across the asset register, the location hierarchy, the PPM regimes, open work orders, and compliance certificates that remain valid. Leave closed work order history in the old system as an archive unless there is a specific analytical reason to move it, and if you do move it, accept that historical data will be shallower than current data and tell your reporting audience so. The detailed sequencing, cleansing and reconciliation approach is in the data migration strategy guide, and the register structure itself in the asset hierarchy design guide.

9. Implementation: the realistic sequence

The sequence that works is unglamorous and deliberately staged. The sequence that fails tries to switch on every module at once because the licence covers them.

• Foundation first. Location hierarchy, asset register, classification standards, user roles. Nothing else is stable until this is agreed and loaded.
• Reactive work and helpdesk second. Get requests flowing in, jobs assigned and closed, and the mobile app in real hands. This is where adoption is won, and it delivers visible value within weeks.
• PPM third. Load statutory regimes first because they are non negotiable, then the rest of the planned schedule. Level the workload against real crew capacity before you switch it on, or month one will generate more work than exists labour to do.
• Contractors and procurement fourth. Bring third parties onto the system once your own team is fluent. Contractors adopt an established system more easily than a chaotic new one.
• Space, projects and analytics last. These depend on clean foundation data and stable operational use. Attempting them early produces reports that are quietly wrong.
• Integrations staged alongside, not all at once. Identity and single sign on early because it affects everyone. Finance when procurement goes live. BMS and access control after the helpdesk can absorb what they generate.

Phasing is not slowness, it is how you avoid asking a team to learn six modules in one month. For realistic duration expectations and the activities inside each phase, see the implementation timeline guide. The related maintenance discipline itself, how the work is planned and executed once the software is live, is covered in the facilities maintenance management guide.

10. The weighted evaluation scorecard

A scorecard does two useful things: it forces the buying group to agree what matters before anyone is charmed by a demo, and it produces a defensible record of why the decision was made. It is not a mathematical oracle. If the scores come out within a few points of each other, the scorecard has told you the products are comparable and the decision belongs to judgement about fit and about the people you will work with.

The structure I would use, with weights to adapt rather than adopt:

Two disciplines make a scorecard real. First, score against demonstration rather than assertion; if a vendor says a capability exists but will not show it, it scores as absent. Second, keep the buying group small enough to reach a decision and wide enough to include a technician, a supervisor, an FM administrator and whoever owns the finance integration. The commercial structuring, how you put all of this into a formal requirements document and invite responses, belongs in the RFP writing guide.

11. Demo scripts that expose weak products

Vendor led demos are rehearsed to show strength and route around weakness. The fix is to control the script. Send the same scenarios to every shortlisted vendor in advance, insist they are performed in a live system rather than described, and do not allow substitutions. These are the scenarios that separate products.

• The multi trade job. A single fault needs an electrician today and a mechanical fitter on Thursday, and the second visit finds more work. Watch how the system models one problem with several visits and a scope change. Weak products force you to raise unrelated jobs and lose the connection.
• The missed statutory PPM. A statutory inspection due last month was not done. Show me how the system surfaced it, what it did with the overdue task, and what the audit trail says now. Some products silently roll the schedule forward, which is a compliance problem dressed as a convenience.
• The offline technician. Complete a checklist with three photos in aeroplane mode, then reconnect. Then have a second user edit the same job while the first was offline, and show me the conflict resolution.
• The contractor with lapsed insurance. Assign a job to a contractor whose insurance expired yesterday. The system should prevent or flag it. Many do neither.
• The new question. Ask for a report nobody prepared: corrective jobs by asset class, by site, last quarter, with average time to close. Watch whether an ordinary administrator can build it or whether it becomes a change request.
• The recharge or client split. If you are a landlord or a provider, take one job and show it billed to the correct party with the correct rate under the correct contract.
• The configuration change. Add a new request category with its own routing and SLA, live, using an administrator account. If this needs the vendor, price that into every future year.

Score each scenario immediately after the session while it is fresh, and record what was shown versus what was promised for a later release. Roadmap promises are not features; they are options you may or may not receive.

12. The two most expensive mistakes

Across selections I have advised on and inherited, two mistakes account for most of the wasted money, and neither is a technology failure.

Buying an IWMS for an organisation that needed a good helpdesk and a maintenance module. This is the expensive one, and it happens for understandable reasons. The suite demo is genuinely impressive. The modules you will not use are bundled at what feels like marginal cost. Nobody wants to be the person who bought the system the organisation outgrew. So a mid sized estate with a small FM team and no dedicated systems administrator buys a platform designed for a global portfolio with an internal configuration team, and the outcome is predictable: an implementation that runs long because the product has to be configured rather than adopted, a team that uses two modules of nine, a dependency on the implementation partner that never ends, and an annual renewal that is hard to justify against what is actually being used. The honest version of "we might need it later" is that you can buy later, and by then you will know what you need. Capability you cannot operate is not capability.

Treating the asset register as something to fix after go live. Covered above, and worth repeating because it is so consistent. The register is the spine. PPM coverage, compliance evidence, cost history, criticality, lifecycle planning and every analytic you bought the system for all attach to it. Organisations that delay it are choosing to run a system whose outputs their own managers do not believe, and rebuilding trust in the data afterwards costs several times what verifying it upfront would have.

A third, smaller but common, deserves a mention: choosing on features and living with support. The functional gap between shortlisted products is usually narrower than buyers expect, while the difference in implementation quality and ongoing support is enormous. Call the references yourself, ask them specifically about year two rather than the launch, and ask what they would do differently.

13. Reading the vendor landscape without being steered

The market is broad and genuinely differentiated by centre of gravity, which is useful once you know your own category. Enterprise asset heavy operators gravitate to platforms such as IBM Maximo, Hexagon EAM, Infor EAM and SAP plant maintenance, all of which carry real depth in asset, reliability and lifecycle management and all of which expect a mature internal capability. Building and workplace centric buyers look at CAFM and IWMS platforms such as Planon and Archibus, which are strong on space, property and integrated workplace processes. Teams whose need is maintenance execution and fast adoption look at the modern CMMS tier, MaintainX, Limble, Fiix, UpKeep and eMaint among them, which trade breadth for usability and speed to value. The CMMS buyer's introduction and the CMMS for facilities management guide go into that tier in more detail.

That grouping is descriptive, not a ranking, and I would not rank them, because the right answer depends entirely on which category you established in section two. A platform that is wrong for a small estate is the correct choice for a national portfolio and vice versa. What is worth knowing is that analyst grids and comparison sites are frequently vendor funded, so treat them as a source of names rather than a source of judgement. The professional bodies are a better neutral starting point for the discipline itself: IFMA , IWFM and RICS all publish guidance that is not trying to sell you a licence.

One habit worth adopting: whenever a vendor uses a category label about themselves, ask them which of the five needs in section one they were originally built to serve. Most will answer honestly, and the answer tells you where the depth is and where the module was added to close a tender gap.

The idea to walk away with

Choosing facility management software is mostly a scoping exercise disguised as a purchasing exercise. The organisations that get it right spend the first third of their effort deciding what kind of system they need and what specific operational failure it must stop, the second third proving candidate products against their own data and their own technicians, and only the last third on commercials. The organisations that get it wrong start at the demo, let the breadth of the suite define the requirement, and discover two years later that they are paying for nine modules and running two.

Buy for the operation you run, staged so your team can absorb it, on an asset register you have verified. That is a less exciting sentence than anything on a vendor website, and it is the whole difference between a system people use and a system people work around.

Final thoughts

If you take one practical action from this guide, write the sentence: "we are buying this system to stop X". Get the budget holder to agree it. Then hold every demo, every scorecard row and every phase of the implementation against that sentence. It will keep you out of the suite that flatters your ambition and into the product that fixes your problem, and it will give you something concrete to measure success against a year after go live. Measuring that outcome properly is its own discipline, and the FM KPI framework is where I would start.

The last thing worth saying is that no product on the market will rescue an operation without process discipline. Software makes a well run FM function measurable and a badly run one visible. Both are useful, but only one of them is what buyers think they are paying for.

Independence note: this guide is independent practitioner analysis. It is not a paid review. No vendor named here has had editorial input or a commercial relationship with this publication, and no product is ranked or recommended.

Related reading: CAFM vs CMMS vs EAM vs IWMS, Which of CAFM, CMMS or EAM is right for you, Multi site CAFM architecture, CAFM data migration strategy, How to write a CAFM RFP, CAFM implementation timeline, FM KPI framework.