For advisers and consultants

Closing the gap between analysis and effect: turning findings into measures with an owner and an expected result, and following them until the effect shows in the data.

If you advise on buildings you do not operate — as an energy consultant, technical adviser or technical account manager — your risk is specific. The analysis is right, the report is read, and nothing changes.

Insight that stops in a PDF has no effect. This article is about the parts of Properate that turn a finding into a measure someone owns.

What you are responsible for

Documenting observations and analyses so that operations and the customer can use them.

Creating or recommending concrete measures, in the system rather than in a document.

Connecting each measure to the building, the system, the problem and the expected effect.

Contributing to prioritisation when measures must be weighed against cost, risk and capacity.

Following up whether the measure was carried out, and whether the expected effect actually arrived.

Make the analysis operational

Every analysis should end somewhere concrete. Before you consider a piece of work finished, it should have produced either a task with an owner, or a written recommendation attached to the thing it concerns.

Build the analysis in Analysis — timeseries for "what happened and when", XY graph for the relationship between two values, heatmap for patterns across days and hours. Then share it so the finding stays reachable, rather than living only in your own export.

Describe context and value, not just the observation

An observation on its own cannot be prioritised against anything. Three things make it decidable:

What the problem is — the measurement, and the period it covers.

Why it matters — energy, comfort, technical condition or risk.

What effect the measure is expected to have — estimated where you can, described where you cannot.

An estimate you have flagged as uncertain is more useful than no estimate. It gives the customer something to weigh, and it gives you something to check afterwards.

Be concrete about ownership

A recommendation without a named recipient and a next step is rarely carried out. Agree with the customer who decides and who executes before you hand the work over — that conversation is much harder to have after the report has been sent.

Follow the case after delivery

Advice becomes valuable when it has been prioritised, carried out and evaluated. That means coming back: was the measure completed, and did consumption, comfort or fault frequency move the way you expected?

Use temperature-corrected figures when you check. A mild winter can make a measure look successful when nothing changed, and a cold one can hide a real improvement.

Build learning across buildings

Connect findings to history and to earlier patterns. The value you add over time is not a single analysis but the accumulated observation that this fault, in this building type, usually turns out to be this cause.

Record that reasoning in an annotation on the system it concerns. The next adviser — possibly you, in two years — starts from your conclusion rather than from the raw data again.

Step by step: the jobs you do most

Turn an analysis into a measure

Build the analysis and select the period that shows the pattern, not just the incident.

Note the finding as an annotation on the building, system or sensor it concerns, with a level that matches its seriousness.

Create a task with New task, set Component, and describe the expected effect in the task itself.

Agree an Assignee with the customer rather than leaving it open.

Check whether an earlier recommendation worked

Open the component or system and read its annotations and task history.

Compare the relevant period before and after, temperature-corrected.

Record what you found — including when the effect did not appear. A measure that did not work is worth as much to the next decision as one that did.

What good use looks like

Recommendations are concrete, prioritisable and attached to the right context.

Measures carry an estimated value or expected effect wherever that is possible.

Dialogue with operations and the technical manager happens in the system, or close to it.

Effect is followed up after execution, not assumed.

Reports support the case — they do not replace follow-up in Properate.

What to avoid

Delivering a report with no operational follow-up.

Giving general advice with no named owner and no expected gain.

Finishing when the recommendation is sent, rather than when the effect has been checked.

Producing analyses that cannot be converted into prioritisation.

Your first two weeks

Make sure every new analysis results in a concrete measure in the system.

Describe expected effect and the basis for prioritisation explicitly.

Agree with the customer who decides and who carries out.

Follow up two or three earlier recommendations and document the actual effect.