Facility Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the ticket table data model fail so often?

The most common structural failure in this category is drawn in the first architecture session. A developer sketches a work order table with a status column, a technician field and a due date, and everyone nods because it looks like every job system they have ever seen.

It is wrong because a facility management company is not the facility owner. Your work order belongs to a client, under a contract, governed by that contract's service level agreement policy, billed against that client's rate card, and its status has to be mirrored back into that client's own portal. Those are five separate objects with real relationships, and a status column has nowhere to put any of them.

The consequence arrives around month four, when someone asks for a rate card that differs by client and by trade, or for a response clock that pauses on one contract and not another. Both need somewhere to live, and retrofitting them into a ticket table means rewriting everything that reads it.

The fix costs nothing if you do it first. Ask any prospective developer to model your domain on a whiteboard before you sign. A team that has built facility management software will draw the work order, asset, site, contract, service level policy and subcontractor as separate objects with correct relationships inside ten minutes. A team that draws a tickets table with a status enum has told you exactly what you would be buying.

What goes wrong when you migrate the asset registry?

Work order history migrates reasonably well. The asset registry is where these projects lose weeks, because most existing registries are fiction and everyone involved knows it.

Ask how many rooftop units the portfolio carries and the honest answer is usually an approximate number with nameplate data for well under half. The registry in Fiix or UpKeep was populated during an implementation, then rotted, because data entry falls on a technician standing on a roof in July with gloves on and twenty two fields to fill. The same unit exists twice under two spellings. Equipment appears against the wrong site because a building was renamed. Serial numbers include the model, or a hand written transcription of it.

Two things fix this and neither is a data import. First, map assets site by site with your operations team validating, and accept that you are migrating perhaps half the registry cleanly and rebuilding the rest through use. Second, and more important, collapse the capture friction so the registry repairs itself in the field. A tag on the asset that a technician scans, so the app already knows the site, the equipment and its last four work orders. New equipment commissioned from a photo of the nameplate, with model, serial and manufacturer extracted and pre filled and three fields to confirm.

A registry that is easier to update than to ignore stays accurate. One that demands twenty two fields will be wrong again within a year regardless of how well you migrated it.

Why do client portal integrations break after launch?

Status mirroring into ServiceChannel and Corrigo is the highest value integration in a facility management build, because it removes the dispatcher re keying and it prevents the failures where the work was done and the portal was never updated. It is also the integration most likely to be quietly broken three months after launch.

The reasons are specific. Each client instance of these platforms is configured differently, so the field that accepted a status update for one client is not the field the next client uses. Enterprise interfaces are gated, credentials expire, and the notification that they expired goes to whoever set them up. Most damaging, a rejected status update usually fails silently: your system believes it sent, the portal never received, and the two records drift until a true up meeting.

What holds up is treating the portal as an unreliable counterpart rather than a database. Every outbound update needs an acknowledgement, a retry policy and an escalation when retries exhaust. A scheduled reconciliation should compare your state against theirs and surface drift as a work list rather than an email. And someone in operations, not engineering, should own the queue of updates that failed to land.

Budget per portal rather than once. A second integration is cheaper than the first but it is not free, and each additional client instance carries its own configuration discovery.

What happens when subcontractor compliance and invoice matching are not covered?

This is where facility management margin actually dies, and it is almost always phase two, which means it is almost always deferred past the point where it was the cheapest thing to fix.

Three exposures sit on every subcontractor relationship. The certificate of insurance expired and nobody noticed until an incident. The sub billed more than you quoted the client, and nobody compared the two because the invoice arrived in accounting with no work order reference on it. And the sub took nine days on a five day commitment, so you absorbed the credit while they were paid in full.

Accounting software cannot help, because it has no concept of a work order. Maintenance software cannot help, because it has no concept of an insurance certificate. So a compliance manager keeps a spreadsheet of expiry dates and sends reminders by hand, which works until the week it does not.

The fix is to make the subcontractor a first class object with a compliance state: insurance certificate with expiry, tax documentation, licence by trade and jurisdiction, rate card and performance record. Dispatch to a non compliant subcontractor is blocked by rule, which is the entire point. Then close the billing loop by having subs submit invoices against a specific work order through a lightweight portal, so variance beyond a threshold routes to a human and everything else posts automatically. For subs who will only ever email a document, extract and match it on site, date and trade, and flag what does not reconcile.

Should you build custom or configure what you already own?

Stay on Limble, UpKeep, Fiix or ServiceTitan if you self perform under one or two client relationships, run fewer than roughly forty technicians, and no client mandates their own portal. At that size the rigidity of the tool is not costing real money, and a subscription against a six figure build is not a close decision. Buy the tool, hire a strong operations lead, and spend the difference on vehicles.

Be clear about why those products stop fitting rather than complaining that they are bad. They are built for the facility owner. The owner has one set of assets, one internal service standard and no obligation to mirror anything into somebody else's system. Your business has none of those properties, and no amount of configuration adds a contract object to a product whose data model does not have one.

The signals to build, and I would want at least two true at once: a full time person whose actual job is moving data between your system and a client's portal, month end unbilled work orders you cannot explain, a credit assessment you believe is wrong and cannot disprove from your own data, a renewal lost or nearly lost on reporting quality rather than field performance, or more than a third of volume subcontracted with no invoice to work order matching.

How do hidden costs get into a facility management quote?

Four lines, and the first two are where estimates go wrong most often.

• Portal integrations, priced per portal. ServiceChannel and Corrigo each carry real cost, their data models differ, and every client instance is configured differently. An estimate with one integration line and a plan to support several clients is understated.
• Offline mobile. Technicians work in mechanical rooms, basements and parking garages. Proper offline capture with conflict resolution on sync is genuine engineering, and skipping it means a technician loses a completed work order once and stops using the app that week.
• Service level policy migration. Three contracts with three pause rule sets is a configurable engine. Thirty contracts is the same engine plus weeks of careful transcription and validation with your operations team in the room.
• Accounting depth. Pushing approved invoices into an accounting package is straightforward. Two way sync with job costing, work in progress and revenue recognition per contract is a different budget.

In our delivery experience a focused first release covering intake, one portal integration, the asset registry with scan capture, dispatch and the service level engine runs $60,000 to $130,000 over 12 to 16 weeks, with the full platform at $150,000 to $400,000 phased over 6 to 12 months.

What separates a build that works from one that fails here?

Interrogate the offline story before anything else in the demo. Ask what happens when a technician completes three work orders in a basement, comes up to signal, and a dispatcher reassigned one of them meanwhile. If the answer is not a specific conflict resolution rule, they have not shipped field software, and field adoption is decided in the first fortnight of real use rather than by the feature list.

Make them talk about ServiceChannel and Corrigo by name. Ask whether they poll or receive notifications, what happens when a status update is rejected, how they reconcile drift, and what the retry behaviour is. Anyone who answers that they can integrate with anything is quoting a schedule they cannot hold.

Insist that every state change is stored as an immutable event with actor and timestamp, including who paused a clock and why. That log is the only thing that lets you reconstruct a timeline months later when a credit is disputed, and it is cheap at the start and painful to retrofit.

Then confirm ownership of the code, the data model and the deployment, with the repository in your organisation from day one rather than at handover. At Digital Heroes the client owns everything from the first commit. And check that compliance surfaces appear in the first scoping conversation without you raising them: insurance and licence expiry with audit trails, technician location handled as personal data, and whatever access records healthcare or government sites impose. If you have to introduce those topics yourself, keep looking.