Facility management system: the operator control test

A facility management system should make the operation easier to trust. It should show what needs attention, which record is authoritative, who owns the next decision, and what proves the work is complete.

That sounds basic. It is also where many software purchases fail.

A vendor can demonstrate work orders, assets, preventive maintenance, inspections, vendors, space planning, inventory, mobile access, and reporting. The demo can be accurate while the buyer still has no answer for how a request moves from an email or phone call into an owned and verified outcome.

IBM describes a CMMS as software used to schedule, manage, and track maintenance tasks. I use that category as a starting point. A facility management system has to do more than hold maintenance activity. It has to control the handoffs around buildings, people, vendors, approvals, and evidence.

I saw the same operating problem on a build outside facilities. The before-state was spreadsheets, whiteboards, and word-of-mouth. The business wanted one automated system, but the useful work was not putting every screen in one application. It was deciding which record mattered, who owned the next action, and what the team needed to see each day.

I have built over 500 production-grade workflows. My opinion after that volume is simple: software does not create operating control by itself. The operator has to define the lane, own the rules, and keep a visible stop control.

Start with the operating promise

Before I compare facility management system features, I write one sentence:

Every valid facility request reaches the right owner, receives the required decision, and closes with evidence in the authoritative record.

That promise creates a boundary. It does not say every request should be automated. It says the system must preserve the path from signal to outcome.

I then map the six decisions that make the promise real:

1. Which channels are allowed to create a request?
2. What minimum information makes the request valid?
3. Which record owns the asset, location, priority, vendor, and completion status?
4. Who owns each normal action and each exception?
5. Which approval boundaries can the system never cross alone?
6. What evidence closes or reopens the work?

This is why I treat the project as business process automation, not a software installation. The outcome crosses inboxes, forms, sensors, asset records, calendars, purchasing, vendors, invoices, and management review.

The best facility management system is the one that can support the operating promise without forcing the team to rebuild the truth by hand.

Make the request lane visible

A maintenance request is not automatically a work order.

A message that says, "The second-floor unit is making noise," may be a useful signal. It is not yet a controlled record. The operation may still need the location, asset, symptom, safety impact, occupant impact, photo, reporter, access window, priority rule, and current owner.

I want the facility management system to separate four states clearly:

• Accepted requests with enough information to assign.
• Incomplete requests that need specific fields.
• Safety, access, or business-continuity exceptions that need immediate human review.
• Vendor or parts dependencies that cannot move until another owner acts.

That is the practical reason to automate work orders from email. The goal is not to make email look structured. The goal is to capture the signal, validate the required information, and move a valid request into the system without hiding uncertainty.

A good request lane also preserves the original message, attachments, timestamps, and later decisions. I do not want extracted fields to replace the evidence that produced them.

Decide which record wins

Facilities work often touches a CMMS, building management system, ERP, spreadsheet, vendor portal, shared inbox, inspection form, contract folder, and accounting platform.

A facility management system cannot control that environment until the buyer names which record wins for each decision.

This is where legacy system modernization becomes a business decision instead of a replacement slogan. Modernization can mean replacing a system that traps bad records. It can also mean keeping a valid system of record and wrapping controlled intake, routing, follow-up, and reporting around it.

I prefer the second path when the core record is usable. It reduces migration risk and lets the team test the operating model before committing to a larger replacement.

The deeper version of this decision is covered in my CMMS software for manufacturing control framework. The vertical changes, but the rule does not: the system should make intake, source records, exceptions, approvals, and proof visible.

Give exceptions a real owner

Most facility management system demos show the happy path. Real operations live in the exceptions.

I design explicit lanes for:

• Asset or location not found.
• Request missing access, safety, or severity details.
• Duplicate or conflicting work orders.
• Technician cannot reproduce the issue.
• Required part is unavailable.
• Vendor has not accepted or updated the job.
• Quote or spend exceeds an approval limit.
• Inspection produces a finding outside the original scope.
• Work appears complete but evidence is missing.
• Destination system rejects the update.

Each lane needs a plain-language reason, one current owner, a due time, the allowed decisions, and proof of closure.

A red badge is not ownership. A shared queue is not ownership. If the facility manager cannot identify the person responsible for the next decision, the software has only made the delay easier to count.

