Posted 9th September 2026 by Rob Whalley

CAFM Software: Why Flexibility Matters More Than Ticking Every Box

When organisations procure a CAFM system, they will often begin with a detailed specification containing hundreds of individual requirements. That makes sense. A CAFM platform can become central to maintenance, assets, compliance, contractors, buildings, people and operational performance, so buyers need confidence that the selected solution can support their needs.

But a wider question is worth considering: are organisations selecting the best CAFM platform, or simply the system that ticks the most boxes?

The Problem With Checklist Procurement

Detailed specifications provide structure and allow suppliers to be compared against a common set of requirements. However, they can also create unintended consequences. A system may satisfy the vast majority of requirements but fall short on a small number of specific features, and those gaps can have a disproportionate effect on the overall score.

At the same time, that platform may offer significant capabilities that were never considered when the specification was written. Because they fall outside the scoring matrix, they may receive little or no recognition. One system can therefore lose marks for a few gaps while receiving no additional value for functionality that could become important later.

That does not mean checklist procurement is wrong. It does highlight the limitation of evaluating complex operational software purely as a collection of individual features rather than as a platform that will need to support changing requirements over many years.

A Requirement Can Mean Different Things to Different People

Another challenge is interpretation. A statement that appears perfectly clear to the organisation writing the specification may mean something quite different to the suppliers responding to it.

Take a relatively simple requirement such as: ‘The system must automatically allocate work to the appropriate operative.’ What does that actually mean?

• Default allocation based on a fixed workflow or a flexible matrix?
• Allocation based on skill set and qualifications?
• Allocation by region, building or GPS proximity?
• Consideration of engineer availability and workload?
• Or a combination of all of these?

A supplier may genuinely have automatic allocation functionality and therefore mark the requirement as Met. Yet the way that functionality operates may differ significantly from what the organisation intended. Requirements should therefore, wherever possible, describe the expected outcome and key workflow in sufficient detail to remove material ambiguity.

The use of Met, Partially Met and Not Met responses creates a related challenge. Where a requirement is broad, a supplier may reasonably select Met based on the functionality it provides. Conversely, where a requirement is highly detailed, and the supplier meets the overall objective but not one specific element exactly as described, it may need to select Partially Met. This can create an unintended imbalance: the more detailed requirement may produce a lower compliance score even though the supplier offers a strong solution.

The distinction between Met and Partially Met should therefore focus on whether any gap is material to the required outcome, rather than simply whether every aspect of a prescribed workflow is delivered in precisely the same way. In the automatic allocation example, the requirement could define the factors to consider, the expected user interaction, exceptions and what should happen when automatic allocation is not possible. The more important the requirement, the less room there should be for interpretation.

Clarifications

Suppliers are normally given an opportunity to raise clarification questions, but this raises an important question: where does responsibility lie for ensuring that each functional requirement is sufficiently clear and fully understood?

There is inevitably a shared responsibility. The contracting authority should define requirements with enough detail for suppliers to understand what is expected and respond consistently. Equally, where a supplier identifies a genuine ambiguity, dependency or uncertainty that could materially affect its response, it should seek clarification.

However, it is neither practical nor proportionate for suppliers to interrogate every individual functional requirement simply to uncover possible unstated expectations. Doing so can produce lengthy clarification logs, delay the procurement process and require suppliers to revisit submissions or commercial proposals several times.

Where a requirement appears reasonably clear, and the supplier has existing functionality that it believes satisfies it, it is reasonable to respond Met based on the written requirement. Supplier comments can then explain how the functionality is delivered, demonstrate capability and state any assumptions. Clarification should be concentrated on material ambiguity rather than becoming an exercise in testing every line for an interpretation that was never stated.

If a particular feature, workflow or method of delivery is essential to achieving a Met score, that expectation should ideally be explicit within the requirement itself.

Presentations

Presentations and demonstrations are important because they allow evaluators to see functionality in practice. But there are limits to what can reasonably be shown within a restricted presentation window. A supplier may have extensive functionality available, yet unless the client defines the specific workflows, scenarios and outcomes it wants to see, the supplier must decide what to demonstrate and how much detail to provide.

This creates a risk that valuable time is spent showing functionality that is less important to the evaluation, while a particular workflow expected by the panel is not demonstrated. Where presentation scoring depends on a process or user journey, clearly defined scenarios should therefore be issued in advance, including the expected workflow and key outcomes.

This allows all suppliers to prepare against the same criteria, improves consistency and ensures the presentation assesses the supplier’s ability to meet the requirement rather than its ability to anticipate what the evaluation panel had in mind.

Some Requirements Only Become Clear During Deployment

