How Do You Build a Facilities Software Selection Checklist That Sticks?

A useful facilities software selection checklist does more than compare feature counts. It creates a repeatable, evidence-based way for virtual utilities, facility operators, workplace teams, and vendor-management leaders to test whether a platform fits their operating model, data environment, risk controls, and budget. The central question is not “Which product has the most modules?” but “Which system can produce dependable results with the people, processes, integrations, and governance we actually have?” This matters because software selection is an operational decision rather than a purely technical purchase. Research across aviation, healthcare, collections management, and industrial vehicle selection shows a recurring principle: checklists work when they support a defined decision and expose exceptions, but a generic checklist can also create false confidence if teams treat completion as proof of fitness.

The checklist below is designed for B2B facilities and workplace environments, including campuses, multi-site portfolios, building-service providers, and organizations managing work across outsourced vendors. It is also relevant to virtual utilities, where a small internal team may administer services distributed among buildings, contractors, and enterprise systems. The purchasing horizon should be planned as of September 2026, while vendors may change pricing, packaging, and product names; every commercial claim should therefore be confirmed through a current, written proposal and a controlled proof of concept.

Also worth reading: What Is the Best VPP Procurement Checklist for Facilities Teams in 2026? · What Is a Facilities Vendor Compliance Checklist for 2026? · How Do Enterprise Facilities and Workplace Teams Navigate Vendor Risk Management VRM Platform Selection in 2026?

Start With the Operating Decision, Not the Product

Before evaluating vendors, define the decision the software must improve and identify the baseline it should change. A request for proposals that simply asks for “a facilities management platform” usually produces broad, incomparable answers. A stronger request asks whether the system will reduce emergency work-order response time, improve preventive-maintenance completion, reconcile vendor invoices against contracted rates, standardize site inspections, or give executives reliable energy and service-performance reporting. Choose one primary outcome and no more than three secondary outcomes. Record the current metric, target metric, measurement owner, and review date so that the eventual selection is based on operational change rather than a polished demonstration.

Set evaluation boundaries as well. Clarify which sites, regions, buildings, contractors, asset classes, and workflows belong in the first release. A system intended for 40 commercial sites should not be judged only on its usability in a single pilot building, while a system intended for one laboratory should not be priced or tested as though it must support a global portfolio. Decide whether field technicians are the primary users, whether vendor staff need limited external access, and whether corporate teams need portfolio reporting. This prevents a capable product from winning for functionality the organization will not use while missing a mandatory requirement such as role-based permissions, audit history, or local data handling.

Use two decision gates. The first is strategic fit: business need, scope, users, and constraints. The second is operational fit: a scripted trial using representative data, workflows, and failure conditions. A vendor may pass the first gate easily and fail the second when its mobile experience cannot handle offline work at a remote site, its invoice automation cannot process credits, or its permissions cannot distinguish a site manager from a contractor coordinator. The most defensible recommendation combines both gates and explicitly identifies unresolved risks.

Define Users, Roles, and Service Boundaries

Facilities software often becomes difficult to select because buyers compare technology before mapping accountability. Identify the people who create requests, approve work, perform inspections, manage contractors, verify completion, reconcile invoices, analyze performance, and administer the system. A typical enterprise may include a facilities director, regional operations manager, site administrator, account manager, planner, technician, safety lead, finance analyst, vendor employee, executive, and external auditor. The permissions model must reflect the actual separation of duties; allowing technicians to mark work complete and approve the resulting invoice is not efficiency when the organization requires independent verification.

Translate roles into testable user journeys. For example, a technician should be able to scan an asset, open a work order, record labor and parts, add photos, flag a safety issue, and obtain help when connectivity is poor. A vendor coordinator should see only assigned properties and work, while a regional manager should see exceptions across the portfolio. A finance user may need invoice lines, evidence, service-level calculations, and export functions without access to sensitive employee or security information. Test access during onboarding, role changes, contract termination, and offboarding because static demonstrations rarely cover these lifecycle events.

Document the boundary between enterprise systems and facilities tools. Many buyers assume that a product is an “all-in-one” platform when the system actually depends on separate modules, licensed connectors, professional services, or partner applications. The request for proposals should identify authoritative data sources for assets, people, work orders, invoices, and contractor records. It should also state which system owns each field and what happens when two systems disagree. This is particularly important for virtual utilities, where the internal team may coordinate rather than physically employ technicians and therefore needs clear rules for delegating tasks without losing accountability.

Evaluate Core Facilities Workflows With Real Exceptions

A facilities software selection checklist should test complete workflows rather than isolated screens. Follow a corrective-maintenance request from intake through triage, dispatch, completion, supervision, invoice approval, analytics, and asset history. Include routine and abnormal conditions: a request arriving after hours, an asset without a barcode, a technician finding a hidden failure, a contractor missing the appointment window, a work order requiring parts not shown in the catalog, and a customer disputing the charge. The objective is not to manufacture difficulty; it is to learn how the product handles the exceptions that consume staff time and create risk.