This matters most in outside work. My vendor dispatch and SLA workflow focuses on assignment, acceptance, status, escalation, and completion proof because vendor work disappears when the real record lives in an email thread.

Keep approvals separate from automation

A facility management system can prepare a decision without receiving authority to make it.

I define the boundary by action:

• Read and classify a request.
• Validate required fields.
• Suggest asset, priority, or trade.
• Prepare a work order for review.
• Assign routine work within policy.
• Escalate safety, access, downtime, or spend exceptions.
• Draft a vendor update.
• Close work only when required evidence is present.

The NIST AI Risk Management Framework is useful here because it treats trustworthiness as something that has to be managed across design, development, use, and evaluation. I apply the same discipline to facility automation. I want to know what the system used, what action it took, where confidence was low, which person approved the exception, and how the team can stop or recover the workflow.

My ownership rule is direct. The business should own the accounts, code, data, credentials, rules, logs, and documentation. No builder or software vendor should become the only person who can explain why a work order moved or why a vendor received approval.

Test one facility workflow before expanding

I do not start by connecting every building, asset class, vendor, and request channel.

I choose one lane with a clear owner and enough volume to learn. Work-order intake, vendor dispatch, inspection follow-up, or preventive-maintenance exceptions are strong candidates.

The pilot should include:

1. A normal request that should route and close.
2. An incomplete request that should stop.
3. A safety or access exception that requires a person.
4. A duplicate request with different wording.
5. A vendor that does not accept the assignment.
6. A spend threshold that blocks automatic progress.
7. A destination-system failure.
8. A pause, correction, and safe replay.
9. A completed job with missing evidence that must not close.

I want the facility owner to perform the stop and recovery steps. Watching the builder run a perfect demo does not prove the team owns the system.

This is also why I recommend automating the handoffs before replacing a CMMS. A narrow pilot shows whether the pain sits in the core platform or in the work moving around it.

Measure completed outcomes

A facility management system makes activity easy to count. Requests opened, work orders assigned, preventive tasks scheduled, vendor messages sent, and reports generated can all look productive.

I measure whether the operation completed the promise. The Department of Energy operations and maintenance guide connects good O&M programs to efficient, reliable, and safe operations. That is the standard I want the scorecard to support.

My first scorecard includes:

• Percentage of valid requests accepted without manual re-entry.
• Time from accepted request to named owner.
• Number and age of open exceptions.
• Safety and access exceptions handled within policy.
• Vendor acceptance, update, and completion time.
• Preventive-maintenance work completed, deferred, or escalated with a reason.
• Inspection findings converted into owned work.
• Reopen rate and repeat issue rate.
• Completed jobs missing required proof.
• Time to detect, stop, and recover from workflow failure.

I review the exceptions every week. Which request types are repeatedly incomplete? Which assets cannot be matched? Which vendors create status gaps? Which approvals stall? Which closed jobs are reopened? Those questions improve the operating model and tell the team whether the facility management system is earning a wider rollout.

When not to hire us for facility automation

Do not hire us when the team wants a generic vendor shortlist or another dashboard without changing who owns the work.

I would pause the project when:

• Asset and location records are duplicated or unmanaged.
• Request priority changes by whoever complains the loudest.
• Nobody owns incomplete requests or vendor exceptions.
• Approval limits are informal.
• Shared credentials hide who made a decision.
• Completion does not require evidence.
• The current system cannot export or integrate, but leadership refuses to replace it.
• The team wants automatic closure before it can run a recovery drill.

Those are operating decisions first. Clean the first record. Name the owners. Define the approval boundaries. Choose the evidence. Then automate the stable lane.

My facilities and maintenance automation page shows the lanes I focus on: work-order intake, CMMS handoffs, vendor dispatch, inspections, preventive maintenance, and reporting. The right starting point is not every lane. It is the one leaking the most time, risk, or proof.

I use the AI Operations X-Ray to identify that starting point. Map one promise, one source-of-truth decision, one exception owner, and one recovery drill. If the facility management system can support those controls, keep it and improve the handoffs. If it cannot, the replacement case becomes clear and grounded in the operation rather than the demo.