A typical remote monitoring platform, out of the box, will happily track several hundred parameters per site — voltages, temperatures, states of charge, door contacts, fuel levels, signal metrics — each on its own default alarm threshold. It looks comprehensive in a product demonstration. In operation, it usually produces the opposite of what was intended.

The assumption behind most RMS deployments is that more visibility automatically produces better operations. In ESC's experience, the limiting factor is almost never how much data is available. It's how much of it a NOC team can actually turn into a decision.

The default-threshold problem

Vendor-supplied alarm thresholds are typically set conservatively, to protect the vendor rather than to reflect a specific site's normal operating range. Deployed unchanged across an estate with real variation in climate, site type and equipment age, the result is a high volume of alerts that don't represent a real operational risk. Operators adapt the only way they can — they start triaging by pattern recognition rather than by reading each alert, and eventually the genuinely urgent alert arrives indistinguishable from the routine noise around it. This is alarm fatigue, and it is a design failure of the deployment, not a limitation of the technology.

RAW MONITORED SIGNALS (100s) SITE-CALIBRATED THRESHOLDS DECISION-RELEVANT SIGNALS OPERATIONAL DECISION
FIG. 01 — DESIGN FLOW: DECISION BACKWARD, NOT DATA FORWARD ESC / EESAFRICA.COM

Start from the decision, not from the sensor list

The RMS deployments ESC has seen produce a genuine operational improvement all share the same design habit: they start by naming the specific decision the system should improve, and work backward to the minimum data set and logic required to support it. A few examples of what that looks like in practice:

  • Outage prevention — correlating battery state of charge with generator runtime patterns to flag sites at meaningful risk of depletion 24–48 hours ahead, rather than alarming only once a site has already gone down.
  • Maintenance prioritisation — using trend data, not point-in-time readings, to schedule preventative generator or battery maintenance where degradation is actually accelerating, instead of running a fixed calendar-based visit schedule across every site regardless of condition.
  • Truck-roll avoidance — using door-contact and equipment-status data to distinguish a fault that can be resolved remotely from one that genuinely requires a site visit, before a technician is dispatched.
  • SLA evidence — retaining the specific data series an operator's SLA actually references, so compliance can be demonstrated without manually reconstructing it after the fact.

Each of these uses a small, specific slice of what the platform is technically capable of collecting. None of them require the full parameter list turned on with default thresholds.

The practical implication

A dashboard nobody opens and an alarm nobody trusts are the same failure mode: data was collected without a decision attached to it. The measure of a good remote monitoring investment isn't the number of parameters monitored — it's the number of operational decisions it visibly changes.

Integration matters as much as sensing

A platform that surfaces excellent data but sits outside the NOC's existing ticketing, dispatch and OSS workflow becomes another screen someone has to remember to check, rather than a system that changes behaviour by default. Integration into the operational workflow already in use — so the right person receives the right alert in the tool they already work in — often does more for operational outcomes than adding another sensor type ever will.

What this means when scoping an RMS investment

  • Name the two or three operational decisions the investment is meant to improve, before evaluating platforms.
  • Calibrate alarm thresholds to each site's real operating range, not the vendor default, before go-live.
  • Judge the platform on its integration into existing NOC and dispatch workflows, not on parameter count.
  • Track the business case against the decisions it changes — outages avoided, truck rolls avoided, maintenance shifted from reactive to preventative — not against "data visibility" as an end in itself.

None of this argues for collecting less data than the technology allows. It argues for being deliberate about which of it earns a place in front of a human, and for treating "did this change an operational decision" as the real success measure — not "is it being collected."