Anomaly Detection Best Practices: How to Organise Your Team for Maximum Impact

Why process design matters as much as the technology

Enersee's anomaly detection module continuously monitors your energy data and surfaces deviations: consumption spikes, unexpected baseline shifts, and equipment irregularities, before they become costly problems. It accounts for your buildings' past behaviour and filters out external influences like weather, so every anomaly that surfaces is a genuine signal, not noise.

The most effective customers don't just activate anomaly detection; they design a lightweight, three-line defence structure around it. This article explains what that looks like in practice, who owns what, and how to make the loop close.

The three-line defence model

Based on how our customers organise themselves, we consistently see three distinct roles emerge. Each line has a different relationship with the buildings, a different cadence, and a different type of responsibility.

1st line: The Energy or Data Expert

The 1st line is the first human set of eyes on every new anomaly. Enersee already does the heavy lifting, prioritising anomalies by severity and accounting for historical building behaviour and weather, but the energy expert adds something the algorithm can't: organisational context. They know about the planned maintenance last Tuesday, the temporary production ramp-up, or the meter that's been recently replaced.

Their job is to triage the NEW anomaly queue and make a judgment call:

• False positive / known cause → close the anomaly with a note, no further action needed.

• Genuine signal → move to TO BE IDENTIFIED and dispatch to the relevant 2nd line contact, even if the root cause isn't yet clear.

• Obvious fix → dispatch directly on status PROBLEM DETECTED with suggested action.

The 1st line is the quality gate. They ensure only human-validated, relevant anomalies travel further down the organisation, reducing noise fatigue for everyone else.

Concrete example: A retail store shows a 40% overnight consumption spike. Because Enersee already corrects for weather and the store's typical seasonal patterns, this deviation stands on its own merits. The energy expert reviews it, can't immediately explain it from the central level, and dispatches it to the store's facility manager as TO BE IDENTIFIED with the note: "Unexplained overnight spike — not weather-related, not matching past behaviour. Please investigate HVAC or refrigeration."

2nd line: The Facility Manager or Building Owner

The 2nd line receives anomalies at TO BE IDENTIFIED status and brings local knowledge: Is the freezer room due for a coil cleaning? Did the cleaning crew change their schedule? Was there a one-off event this weekend?

Once the root cause is identified or suspected, they move the anomaly to PROBLEM DETECTED and create a ticket in the facility management (FM) system to dispatch a technician. Critically, that FM ticket ID should be linked to the Enersee anomaly ID; this is what closes the loop and enables learning over time. If no facility management system is present, of course Enersee’s ticketing system can be used.

Concrete example: The facility manager at the retail store receives the dispatched anomaly. Knowing their building, they check the refrigeration unit logs and find the condenser fan motor has been running continuously without cycling. No external factor explains this, Enersee's baseline already filtered those out. They move the anomaly to PROBLEM DETECTED, open a maintenance ticket, and send a refrigeration technician, noting in both systems: "Condenser fan motor suspected fault - continuous run, no cycling."

3rd line: The Technician

The technician receives a work order from the 2nd line (via the FM ticket or through Enersee) and goes on-site. Sometimes the root cause is already pinpointed; sometimes they still need to diagnose a technically complex issue: a faulty sensor, a stuck valve, a VFD behaving unexpectedly.

Once resolved, the anomaly moves to SOLVED. This can happen automatically if your FM system is integrated with Enersee, or manually via an export in the interim. Either way, the key habit is detailed logging in the FM system: what was found, what was done, what parts were replaced. Linked back to the Enersee anomaly ID, these logs are the raw material for root cause pattern recognition: helping the system become smarter about your specific building portfolio over time.

Concrete example: The technician arrives at the retail store, confirms the condenser fan motor has a failing bearing causing it to run without shutting off, and replaces the motor. They log the intervention in the FM system referencing the anomaly ID from Enersee. The ticket closes, and the anomaly status updates to SOLVED. Down the line, when a similar energy pattern appears on a different store, Enersee can surface the historical match: "Similar profile previously linked to condenser fan motor fault."

Setting up the process: a quick-start checklist

Before going live, align on these foundations:

Roles and assignment

• Identify who will be the 1st line energy expert (and their backup)

• Map 2nd line contacts per building or department

• Confirm the technician dispatch process (internal or contractor)

Anomaly workflow configuration

• Align your team on the four statuses: NEW → TO BE IDENTIFIED → PROBLEM DETECTED → SOLVED

• Agree on response time expectations between 1st and 2nd line

• Establish a naming convention for referencing anomaly IDs in tickets (e.g. [ENR-4821] in the ticket subject line)

Cadence and review

• Schedule the 1st line's twice-weekly triage sessions in the calendar

• Set a monthly touchpoint between 1st and 2nd line to discuss recurring patterns

• After 90 days, review closed anomalies: what were the most common root causes? Are there systemic issues to address proactively?

Common pitfalls to avoid

Skipping the 1st line. Some organisations push every new anomaly directly to facility managers. This quickly creates noise fatigue, busy people stop acting on alerts that occasionally turn out to be nothing. The 1st line's validation step is the filter that keeps the system credible.

Not logging root causes. An anomaly resolved without a documented cause is a missed learning opportunity. Even a short note ("HVAC setpoint drift after firmware update") adds compounding value over time.

Treating the ticket ID link as optional. It feels like administrative overhead early on, but this is the mechanism that enables Enersee to build a root cause knowledge base specific to your building portfolio. Invest in the habit before the integration is in place.

Overwhelming the 2nd line. If a facility manager is receiving 20 dispatched anomalies per week, something is broken upstream. Review whether the 1st line's triage criteria are tight enough.

Getting started

If you're deploying Enersee's anomaly detection for the first time, we recommend starting with tighter detection thresholds, surfacing only the most significant anomalies while your team builds familiarity with the workflow. As confidence in the system grows and the three-line process becomes second nature, thresholds can be loosened to catch more subtle deviations across your portfolio.

What requires a bit of thought upfront is the human side: defining your 1st line person, mapping 2nd line contacts per building, and agreeing on how FM tickets will reference anomaly IDs. Your Customer Success contact at Enersee can help you set that up and make sure the first triage sessions run smoothly.

Have questions about setting up anomaly detection in your organisation? Reach out to your Enersee contact or post a question in this community.