Preventive maintenance deserves a separate test because calendar-based schedules may look strong while field execution remains weak. Ask whether tasks are generated by time, usage, condition, inspection results, or a combination of rules. Confirm how repeated failures, skipped visits, incomplete checklists, and overdue assets appear to managers. For a system serving laboratories, hospitals, hotels, or factories, test permit-to-work or safety escalation only if that scope is genuinely required; adding every possible safety module can distort both selection and cost. A smaller system with usable evidence trails may be preferable to a larger one that leaves users bypassing the process.

Vendor operations should be tested from the vendor’s perspective as well as the client’s. Upload a current service schedule, simulate a price change, submit an invoice with a credit, request a document correction, and review performance against agreed response and completion targets. Determine whether vendors can see only relevant sites and records, whether invoice submission deadlines are enforced, and whether the system records who accepted or rejected an exception. Avoid assuming that a low work-order count proves vendor performance. Low volume may mean good preventive work, poor reporting, missing asset coverage, or technicians completing work outside the system.

Compare Functional Depth Without Inflating the Score

Create a requirement matrix and classify features as mandatory, preferred, optional, or not applicable. Mandatory requirements should be limited to conditions the business genuinely cannot compromise, such as legal record retention, required localization, enterprise single sign-on, or a mandated interface. Preferred requirements should identify important improvements, while optional items should be excluded unless the business case is unusually strong. Assigning equal weight to every function encourages feature-count comparisons and hides the operational priorities established earlier.

Use scenario-based scoring rather than a simple checklist of “yes” or “no.” A 1-to-5 scale can indicate whether a feature is absent, weak, usable, strong, or demonstrably better than the current method. Cap the score when a capability depends on an unproven integration, an undocumented service, or manual work that undermines the expected benefit. Weight mandatory gates separately so a strong score cannot compensate for a missing security control or an inability to support required mobile use. Aim for a transparent result: for example, 30% workflow execution, 20% data and integrations, 15% user experience, 15% governance, 10% service support, and 10% commercial fit.

The comparison should expose trade-offs instead of declaring a universal winner.

These categories describe buying patterns, not fixed product classes. Vendors may repackage modules, and an enterprise suite can be right for a smaller organization if implementation support is included. The key is to compare the proposed configuration, not the label on the vendor’s website.

Test Data, Integrations, Security, and AI Claims Carefully

The system will be dependable only if its data model supports the decisions users need. Ask how assets are identified, how parent-child relationships work, how meter readings map to cost centers, and how historical service records are retained. Test duplicate requests, merged assets, reassigned sites, missing cost centers, and imported records that fail validation. For virtual utilities, confirm whether one request can involve several buildings or vendors and whether performance can be consolidated without hiding property-level accountability.

Treat integrations as products within the product. Obtain a current list of standard interfaces, then determine whether the required connection is prebuilt, configurable, partner-delivered, or custom. Confirm supported versions, authentication, sync direction, frequency, error handling, monitoring, and responsibility when an interface fails. A claimed connection to a payroll, accounting, identity, or enterprise resource-planning system is not enough if bulk updates, credit notes, custom fields, or historical migration are excluded. Include integration expenses and ongoing support in the total-cost model.

Security review should cover identity, authorization, audit trails, encryption, data location, retention, deletion, incident response, and business continuity. Require evidence appropriate to the risk, such as independent assurance reports, penetration-test summaries, and a documented vulnerability-remediation process, while protecting genuinely confidential report details. If the tool will process employee, visitor, badge, medical, or critical-infrastructure information, the assessment may need to be more rigorous than a standard corporate application review.

AI features require separate evidence. Ask what data the model uses, whether customer data trains shared models, how outputs are validated, and whether a user can inspect the source values. A natural-language summary is not automatically trustworthy, especially when it changes energy totals, invoice reasons, or compliance conclusions. In 2026, no vendor should receive production access merely because a feature is labeled “AI”; the system should first demonstrate permissions, human review, and predictable performance on the buyer’s own scenarios.

Establish a Real Proof of Concept and a Fair Commercial Model

A proof of concept should be small enough to control but realistic enough to decide. Select two or three sites with different service models, one portfolio view, and representative users. Use synthetic or appropriately protected data, then run the same scripted tasks supplied to every finalist. Include mobile or tablet use, desktop administration, contractor access, finance review, and at least one failed integration or delayed response. Measure task completion, time on task, user errors, support interventions, and whether the audit trail is understandable.

