For technical managers

Making technical follow-up steerable: prioritising deviations explicitly, delegating with an owner and a deadline, and using history to find causes rather than treating each fault as new.

If you are accountable for the technical condition of one or more buildings, your problem is rarely a shortage of information. It is that the information arrives as phone calls, emails and individual people's memories — and none of that can be prioritised, delegated or followed up.

This article is about using Properate as the board you steer from.

What you are responsible for

Quality-assuring and creating measures when deviations or opportunities are identified.

Prioritising cases against risk, comfort, energy, cost and consequence.

Delegating to local operations or to external suppliers.

Following up the backlog, deadlines and open high-priority cases.

Making sure closed cases are actually closed — with enough documentation to be useful later.

Using history, service findings and recurring faults to identify underlying causes.

Use Properate as your board, not as a status screen

The difference matters. Reading status is passive; running the board means every relevant alarm, annotation and open case has an owner and a priority before you close the laptop.

Work from Incident handling, filtered by severity. Anything unassigned is nobody's — and unassigned items are the ones that quietly become next winter's problem.

Prioritise explicitly

Separate three things, and say which is which:

What is urgent — act now.

What should be planned — belongs in a schedule, not in today.

What must be escalated to a property manager or to HQ, because it needs a budget or a decision you do not own.

A case with no priority is not a decision that has been deferred. It is a decision nobody has made.

Delegate so it can be followed up

Every task needs three things before it leaves your hands: an Assignee, a deadline, and a clear expectation of what "done" means. Set Component as well — that is what makes the task findable in two years by whoever opens that piece of equipment.

Check quality at closing, not just status

A case marked finished is not the same as a case that is fixed. Before accepting a closure, look for what was actually found, what was done, and whether the value returned because someone repaired it or because it drifted back on its own.

Weakly documented closures are the main way an organisation loses its own history.

Look for patterns, not incidents

This is the part only you are placed to do. A fault that returns three times is not three faults — it is one cause that has never been addressed.

Use annotations on the component, the service findings attached to the system, and Analysis to see whether the pattern follows the season, the schedule or a particular setpoint. Then raise a measure against the cause rather than closing the symptom for a fourth time.

Step by step: the jobs you do most

Run the weekly board

Open Incidents → Incident handling and filter by severity.

Work top-down: give every relevant item an owner and a priority. Assign to yourself anything you intend to decide on personally.

Open Alarm configuration on anything you do not recognise, to see what condition actually triggered it.

Note which items you are escalating, and to whom.

Turn a deviation into a measure

From the deviation, create a task with New task.

Set Component to the equipment concerned, and give the task a Priority that reflects risk rather than annoyance.

Write what you expect the outcome to be, not only what to do. The next person needs to know what "solved" looks like.

Use Make recurring if the real fix is a routine rather than a one-off intervention.

Clean up the backlog

Filter tasks to those with no assignee, no deadline or no description.

For each: assign it, date it, describe it — or close it with a reason.

A backlog nobody trusts gets ignored, and then the system stops being the source of truth.

Find the cause behind a recurring fault

Open the component in FDV → Components and read its history and attached files.

Check the annotations on it — what colleagues found on site is often the missing piece.

Build an Analysis comparing the misbehaving value against setpoint, outdoor temperature or the governing calendar.

Raise one measure against the cause, and record in the annotation why you concluded what you did.

What good use looks like

No relevant alarm or annotation is left without an owner.

Technical prioritisation happens in Properate, where other roles can see it.

Recurring faults are treated as a cause problem, not as separate cases.

Service reports are connected to the right system, task and follow-up recommendation.

The backlog is reviewed on a fixed rhythm, and old cases are cleared or escalated.

What to avoid

Using Properate only to read status, without actively prioritising.

Letting too many cases stand open with no clear direction.

Continuing to steer by phone and email when the case belongs in the system.

Accepting closures that are weakly documented.

Your first two weeks

Go through every open case and give each one a priority and an owner.

Clear out cases missing a deadline, an assignee or a usable description.

Pick three recurring faults and decide whether each should become a measure.

Use Properate live in your technical follow-up meetings, rather than reporting from it afterwards.

If the system is open on the screen during the meeting, it stays current. If it is something you update after the meeting, it will not be.