Ask a facilities team how reporting works and you'll usually hear a version of the same answer: export to Excel, clean it up, build the pivot, paste it into the deck. Every month. Often by the same one person.

It's tempting to treat that as a discipline problem — the team just needs better habits, or a BI tool, or a template. It usually isn't. The reason reporting is painful in most facilities systems is structural, and understanding the structure tells you which fixes will work and which will waste six months.

Intake systems and reporting systems want opposite things

A work-order system's core job is to capture a request and move it through a workflow: someone reports a problem, it gets triaged, a vendor is assigned, work happens, it closes. That's a transactional job. Success means the record is complete, the right person is notified, and nothing gets lost.

Reporting is an aggregation job. It doesn't care about any individual record; it cares about five hundred of them at once, grouped and counted and compared to last month.

Those two jobs pull design in opposite directions. Transactional systems favour flexibility — let every client configure their own fields, statuses, and categories, because every client's process is different. Aggregation favours constraint — you can only count things that were recorded the same way. Most facilities platforms optimized for the first, because that's what wins deals in a demo. Reporting arrived later, as a module, on top of data that was never shaped for it.

That's the whole story, really. Everything below is a symptom of it.

The five things that actually break your reports

1. No canonical date to anchor on

A single work order has several dates: when it was requested, when it was accepted, when a vendor was assigned, when work finished, when it was closed. Ask “how many work orders in March?” and the honest answer is “depends which date you mean.”

Teams often don't settle this, so different reports quietly use different anchors and stop agreeing with each other. Then nobody trusts any of them.

2. Status taxonomy drift

Over years of use, statuses accumulate. Someone adds “On hold — parts” and someone else adds “Awaiting parts.” A status meant for one edge case becomes a team's default. Nothing forces cleanup, because from the transactional side it all works fine — the record moves, the notification sends.

For reporting it's corrosive. “What percentage is open?” requires deciding which of fourteen statuses count as open, and that decision usually lives in one analyst's spreadsheet formula rather than in the system.

3. Free-text where you needed a category

If the problem field accepts free text, you will end up with “HVAC,” “H-VAC,” “hvac,” “Heating,” and “AC not working” all describing the same thing. Any “top problems” chart built on that column is fiction — the real top category is fragmented across five spellings and the chart shows whichever fragment won.

This is the single most common reason a dashboard looks plausible and is wrong.

4. Incomplete records that only matter in aggregate

A work order with no vendor recorded still closes fine. Nobody notices. But run vendor performance across the quarter and those blanks silently distort every number — and because they're invisible in the transactional view, nobody knows the report is skewed.

5. Period boundaries nobody decided

A job opened in March and closed in May belongs to which month? Both answers are defensible. What isn't defensible is different reports making different choices, which is what happens when the rule lives in a formula rather than the system.

The diagnostic

Want to know how bad it is in your data? Run a count of distinct values on your problem category field, and another on status. If a portfolio of a few hundred properties returns 150+ distinct categories or a dozen statuses, your reports aren't measuring what you think they're measuring — and no reporting tool will fix that.

Why bolting on a BI tool usually disappoints

The instinctive fix is to point Power BI, Tableau, or Looker at the data. Sometimes that works. Frequently it produces an expensive, beautiful dashboard nobody trusts, for three reasons:

  • It inherits the data problems. A BI tool can't un-fragment your categories or decide your status taxonomy. Garbage in, beautifully-visualized garbage out.
  • The business rules move further from the work. The definition of “open” now lives in a BI layer maintained by someone who doesn't do facilities. When the definition needs to change, there's a ticket queue between the question and the answer.
  • It doesn't solve access. Executives get the dashboard. The branch manager who actually needs to see their own eight open jobs still doesn't have anything — so they email someone, and the spreadsheet survives.

BI tools are good at combining data across systems and doing genuinely advanced analysis. They are not a fix for operational reporting that was never designed in.

What actually fixes it

The pattern that works is constraining input so aggregation is possible, and treating reporting as part of the system rather than a layer above it:

  • Picklists, not free text, for anything you intend to count — and scoped per property type, so a bank branch offers vault and ATM while an office offers elevators and HVAC. Requesters pick a real category because that's the only option.
  • One anchor date, decided once. Requested date is usually right: it reflects when demand arrived and doesn't move when a job finally closes.
  • A status lifecycle that means something — a small, ordered set where “open” needs no interpretation.
  • Derived metrics, not typed ones. Response time and completion time should be calculated from the underlying dates, never entered by hand. Anything hand-entered will eventually disagree with the record it describes.
  • Role-scoped views of the same data. Executives see the portfolio, managers see their properties, branch staff see their branch — from one set of records, so nobody needs a spreadsheet emailed to them.
  • Validation at import. If data arrives from another system, check it against the schema before it lands rather than discovering the problems in a quarterly review.

The cost of leaving it alone

It's easy to treat the monthly export ritual as an annoyance rather than a real cost. It usually isn't just an annoyance:

  • The numbers are always old. By the time the deck is built, the picture has moved. Decisions get made on a snapshot of three weeks ago.
  • One person is the reporting system. They know which columns are unreliable and which statuses to exclude. When they leave, that knowledge leaves.
  • Nobody fully trusts the figures — including the person who built them — which quietly caps how much they get used for anything that matters.
  • Questions go unasked because answering them means another export. That's the real loss: not the hours, but the analysis nobody bothers to attempt.
Where Bedrok Pro fits

Bedrok Pro was built with reporting as a first-class concern rather than a module: per-property issue picklists so categories stay countable, a defined status lifecycle, response and completion times derived from the underlying dates, and dashboards scoped by role so each team sees its own slice of the same records. Imports are validated against the property category's schema before anything is saved.

See how the reporting works, or send us a month of your data and we'll show you your own portfolio in it.

If you take one thing from this: before you evaluate any reporting tool, run those two distinct counts on your category and status fields. Ten minutes, and it tells you whether you have a tooling problem or a data problem. They need completely different fixes, and buying software for the wrong one is how six months disappear.

Our export guide covers the data-quality traps in more detail if you want to go deeper.