Structure the test over a defined period, such as two to four weeks for a focused proof of concept and three to six months for a limited production pilot. A demonstration can reveal obvious gaps, but it cannot establish adoption, data quality, seasonal behavior, or operational stability. Define success before the test: for example, at least 90% completion of specified work-order tasks by trained pilot users, 95% successful transfer of required invoice fields, no critical permission failure, and an agreed method for unresolved offline records. A larger portfolio may justify a six- to twelve-month rollout, but do not confuse a long rollout plan with a long acceptance period.

Compare total cost, not only subscription price. Review implementation, data cleansing, migration, configuration, integration, training, change management, support, hosting, security assessment, reporting, renewal escalation, and the internal labor required to keep the product accurate. Ask for a three-year cost model with volumes by site, user, connected device, workflow, and module. Confirm whether sandbox environments, extra storage, API calls, premium support, and customer-managed integrations are included.

Pricing structures vary widely, so specific market figures should be treated as planning ranges rather than promises. A focused team may find a low annual platform fee, while enterprise systems can reach five- or six-figure annual commitments before services; implementation may add another 20% to 100% of first-year subscription cost in a customized deployment. A rough 10% to 20% of first-year recurring fees may be reserved annually for optimization, training, and ordinary product changes, although complex portfolios can require more. Require written price protection and an itemized statement of what happens when sites, users, devices, or connected assets exceed the proposed tiers.

Control Common Selection Mistakes and Decision Bias

One common mistake is selecting from a shortlist created before requirements are mature. Another is giving a polished demonstration data that is cleaner than real operations, so hidden costs from duplicates, missing assets, and inconsistent contractor names never appear. Buyers also underestimate implementation labor, particularly data cleansing and user training. Research and industry commentary have repeatedly associated understaffing with operational pressure; adding software without redesigning ownership may simply give fewer staff more screens. Count the internal people who will configure, support, reconcile, and report on the platform before committing.

A second error is treating every request as an equal-priority feature. This produces a large procurement that is expensive to implement and difficult to adopt. Set must-have gates, use weighted scenarios, and require vendors to explain trade-offs. Avoid the opposite error: choosing the cheapest product that passes mandatory requirements without testing long-term administration, data export, support quality, or future scale. Low initial cost can be reasonable for a narrow pilot, but a tool that requires duplicate entry into accounting or work-order systems may become costly once adoption expands.

Watch for vague language. Terms such as “scalable,” “intelligent,” and “open” need measurable definitions. Ask how many users and sites are supported in the proposed configuration, which interfaces are included, how quickly a failed sync is visible, and what export format the customer retains. References should be relevant to the same industry, portfolio scale, and service model. A healthcare reference may be useful for compliance evidence but less useful for predicting adoption in office buildings managed by outside vendors.

Finally, separate consensus from evidence. A selection committee should record the reason for each vote, and unresolved objections should become contract conditions or pilot exit criteria. The chosen product may be the best available option without being perfect. Strong selection is not the absence of compromise; it is a transparent understanding of those compromises before money and operational time are committed.

Decide, Contract, and Plan the First 90 Days

A selection should be approved only when the preferred vendor meets mandatory conditions and the business case has named owners. The decision record should summarize current-state evidence, target outcomes, weighted scores, proof-of-concept results, security and integration findings, total three-year cost, unresolved risks, and the reason the option was rejected. Give operational, finance, security, and procurement leads appropriate approval authority rather than allowing a facilities stakeholder to make an end-to-end commitment alone.

Put important promises into the contract or order form. Specify implementation milestones, data migration responsibilities, interface behavior, acceptance tests, service levels, support channels, renewal increases, training, export rights, and consequences for missed delivery. Do not rely on a sales presentation or generic master service agreement when the proposal contains a material exception. Ensure the agreement also explains how customer data is returned or deleted and how access ends for employees and external vendors.

Plan the first 90 days around control and learning. During days 1–30, establish governance, confirm data owners, freeze the initial requirement baseline, and prepare sites and users. During days 31–60, configure the selected workflows, migrate test data, complete role testing, train administrators, and launch a limited pilot. During days 61–90, review adoption, work-order quality, invoice accuracy, support load, and user feedback against the original business case. A practical initial target may be at least 85% of in-scope active users trained and 90% of pilot work orders recorded in the system, but the correct threshold should reflect operational risk and the agreed rollout stage.

Act promptly when a system addresses a defined bottleneck, but do not create urgency with artificial deadlines. If a contract expires within 90 days, inadequate service-level reporting is harming vendor governance, or a major site is expanding, begin structured evaluation early. If the current process is stable, inventory the problem first and consider a narrow proof of concept before committing to a broad transformation. The right buying decision in September 2026 is not necessarily the most feature-rich software; it is the option that can be governed, adopted, integrated, and measured against a clear facilities or workplace outcome.