📌 Key Takeaways
Define every monitoring duty, handoff, record, and outage responsibility in writing before recurring service begins at any lift station.
Separate Automation From Action: List what the platform handles automatically and which people acknowledge alerts, respond, escalate, and confirm closure.
Assign Every Handoff: A delivered or acknowledged alert never proves resolution, so assign ownership through field response and closure.
Define Coverage By Activity: Document covered stations, duties, hours, time zones, exclusions, and off-hours owners instead of relying on broad service labels.
Separate Records And Timing: Treat report frequency, alarm timing, accessible history, retention, exports, and review ownership as separate requirements.
Plan For Visibility Loss: Name who detects outages, informs operations, manages temporary arrangements, and confirms usable remote information has returned.
Clear ownership turns alerts into reliable action.
Municipal utility leaders and operators will reduce coverage gaps by using the scope questions and planning matrix below.
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
A useful coverage definition does more than confirm that remote visibility exists. It specifies which functions are included, when each duty applies, who owns every handoff from notification through resolution, what records are expected, and how responsibility is handled when remote information becomes unavailable.
That specificity matters because remote telemetry (the remote transmission of operating information from a station to a monitoring platform) can leave a gap between what the technology does automatically and what a person is expected to do next. A controller may detect a high-water condition and send a notification within seconds, yet no document may identify who acknowledges that notification, who escalates when the first recipient is unavailable, or who coordinates the field response. Those responsibilities do not assign themselves when the subscription begins.
The framework below organizes the scope items a municipal utility should define before finalizing any recurring monitoring arrangement. It is a planning tool, not an operating procedure. Site-specific assignments require qualified operational review.
Define the Coverage in Writing
The first step is separating what the monitoring platform does from what a person or team is responsible for. Four categories help structure that separation: station and controller functions, remote information and automated notifications, provider duties, and utility operational duties.
Station and controller functions include the conditions monitored (water level, pump status, power, communication health) and the alarm thresholds configured for each station. Remote information and automated notifications include the data the platform collects, the reports it generates, and the alerts it sends when a threshold is met. Provider duties may include hosting the platform, delivering notifications, offering technical support, and providing configuration assistance. Utility operational duties include acknowledging alerts, dispatching personnel, coordinating field response, and confirming that the event is resolved.
Describing duties by activity, rather than relying on plan labels, helps surface a common friction point: procurement, operations, and support staff may each hold different expectations about what "monitoring coverage" includes. The person who approved the subscription, the operator who receives the alerts, and the support contact who helps configure the platform may each assume a different scope. Defining duties by activity makes those assumptions visible before they create an operational gap.
A common misunderstanding is that "continuous monitoring" means continuous human oversight. Ask which activities are automated (data collection, threshold comparison, notification dispatch) and which require staffed action that has been documented and assigned. A service may support automated notifications during a stated period without providing human oversight during that entire period. If staffed duties matter to the utility, their coverage periods and boundaries should be documented separately, including the applicable time zone.
OmniSite's GuardDog documentation lists customizable callout lists with email, text, and phone call options, historical data, and report export. Those are platform capabilities. They describe what the software can deliver, not who acts on the information once it arrives.
Use the matrix below to organize scope questions. Each row identifies a category to define, the specific details to document, the ownership or boundary to clarify, and the record to request or agree upon.
Scope Item | Define Explicitly | Owner or Boundary to Clarify | Record to Request or Agree |
|---|---|---|---|
Covered functions and stations | Which locations, monitored conditions, and services are included or excluded? | Who confirms scope changes? | Covered-station and function list |
Coverage hours | When are automated functions, staffed duties, and support each available? | Who owns duties outside the stated hours? | Coverage periods and applicable time zone |
Notifications and event context | Which recipients and channels are intended, and what information is needed? | Who maintains recipients and requested content? | Notification requirements and contact ownership |
Acknowledgment and escalation | What counts as acknowledgment, and when does a handoff occur? | Who takes the next duty, and what does acknowledgment establish? | Reviewed escalation responsibilities |
Operational response | Who assesses the event, coordinates action, and confirms closure? | What remains with the utility or another designated party? | Agreed response and closure responsibilities |
Reporting and retention | Which records, reporting frequency, accessible history, retention, and export provisions are needed? | Who supplies and reviews each item? | Agreed reporting and record-access requirements |
Loss of remote visibility | Who recognizes, communicates, and coordinates recovery from an information gap? | Which duties are covered, excluded, or handled elsewhere? | Reviewed outage responsibilities and limitations |
Completing the matrix for a single station often reveals which responsibilities have not been assigned at any station.
The matrix also gives teams a place to record exclusions. Knowing what is not covered can be as important as listing included functions, especially when a broad service label could create different assumptions among purchasing staff, support personnel, and operators.
Assign Ownership from Notification Through Resolution
A notification reaching a designated recipient is not the same as someone owning the next step. Coverage definitions should separate five responsibilities: receipt, acknowledgment, escalation, operational response, and closure.
Receipt confirms that the notification was delivered to an intended channel. Acknowledgment confirms that a person has seen the notification and accepted responsibility for evaluating it. Escalation is a planned handoff: when a defined condition is met (for example, no acknowledgment within an agreed period), the duty moves to the next person or role on the list. Operational response is the assessment, coordination, and field action needed to address the event. Closure confirms that the underlying condition has been resolved and normal operations have resumed.
An acknowledged alarm should not automatically be treated as a resolved event. The agreed process should state what acknowledgment establishes and which responsibility follows it. For instance, an operator might tap 'acknowledge' to mute a 2:00 a.m. alert on their phone via the GuardDogâ„¢ 2 Mobile App, intending to check the station at dawn, without realizing the system considers the event resolved and halts the escalation to the backup operator on the callout list.Â
Consider a hypothetical municipal example. A high-water alarm triggers an automated notification to the on-call operator. The operator's phone receives the alert, but no one has documented what happens next. Does acknowledging the alert in the software mean the operator has accepted dispatch responsibility? If the operator cannot respond, does the system escalate to a supervisor, or does the operator need to contact someone manually? Who confirms that the pump is running and the water level has dropped?
A likely objection is that an existing callout list already resolves accountability. It may, but it is worth asking which of these five responsibilities the list actually documents. A callout list typically identifies who receives a message. It may not specify who accepts the next duty after receipt, who escalates when no one acknowledges, who coordinates the field response, or who confirms closure.
Address recipient maintenance as well: when staff change roles, shifts, or contact information, identify who updates the callout list and how quickly that update should take effect. Excessive notifications can compound these maintenance questions, and they are often a service-scope problem rather than only a technology problem. Defining which roles need which information, who owns recipient changes, and what event context those recipients require gives the utility a clearer basis for reviewing notification needs.
Off-hours ownership deserves the same clarity. Define whether after-hours duties differ from daytime duties, and confirm who holds responsibility during each period. Any applied escalation assignment should be confirmed with the responsible operations lead before implementation.
These assignments require qualified operational review before they are used as working procedures. The matrix and scenarios in this article are planning aids, not approved response protocols.
Specify the Information and Records the Team Needs
A monitoring arrangement generates several types of information that serve different purposes. Treating them interchangeably creates misaligned expectations.
Requested event context deserves early attention. The operations team should define what information it needs when an event occurs — the station or asset involved, the monitored condition, event status, applicable timestamps, recipient information, or other details the team considers necessary. These are information requirements to specify in the scope, not assumed platform fields.
Reporting frequency refers to how often the platform delivers a scheduled summary. A daily report and a fifteen-minute analog update serve different operational needs. A reporting interval is not the alarm-response time. Scheduled reporting tells the team about historical or periodic conditions; alarm notification addresses a threshold event that may need immediate attention.
Alarm notification timing refers to how quickly the system sends an alert after a threshold is crossed. This is separate from how quickly a person acknowledges or acts on that alert. OmniSite's technical documentation states that the system logs state changes that trigger alarms and dispatches notifications to designated recipients. Understanding how that logging works helps clarify what information is captured automatically.
Accessible history describes how far back a user can view records through the platform. Visible history does not by itself establish a retention arrangement. Ask separately about accessible history, agreed retention terms, export provisions, and review ownership. Retention is a commitment about how long records are preserved and under what terms they remain accessible. Export is the ability to extract records in a usable format.
Review ownership identifies who is responsible for examining the records and acting on what they show. Records without a clear review owner can accumulate without anyone checking for patterns or conditions that need maintenance attention. Specify who receives each type of record and who is responsible for reviewing it.
A useful scope definition addresses each of these items separately: what records are generated, how often they are delivered, how far back they are accessible, how long they are retained, whether they can be exported, and who reviews them.
The same discipline applies to changes. If station coverage, monitored functions, contacts, or record requirements change, the scope should identify who confirms each change and who updates the corresponding documentation. Without that assignment, scope adjustments can take effect in the platform before anyone revises the written record of what was agreed.
Define Responsibilities When Remote Visibility Is Unavailable
Remote monitoring depends on connectivity, power, and platform availability. When any of those is interrupted, the utility loses the information it normally relies on for operational awareness. A scope definition should address what happens during that gap.
To illustrate how this gap affects operations, imagine a scenario where connectivity drops. A cellular service interruption occurs outside ordinary office hours at a station with no local staff presence. The platform stops receiving data, and automated notifications stop reflecting current conditions. Who recognizes that the information has become unavailable? Who communicates the status to the operations team? Who coordinates interim arrangements until visibility is restored?
These questions belong in the coverage definition because the answers depend on agreed responsibilities, not on the monitoring technology alone. The provider may have a role in communicating a platform-level interruption, while the utility may own the operational response to a site-level connectivity loss.
Planned interruptions need similar treatment. If remote visibility will be intentionally unavailable for a known period, the scope should clarify who communicates the interruption in advance, which responsibilities remain in effect during the outage, which are handled elsewhere, and who confirms the transition back to the normal arrangement.
A related assumption to address is that technical support will manage the station incident. Technical support for restoring a connection and operational responsibility for the station during the information gap are different duties with different owners. Identify the support scope and the operational response owner explicitly. Do not assume that one includes the other.
Restoration coordination is its own responsibility. Define who confirms that expected remote information is available again for operational purposes. Do not assume that restored connectivity, a completed support ticket, or a returned data feed automatically closes every operational responsibility connected to the interruption.
Define the following: who identifies that remote information is unavailable, who communicates the status to affected personnel, who coordinates any interim operational arrangements, and who confirms that remote visibility has been restored. Also identify which of those duties are included in the monitoring arrangement and which fall outside it. Do not infer data backfill, offline monitoring behavior, restoration times, redundant communications, or recovery guarantees from the existence of remote monitoring. Outage assignments and related operating decisions require qualified operational or technical review before they are used in practice.
Questions to Settle Before Finalizing Coverage
Two questions frequently arise during scope discussions. Addressing them before the arrangement is finalized can prevent misunderstandings during operations.
Does help configuring a monitoring system include ongoing alarm response?
Configuration assistance and ongoing alarm-response responsibility are separate scope items. OmniSite's Activate page describes configuration services for GuardDog alarms, contacts, and settings. That description addresses initial setup, not a recurring duty to respond when alarms occur during operations. If a utility's team carries setup expectations into the recurring arrangement, the distinction may not surface until an event requires a response that no one has been assigned. Confirm both the configuration scope and the ongoing response scope as separate items. Any provider duty expected after setup should be supported by the applicable service scope rather than assumed from the availability of setup assistance.
Does every lift station need the same monitoring-service scope?
A common documentation format can accommodate differences in included functions, coverage hours, assigned owners, and required records across stations. Whether those differences are appropriate depends on reviewed operational needs: a station with redundant pumps and a station serving a critical interceptor may warrant different notification priorities, escalation timelines, and outage arrangements. The matrix above can be completed once per station where reviewed needs differ, using the same structure to keep documentation consistent without forcing identical scope where it does not fit.
Settle Unresolved Ownership Before the Arrangement Begins
The most consequential gaps in monitoring coverage are rarely about the technology. They are about responsibilities that were assumed but never assigned: who acts after a notification arrives, who owns the escalation when no one acknowledges, who manages the station when remote visibility is lost, and who reviews the records once they exist. Turning monitoring capabilities into defined responsibilities is the work that makes a recurring arrangement operational.
Use the coverage matrix to prepare questions for your operations lead and service provider. Start with the station where unclear ownership would create the most operational risk, and document the answers before extending the arrangement to additional sites. When contact information changes, staff rotate, stations are added, or service terms are modified, revisit the scope to confirm that ownership still reflects the current arrangement.
Disclaimer: This article is for general informational purposes only and does not constitute compliance, safety, technical, or professional advice. Requirements, risks, and best practices may vary by context, jurisdiction, system, provider, or use case. Confirm important decisions with the appropriate qualified professional, authority, or technical expert.
Our Editorial Process:
Content is developed from OmniSite source materials and reviewed for clarity, usefulness, and factual consistency. It is intended to help municipal and utility professionals evaluate monitoring and response-readiness options and should not replace site-specific engineering, electrical, regulatory, or safety guidance.
By the OmniSite Insights Team
The OmniSite Insights Team turns field-tested monitoring, alarm-notification, and municipal infrastructure knowledge into practical guides for wastewater, water, and remote equipment teams. OmniSite manufactures control systems that support early warning for lift stations, water systems, wastewater systems, and airfield lighting applications.