Utilisation is assumed rather than measured
Badge and booking data exist but sit outside the reporting, so decisions about how much space is needed rest on impressions of how busy the office looks.
Corporate real estate
Corporate estates are managed from a lease database, a facilities system and a badge-in feed that were never designed to be read together. The result is that space decisions get made on assumptions about utilisation nobody has tested. We join the lease commitments, the running costs and the actual occupancy so the cost of a desk, a floor and a break option are all known numbers.
Discuss your operationWhat we usually find
Badge and booking data exist but sit outside the reporting, so decisions about how much space is needed rest on impressions of how busy the office looks.
Break clauses and rent reviews live in a document store rather than in a calendar anybody reports on, so the option is often noticed after it has passed.
Rent, service charge, facilities, utilities and fit-out sit with different budget holders, and no single view adds them up per building.
Where we start
Scope depends on the state of your systems. These are the pieces that recur in this sector.
Rent, service charge, facilities and utilities joined per building and per floor, on one definition across the estate.
Badge, booking and sensor data turned into a defensible measure of how much space is genuinely in use, and when.
Breaks, reviews and expiries surfaced with enough notice, and costed, so the option is a decision rather than a deadline.
The cost and headcount consequences of consolidating, subletting or exercising a break, modelled on the joined data.
What changes
You own all of it: the code, the written definitions and documentation aimed at whoever maintains this after us.
The builds behind it
Your finance, customer and operational records joined into one dataset, with each figure defined once and traceable back to the system it came from.
Reporting built on top of the joined data, aimed at the few revenue and cost drivers that actually change the result.
One defined task, automated inside a process that already exists, measured against whatever it replaced.
Driver-based models built on the same definitions as your reporting, so the forecast and the actuals stop disagreeing.
Worth asking