Complex CAFM projects also have a practical reality: not every requirement becomes fully clear during procurement. Once implementation workshops begin and teams start discussing real operational processes, additional questions emerge. Exceptions are identified, different departments reveal slightly different processes and legacy workflows often contain years of operational knowledge that cannot be captured in a single line of a specification.

A requirement originally written as one sentence can therefore become an entire workflow containing decisions, approvals and exceptions. That does not necessarily mean the original specification was poor, nor that the supplier misunderstood it.

For example, a system may support approval workflows and reasonably be marked as Met, while implementation still requires decisions around:

• who approves what and whether financial thresholds apply;
• what happens when an approver is absent or approval is delegated;
• whether different workflows are needed by department or site;
• what notifications, rejection routes and audit information are required.

The supplier may be able to provide the required solution, and may even have demonstrated a similar process during the presentation, but the precise output may still differ from what the contracting authority expected. This is why business analysis, implementation workshops and workflow design remain so important. Procurement should define the required outcome as clearly as reasonably possible; implementation should establish the finer detail needed to make that outcome work operationally.

Configuration Versus Development

It is also important to distinguish between configuration and development. A modern CAFM platform should offer significant flexibility through configuration. Changes to workflows, permissions, forms, dashboards or notifications should not automatically require bespoke development.

Some requirements will, however, require development. That should not automatically be viewed negatively. A supplier may be able to enhance an existing platform through a formal requirements-gathering process and deliver the required outcome within the implementation programme. This can benefit both parties, provided the requirement is transparent, the total cost remains competitive and the supplier can demonstrate the capacity and track record to deliver the enhancement.

Today's Specification Will Not Be Tomorrow's Specification

A CAFM procurement defines what an organisation needs today, but the selected platform may remain in place for many years. During that time, legislation, compliance obligations, contractors, organisational structures and technology will change. Mobile working, IoT, QR codes, BIM, APIs and business intelligence may become more important, while entirely new operational requirements may emerge.

A requirement considered essential during procurement may also become less important several years later, while functionality that did not appear in the original specification could become fundamental. Future adaptability should therefore be considered alongside present-day functionality.

This is also how mature software platforms evolve. Many capabilities available today exist because previous customers identified a requirement the software did not initially support, the workflow was understood, development was delivered and that functionality became part of the wider product.

Consider the Functionality You Didn't Ask For

Another important aspect of procurement is functionality that does not appear in the specification. A CAFM tender may focus heavily on planned maintenance, reactive maintenance and asset management, while a broader platform may also include compliance, contractor management, stock, permits, health and safety, audits, surveys, room booking, projects, cleaning, purchasing, events, accommodation, finance, fleet or document management.

Those areas may not form part of the immediate requirement, but they may still have significant future value. Procurement should consider not only what one department needs today, but how the platform might support the wider organisation tomorrow. A system initially procured for a Facilities Management team may later benefit Estates, Health & Safety, Compliance, Finance, Procurement, Cleaning, Security or other operational teams.

For example, FM inspection data may support Health & Safety activity; contractor information may be shared across Estates, Compliance and Procurement; purchasing functionality may connect maintenance activity with financial controls; and room or resource management may extend the platform beyond the original FM function.

Three years later, the organisation may decide to digitise one of these additional processes. If the capability already exists within the platform, expansion can often reuse the same buildings, locations, assets, users, contractors, documents and reporting structures. If it does not, another product may need to be procured, implemented, integrated, licensed and supported.

There is therefore a genuine cost and efficiency benefit in considering the wider organisation and its direction of travel. A capable shared platform can reduce duplicated data, separate software licences, integrations, training requirements and support overheads, while providing a more joined-up view of operational information.

This does not mean suppliers should receive extra credit simply for presenting long lists of functionality that has not been requested. The primary assessment must remain focused on the stated requirements. However, suppliers should have an opportunity to demonstrate relevant wider capability where it could support other departments, reduce future expenditure or contribute to the organisation’s longer-term digital strategy.

Procurement Is a Shared Responsibility

Ultimately, good software procurement requires effort from both sides. Buyers should make critical requirements explicit, particularly where a specific workflow or outcome is essential. Suppliers should respond transparently, explaining where functionality is partial, where configuration or development is required, what assumptions have been made and where further business analysis will be needed during implementation.

That creates a much stronger foundation than discovering during deployment that both parties placed a tick beside the same requirement while imagining two different solutions.

Selecting CAFM software is rarely just about purchasing the functionality available at one moment in time. It is often the beginning of a relationship with a platform that may remain within the organisation for five, ten or even fifteen years. A detailed specification remains important, but it should sit alongside demonstrations, business analysis and an assessment of the platform’s flexibility, development capability and overall direction of travel.

The strongest CAFM system may therefore not be the one that can tick every line of a spreadsheet today. It may be the one that can demonstrate what those ticks actually mean, adapt when the detailed requirements emerge, and support the requirements that have not yet been written down.