How Properate is meant to be used
Most organisations that struggle with building operation do not have an operational problem. They have an information problem: observations stay verbal, measures are not followed up, alarms are acknowledged without action, and nobody has a reliable picture of what is actually happening.
This article describes the working model Properate is built around. It is worth reading once before the module articles, because it explains why they are arranged the way they are.
Properate is a work surface, not a reporting tool
This is the distinction that matters most. Properate is not an analysis package that produces reports about buildings; it is the surface where operation, observations, deviations, measures, documentation and follow-up all live in one place.
Analysis and reporting are in here, and they are useful — but they are outputs of the work, not the point of it. If the system is only somewhere you go to read numbers, most of its value never arrives.
The chain: from observation to documented value
Every part of the product sits somewhere on the same chain:
- Observation — a sensor value, an alarm, or something a person noticed on site.
- Insight — what the observation means once you can see it against history, weather or a setpoint.
- Measure — a decision about what to do, with an owner and an expected effect.
- Execution — the work, done and written down.
- Documented value — the result, visible in the data and available for reporting to owners, tenants and certification schemes.
A break anywhere in the chain wastes everything upstream of it. An observation nobody records cannot become insight. A measure nobody owns is not carried out. Work that is done but not documented cannot be shown to have worked.
Two kinds of KPI — you need both
Following energy consumption alone will not tell you why one building improves and another does not. That takes two separate sets of measures.
Outcome KPIs — what are we achieving?
- kWh/m², temperature-corrected, per building
- Deviation against the energy budget
- Number of recurring technical faults
- Share of planned versus acute work
- Time to close technical deviations
- Estimated and realised value of measures
- Number of open high-priority cases
Compliance KPIs — are we actually working this way?
- Share of tasks handled in the system
- Share of alarms that lead to an assessment
- Time from alarm to a created measure
- Number of annotations registered per building per month
- Share of service reports connected to their context
- Share of checklists completed on time
- Active use per role and per building
Outcome KPIs tell you whether the value arrived. Compliance KPIs tell you whether the organisation is working in a way that makes that value possible. Without both, a building that improves and a building that got a mild winter look identical.
AI supports the work — it does not replace the decision
The principle is deliberate: AI analyses and proposes — pattern recognition, deviation detection, prioritisation. People assess, decide and carry responsibility.
Two consequences follow. Decisions should stay understandable and checkable, so the organisation can build justified trust in what is suggested. And the quality of structure you keep today sets the ceiling on what any of this can do later: good structure now means better suggestions later; poor structure now limits them permanently.
Working alongside an existing FDV system
Worth clearing up a word first. FDV means two different things in this help centre. Properate has its own FDV module — the building's profile, systems, components and files. Separately, many organisations already run a dedicated FDV system for work orders. This section is about the second one.
Properate is built to work either as a supplement to an existing FDV system, or as the whole platform where none exists. One principle holds in both cases: deviations are identified in Properate, measures are prioritised in Properate, and effect is measured in Properate.
- Model A — Properate as the primary platform. Recommended. Deviations and measures are handled here; relevant work orders can be passed to the FDV system. Highest traceability and the most learning over time.
- Model B — shared responsibility. Deviations are identified in Properate, work orders are created in the FDV system, and status is linked back. A realistic fit for established organisations.
- Model C — FDV-dominated. Properate is used for analysis and insight only, and measures are handled elsewhere. Recommended only as a transitional arrangement, because the chain above is broken between insight and execution.
What has to be true for this to work
The effect does not arrive because the software is in use. It arrives when the organisation agrees on a few things:
- Properate is the operational source of truth — not parallel spreadsheets, email threads or verbal agreements.
- Roles and responsibilities are defined, and each role knows what it owns.
- Local operations experience the system as help in their working day, not as supervision from above.
- Management uses the system itself, rather than asking for reports out of it.
- Compliance KPIs are followed as closely as energy figures and costs.
- Parallel ways of working are phased out rather than kept alongside.
The goal is not that people use Properate. It is that the buildings run better because the way of working changed.