A product demonstration should do more than show polished equipment. It should let your aquatics team test the complete path from an underwater event to a staff response. Using scenarios that reflect your facility, staffing model, and emergency procedures. The goal is not to replace lifeguard supervision. It is to determine whether the technology can add a practical layer of protection without creating confusion during a busy shift.
Schedule a drowning detection system demo
A drowning detection system demo should prove how wearables or lifeguard tags initiate an alert, how the GUARDian Hub (w3000) communicates it, and which staff members receive each escalation. WAVE describes GUARDian as a system for supervised swimming environments that monitors underwater activity and alerts staff, but the right configuration depends on your facility's needs. See how the GUARDian system works.
Bring the people who will operate, hear, manage, and review the system. Then ask the vendor to demonstrate each step clearly, including what happens when an alert is triggered, who acts first, and how the event is documented. Start by defining the evidence your team should expect before discussing features or pricing.
A drowning detection system demo should make the complete path visible, from an underwater trigger to staff awareness and an appropriate response. The goal is not to watch a polished product presentation. It is to test how the proposed configuration could support lifeguards in your supervised aquatic environment, using your staffing model, pool layout, and operating procedures.
Start with the swimmer-wearable scenario. Ask the product team to show what happens when an AquaSense wearable is submerged. WAVE describes an adjustable delay timer that begins when the wearable goes underwater. If the submersion continues through the preset window, the system can initiate an alert to staff. Ask which settings are configurable, who controls them, and how the chosen threshold fits your facility's supervision plan. The timer is intended to help minimize false alarms. But a demonstration should still show how staff interpret and respond to an alert rather than treating it as proof that every incident will be detected.
Next, follow the signal through the GUARDian system. WAVE describes a central hub that connects swimmers, lifeguards, and staff. During the demo, identify the first person who receives the notification and the form it takes. Swimmer-wearable alerts are described as reaching vibrating staff bracelets, while spoken-word alerts can communicate that an event is underway and request facility staff assistance. Have the team demonstrate the actual sound, vibration, and visibility in the areas where your staff work. A feature that is technically available but difficult to notice in a busy pool deserves further discussion.
Request a second scenario involving a lifeguard entering the water. WAVE says a submerged lifeguard tag can trigger the hub to activate staff bracelets, followed by audio and visual alerts. This lets your team evaluate whether the system supports rescue coordination without interrupting the lifeguard's primary task. Ask whether the hub can connect guards to staff, swimmers, or both, since WAVE describes those as configuration choices. Confirm what each role is expected to do after an alert and where responsibility transfers if the first recipient does not respond.
Finally, test the workflow with the people who would use it every day. Include a lifeguard, supervisor, and any facility staff expected to hear or act on an announcement. Review the alert sequence, the handoff, and the documentation produced afterward. A useful demo should leave decision-makers with observed evidence and facility-specific questions, not a promise of guaranteed safety or a substitute for vigilant supervision. Review the available swimmer wearables alongside the hub and staff-alert components so the proposal reflects the complete operating system.
A useful demo proves how a configured system moves from a submerged wearable or lifeguard tag to recognizable staff alerts and a defined response. While keeping lifeguard supervision at the center.
A useful demonstration should let your actual staff experience each alert channel and confirm who responds at every stage.
Do not evaluate a drowning detection system demo only from a sales presentation. Ask the team to run realistic scenarios with the people who will supervise the water, manage the facility, and support an incident. The goal is not to prove that technology replaces lifeguards. It is to see whether the proposed configuration adds a clear, workable layer of support to your existing supervision plan.
For a swimmer-wearable scenario, ask what happens from submersion through staff response. WAVE describes an adjustable timer that begins when a wearable is submerged. After the timer elapses, lifeguards can be notified through vibrating bracelets. During the demonstration, have guards wear the bracelets in their normal positions and move through the areas where they would actually work. Ask them to describe what they felt, how they identify the alert, and how they would acknowledge or investigate it. These details matter more than simply seeing a device activate.
Next, test the escalation channels that are documented for the proposed system. WAVE describes clear spoken-word alerts that request facility staff assistance. For a lifeguard-entry scenario, a submerged lifeguard tag can trigger staff bracelets, followed by audio and visual alerts from the GUARDian Hub. Ask the presenter to demonstrate the spoken announcement, visual indicator, and any siren function included in the configuration. Confirm where each signal can be heard or seen, especially near mechanical rooms, offices, outdoor decks, and other noisy areas. The lifeguard alert equipment page can help your team prepare questions about tags and staff notification.
Routing and delay settings should be discussed as operational decisions, not assumed defaults. WAVE says a facility can choose whether its hub connects guards to staff, swimmers, or both. Ask which roles receive the initial bracelet alert, when a spoken or visual alert follows. And whether routing or delays can be adjusted for your pool layout and staffing model. Do not accept a generic response-time promise. Instead, document the intended sequence and test it with a guard, deck supervisor, and the staff member who would provide additional assistance.
Finish by asking each role what they are expected to do after an alert. A lifeguard should know how the bracelet supports the visual scan and response. A supervisor should know when to coordinate coverage or escalation. Front desk, security, or other facility staff should understand what a spoken or visual notification means and what assistance they are authorized to provide. Compare the proposed workflow with your existing lifeguard alert device features checklist, then record any configuration questions before requesting a proposal.
A useful drowning detection system demo should involve the people who will receive, interpret, and act on an alert. Ask the provider to walk through the workflow with your actual lifeguards, supervisors, facility staff, and administrators rather than limiting the conversation to a product specialist. The goal is to confirm how the proposed configuration supports supervision and response at your facility, not to assume every role or integration is included.
Test the complete path from detection to response with the staff who will use it. A demo is most valuable when each person knows what they should see, hear, or do next.
Start with the people closest to the water. Ask a lifeguard to wear the proposed alert device, then request a realistic scenario involving swimmer submersion or lifeguard water entry. Confirm which lifeguards receive the initial alert, whether the signal is distinct from routine communication, and how a supervisor knows who is responding. WAVE describes lifeguard tags as detecting water entry and communicating that event to staff, but the exact routing and equipment should be confirmed for your proposed configuration.
Useful questions include: What happens when one guard enters the water? Which other staff members are notified? Can the alert be acknowledged or escalated? What is the local procedure if the first responder is already handling another incident? Include these questions in your service and support guide discussion so training and response responsibilities are documented together.
Supervisors should test how the system fits into zone coverage, rotation changes, breaks, and opening or closing procedures. Ask them to run an alert while staff are positioned in different areas of the facility. If the proposed setup includes spoken announcements, remote speakers, sirens, or LED indicators. Verify where each signal can be heard or seen and who is responsible for confirming the response. Do not treat an escalation feature as automatically available in every system configuration.
Facility staff outside the deck team may need a defined supporting role. Ask whether front desk, security, maintenance, or operations personnel can receive a relevant notification, and whether their involvement is appropriate for your facility's emergency plan. For hotels, resorts, or facilities with distributed staff, clarify how an alert reaches the designated responder without creating confusion or exposing unnecessary information.
Administrators should test the workflow after the immediate event. Ask who can review activity, update staff permissions, check equipment status, and document an incident. If Hub Management Software or CompleteView is part of the proposal, request a live view of the roles and records available to your team. Confirm which users can access those functions and what data can be exported. WAVE's lifeguard support system guide can provide useful context, but the demo should answer configuration-specific questions.
Before ending the demo, have each role describe its next action in its own words. Then ask the technical team to repeat the scenario with a missed acknowledgment, a staff change, and a non-emergency alert. This practical test reveals gaps that a feature list cannot, and gives your team a clearer basis for evaluating the system.
A useful drowning detection system demo should cover the operational handoff, not only the equipment. Ask the technical team to walk through how the proposed system would be introduced at your facility. How staff would learn the alert workflow, and how routine checks would fit into the normal pool schedule. WAVE describes implementation as including plug-and-play deployment, facility operation during setup, staff education, and system optimization, but the details should be confirmed for your site and configuration.
Plan the evaluation around a practical sequence: install and configure the system. Train the people who will respond, test the complete alert path, and establish an ongoing equipment-check routine.
Before approving a rollout, document the named owners, testing scenarios, escalation settings, and maintenance checkpoints. For additional context on how this technology supports aquatic staff, see drowning detection technology for lifeguards. Those questions will make a live demonstration more useful and expose operational gaps before they affect a real shift.
A live demonstration should cover more than the alert itself. Ask to see how administrators monitor the GUARDian system after installation, how staff access is controlled. And what records are available when an event or recurring alert needs review. The goal is to understand the operational picture your team would have, not to assume every function is included in every proposed configuration.
HMS and CompleteView can help teams review equipment status, alert activity, incidents, and historical patterns. During a drowning detection system demo, confirm which capabilities, permissions, reports, and data controls are included for your facility.
Ask the product team to walk through Hub Management Software (HMS) using roles that match your organization. WAVE describes HMS as supporting equipment-status tracking, low-battery notifications, configurable alert thresholds, staff permissions, and activity logging. Request a clear demonstration of each item rather than a feature list. Can an administrator identify equipment that needs attention? How are low-battery conditions presented, and who receives those notifications? Which users can change alert thresholds, add staff, or review activity?
Also ask how permissions are assigned and changed when staff members move between roles. A facility may need different access for a lifeguard, aquatics director, maintenance lead, and regional administrator. Confirm whether the proposed configuration supports those distinctions, what activity is recorded, and how an administrator reviews a change later. The GUARDian system overview can provide useful product context, while the service and support guide is a starting point for questions about ongoing operational assistance.
Ask to see the path from an alert to an incident record. What information is captured, who can add notes, and can authorized users distinguish emergency events from non-emergency alerts? WAVE describes CompleteView as providing incident analytics, non-emergency alert pattern detection, historical reports, and data export for compliance documentation. Treat those as documented capabilities to examine in the demo, then ask which report formats and export options are available in your proposed setup.
Useful questions include: How far back can authorized users review activity? Can reports be filtered by facility, date, alert type, or equipment? How are corrections handled if an incident record is incomplete? Can exported data be opened in the tools your organization already uses? For a broader planning perspective, review aquatic risk management technology and bring any reporting requirements from your risk, operations, or leadership teams to the technical Q&A.
Ask what information the system collects, where it is available, how long records are retained, and who can view or export them. Confirm whether permissions apply separately to HMS and CompleteView, and ask what happens when an employee leaves or a facility changes administrators. These are configuration and policy questions, not assumptions about security or compliance. Have the vendor explain the proposed data flow in plain language, then document the answers for the people responsible for privacy, records, and incident review.
A useful drowning detection system demo should leave your team with more than a product impression. It should clarify how the proposed configuration fits your facility, who owns each operating step, and what evidence supports the vendor's recommendations. Sensor-based approaches are described in research as practical, cost-effective, and widely applicable, but the right deployment still depends on your site, staffing model, and operating requirements. Schedule a demo with the people who will approve, operate, and support the system.
Before requesting a proposal, ask the vendor to demonstrate the complete alert workflow, identify configuration assumptions, and document responsibilities for deployment, training, maintenance, data, and support.
| Demo area | Ask the vendor | Evidence to request | Internal owner |
|---|---|---|---|
| Alerts | Which alert types, escalation steps, and staff notification methods are included in the proposed configuration? | Live scenario from detection through staff response, including any adjustable settings. | Head of aquatics and lifeguard lead |
| Roles | How are permissions and responsibilities assigned across lifeguards, supervisors, administrators, and other responders? | Role matrix, access examples, and a test account or workflow. | Operations and risk management |
| Deployment | What site information, layout review, equipment, and installation steps does the proposal assume? | Facility-specific deployment plan, coverage assumptions, and exclusions. | Facilities and procurement |
| Training | What staff education is included, who delivers it, and how will new or seasonal staff be onboarded? | Training agenda, operating materials, and recommended practice scenarios. | Training manager |
| Maintenance | How will the team monitor equipment status, battery condition, configuration, and system health? | Maintenance responsibilities, alert examples, service process, and support terms. | Facilities or technical services |
| Data | What activity, incident, and historical data can authorized users review, export, or retain? | Sample reports, data-access description, retention assumptions, and permission controls. | Risk, compliance, and IT |
| Support | What support channels, response process, optimization help, and multi-facility capabilities are included? | Service scope, escalation contacts, implementation timeline, and portal capabilities to be confirmed. | Executive sponsor |
| Proposal assumptions | Which capabilities, quantities, coverage, support terms, and current pricing options are conditional on the final site assessment? | Itemized quote with inclusions, exclusions, dependencies, renewal or term assumptions, and validity date. | Procurement and finance |
Use the vendor's answers to separate documented capabilities from items that require confirmation. WAVE describes implementation as including staff education and system optimization, and its sales process includes a live demonstration and technical-team Q&A. Ask the team to show what is included in your proposed configuration rather than assuming every feature is standard. For multi-site organizations, ask whether the WAVE Portal's management and remote-configuration functions apply to your account and facilities.
Finally, review the current pricing options only alongside the written proposal. Quantities, site requirements, support terms, and configuration can affect the final recommendation. A complete checklist helps your team compare the proposal against operational needs while keeping lifeguards and supervised response at the center.
Ask the team to demonstrate the complete path: a swimmer wearable or lifeguard tag initiates an event. The GUARDian Hub communicates it, and the designated staff receive the alert. Request a realistic scenario using your facility's staffing pattern, response zones, and supervision procedures.
For swimmer wearables, an adjustable delay timer begins when the device is submerged. If the preset threshold is reached, WAVE says lifeguards can receive notifications through vibrating bracelets, with spoken facility alerts available as part of the configured escalation path. Confirm the exact timing and channels proposed for your site. Learn about swimmer equipment.
Ask for a live lifeguard-entry demonstration. WAVE describes a submerged lifeguard tag triggering staff bracelets, while the hub provides audio and visual alerts. Your team should verify who receives each notification and how the event fits your existing rescue protocol. Review lifeguard alert equipment.
Ask who trains lifeguards, supervisors, and administrators; how new employees are onboarded; and how the facility checks device readiness. Confirm battery monitoring, software updates, replacement procedures, support coverage, and the responsibilities assigned to your staff before requesting a proposal.
Ask to see how authorized users manage equipment status, alert thresholds, permissions, and activity records. Request an example of incident analytics or historical reporting, then confirm what data is available, exportable, retained, and accessible for your facility's operational and documentation needs.
A focused demonstration can help your aquatics team connect alert initiation, staff response, management, deployment, and training to your facility's needs. Bring the people who will use and support the system so you can evaluate the workflow together.
Schedule a drowning detection system demo