Starting the conversation: your safety landscape

• Tell me briefly about the communities and sites you are responsible for, including number of campuses, buildings, and typical daytime and evening populations.
• How often do you run formal emergency alerts or live-test exercises today? Options: Weekly, Monthly, Quarterly, Twice a year, Annually, Never
• On an average school day, how many people must be reachable within the first 60 seconds? Options: Under 500, 500 to 2,000, 2,001 to 10,000, 10,001 to 50,000, 50,000+
• Who currently gets notified first when an incident begins, and who owns that decision?
• Describe the tools you use right now to reach staff, students, and visitors, including any manual steps.
• Which of these channels are active in your daily operations? Options: SMS/text, Email, Voice calls, App push, Digital signage, Public address/PA, Social media, None of the above

Where seconds are lost: notification failures that matter

• When the last real emergency unfolded at your site, what was the single notification failure that most endangered people?
• Tell me the timeline from threat confirmation to first notification in that incident, including any manual handoffs.
• How many people did not receive any notification within the first five minutes during that event? Options: 0-10, 11-50, 51-200, 201-1,000, 1,001+
• If you trace back the technical steps, where did contact sync or channel routing break down?
• Which stakeholders reported confusion or delay during the event, and what did they report?
• If that failure had resulted in a serious outcome, would your district be required to open an investigation or face state review? Options: Yes, likely, No, Uncertain, Would require legal review

Who moves when an alarm goes off

• Who on your team is enabled to activate a mass alert without additional approvals during off-hours? Options: Campus safety director, Campus chief/commander, Assigned on-call staff, Principal/site lead, No one can today
• Walk me through the steps a junior staff member would take to issue an alert under pressure.
• Count the number of staff who are trained and confident to operate the alert system at any hour. Options: 0, 1-2, 3-5, 6-10, 10+
• List the internal and external roles that must be notified immediately, such as operations, transportation, or local law enforcement. Options: Facilities/operations, Transportation, Local law enforcement, Health services, Communications/PR, External partners
• In a staffing shortage, what would stop those notifications from going out within your target window?
• Should your primary on-call person be unavailable during an incident, is there a documented and tested fallback process that guarantees notification within your required time? Options: Yes, documented and tested, Yes, documented but not tested, No documented fallback, Partial fallback exists

Measuring success: the signals that matter

• What single measurable signal would convince you this system is working in a real emergency?
• Provide the top three metrics you would monitor during a live test, for example delivery within 60 seconds, percent reached on mobile, or time-to-confirmation. Options: Delivery within 60 seconds, Percent reached on mobile, Time-to-confirmation from sender, Activation accuracy by building, Staff activation time under stress
• On your target dashboard, how would you display coverage by role and by building?
• Would a successful pilot require both time-to-delivery thresholds and evidence staff can activate under stress, or is one of those sufficient? Options: Both required, Time-to-delivery only, Activation evidence only, Unsure
• Describe the acceptance criteria that would let your leadership sign a purchase order the week after a successful pilot.
• Assuming the pilot meets your time-to-delivery goal but fails to reach 10 percent of a high-risk population, would you proceed to procurement or pause for remediation? Options: Proceed to procurement, Pause for remediation, Escalate to leadership, Extend pilot

Past incidents and near-misses that still weigh on you

• In the last two years, which incident or near-miss changed how you think about alerting the most?
• Summarize the tangible consequences from that event, for example legal review, operational downtime, or injuries.
• When you reconstructed the timeline of that event, which handoffs or technical steps were unclear?
• List the vendor category or internal system that was relied on most heavily in that incident, and explain what failed. Options: SIS/Student information system, HR/employee directory, PA/audio system, SMS gateway, Custom internal tools, Other
• Rate your current confidence from 1 to 10 that the same failure could occur today. Options: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
• Would your current process pass or fail if a state regulator required proof that every person is reachable within your target window? Options: Pass, Fail, Conditional, with exceptions, Unsure

What alternatives are on the table for solving this

• Name the alternatives you are actively considering instead of a new multi-channel alerting platform, including internal builds. Options: Incumbent vendor, Internal build, Point solutions per channel, PA-only upgrade, Contract with local agency, Other
• For each alternative, what would have to be true about your current approach for you to stay with it?
• Have any internal teams proposed building or owning this capability themselves? Options: Yes, a team has proposed it, No one has proposed it, Under discussion
• Consider the incumbent solution in use today, what evidence would justify keeping it rather than switching?
• Identify the deal-breakers that would rule out a vendor quickly, for example inability to meet delivery times or lack of panic hardware support. Options: Fails delivery time targets, No panic hardware support, No API access, Cannot segment by building/role, Pricing above budget, Noncompliant with regs
• Under what circumstances would you stop pursuing an internal build and choose an external vendor instead?

Operational readiness and constraints we must clear

• Assuming we configured exactly what you requested, which system integrations or approvals could still block deployment?
• Select the integration endpoints that must be connected, choose all that apply. Options: Student information system (SIS), HR/employee directory, Public address/PA override, Digital signage, Access control/door systems, Mobile app SDK, LDAP/Active Directory, SMS gateway/carrier, Local 911/PSAP integration, Other
• For each integration, name the internal owner and indicate whether they can provide API credentials or system access within 4 weeks.
• Count the number of full time IT staff who will be available to support configuration and testing during the first month. Options: 0, 1-2, 3-5, 6-10, 10+
• Is your contact database centralized and owned by a single team, or distributed across multiple systems? Options: Centralized and owned, Distributed across multiple systems, Partially centralized, Unknown
• Identify compliance or legal approvals that could extend the timeline, for example state review or data sharing agreements.
• Suppose a critical integration cannot be completed, do you have an acceptable workaround that preserves your target notification time? Options: Yes, documented workaround, Yes, an ad hoc workaround, No acceptable workaround, Depends on which integration

Decision levers, timeline, and next steps

• Lay out the internal approvals you would need if the pilot proves the numbers, and typical durations for each.
• Select the budget source that would pay for this purchase. Options: Operational budget, Capital expenditure, Grant funding, Emergency preparedness budget, Unknown
• Provide the date or month of your next procurement window or board meeting where this could be approved.
• Explain the minimum outcome from the pilot that would let you sign within 30 days.
• Choose the rollout approach you prefer, phased by campus or a single cutover, and why. Options: Phased by campus, Single cutover, Hybrid phased then cutover
• Name the stakeholders who must attend a 30-minute briefing at pilot completion to remove the last obstacle to signing.
• Once the pilot results are approved, how quickly could you issue a purchase order? Options: Within 7 days, Within 30 days, Within 60 days, Depends on approvals, Unknown

• Live-Scenario Experience

• Confirm the current state and its cost to you
• You confirm the demonstrated workflows eliminate the manual activation gaps and reduce time-to-first-notify compared with your current process.
• Provide a prioritized list of 2–3 realistic emergency scenarios and a recent anonymized sample contact export for testing.
• You agree on measurable acceptance criteria for coverage percentage and target time-to-notify that will be used in the live test.
• Select 2 realistic emergency scenarios to run
• Run a tailored delivery timing test using the provided contact sample and deliver a channel-level timing and coverage report before the follow-up session.
• Run scenario 1 end-to-end, multi-channel activation
• Confirm acceptance criteria for coverage percentage and maximum time-to-notify to be used in the full-scale live test.
• You identify any remaining technical or operational gaps that must be closed before a decision.
• Run scenario 2 with panic hardware and two-way comms
• Schedule the full-scale live test window and identify the staff roles who will participate in the activation drill.
• Prove contact coverage and data mapping
• Show delivery timing under simulated network stress
• Validation checkpoint, confirm this matches what you need

• Live-Scenario Experience
• Live-Scenario Experience Deck
• Live-Scenario Experience Brief

• meeting
• slides
• document

• Provision platform accounts and admin access
• Import and normalize contact records
• Deploy contact database sync and reconciliation
• Configure multi-channel delivery (SMS, email, voice, push)
• Integrate PA system and digital signage override
• Install and configure panic button hardware
• Configure building-level segmentation and geofencing
• Set up two-way incident communication channels
• Define escalation paths and channel fallback rules
• Configure notification templates and prewritten messages
• Train staff on activation procedures and panic response
• Run live emergency test exercise measuring delivery metrics
• Configure delivery priority and congestion throttling
• Deploy real-time delivery monitoring dashboard

Provision platform accounts and admin access

• How many platform administrators and site-level operators do you need created for your district or campus? Options: 1-2, 3-5, 6-10, More than 10
• Which identity method will you use for sign-on for those accounts (directory services such as LDAP/Active Directory, SAML single sign-on, or platform-native credentials)? Options: LDAP / Active Directory, SAML single sign-on (SSO), Platform-native credentials, Other
• Who in your IT team will supply test accounts and API credentials for admin provisioning and how will they be delivered (secure file transfer, vault entry, ticket)?
• What network or firewall rules must we allow (IP allowlist, VPN tunnel, port ranges) so admins can access the admin console from your campuses?
• Do you require role-based access controls that separate district-level, building-level, and emergency operations center roles? Options: Yes, No, Partial - explain
• What password policy or multi-factor authentication (MFA) requirements must be enforced for admin accounts (minimum length, rotation, MFA methods)?

Import and normalize contact records

• How many contact records in total need to be imported from your student information system (SIS), human resources (HR) database, and third-party vendor lists? Options: Less than 5,000, 5,000-25,000, 25,000-100,000, More than 100,000
• Which source systems contain contact fields we must map (student information system (SIS), HR payroll, parent/guardian portal, vendor roster)? Options: SIS, HR/payroll, Parent/guardian portal, Vendor roster, Other
• Which specific contact fields must be present and validated for each record (mobile phone, carrier, SMS consent timestamp, email, building assignment, role such as teacher or student)?
• Do you have existing rules for deduplication and canonicalization (for example: prefer student mobile over parent, normalize international prefixes, merge by student ID)? Options: Yes - provide rules, No - need recommended rules
• What data privacy or compliance constraints apply to these records (Family Educational Rights and Privacy Act (FERPA), state student privacy law, HIPAA for health staff), and where must PII be masked or excluded? Options: FERPA, State student privacy law, HIPAA, None / Other
• What acceptance criteria will confirm the import is successful (for example: X% reachable mobile numbers, dedupe rate under Y%, field-mapping completeness)? Options: Reachability >= 95%, Dedupe rate <= 5%, All required fields mapped, Other

Deploy contact database sync and reconciliation

• How often should the contact database synchronize with each source system (real-time webhook, near-real-time every 5 minutes, hourly, nightly)? Options: Real-time/webhook, Every 5 minutes, Hourly, Nightly
• Which connector types do you require for sync (SIS database export, secure API from HR system, SFTP drop, directory sync for staff accounts)? Options: SIS API, HR API, SFTP/CSV, Directory sync (LDAP/AD), Other
• Who will supply API credentials, service accounts, or SFTP endpoints for each source and what is the expected lead time to obtain them?
• What reconciliation rules do you want for conflicting data (source priority, timestamp-based last-write wins, manual review queues by building admin)? Options: Source priority, Timestamp last-write wins, Manual review required
• Which exception workflows should be created for reconciliation failures (automated retry, email alert to roster owner, stop sync and create ticket)? Options: Retry then alert, Create ticket to roster owner, Stop sync and hold records
• What retention and archival policy should apply to historical contact snapshots for audit or compliance (retain 1 year, 3 years, indefinite)? Options: 1 year, 3 years, Indefinite, Other

Configure multi-channel delivery (SMS, email, voice, push)

• Which delivery channels do you require enabled at go-live for each audience (students: SMS and push; staff: SMS, email, voice), list by audience segment?
• What delivery speed objective do you require for initial outbound notifications (for example: 60 seconds for first wave to all reachable mobile devices)? Options: 30 seconds, 60 seconds, 120 seconds, Custom
• Which SMS opt-in and consent rules apply for your jurisdiction and how are opt-outs captured in your source contact records? Options: Consent recorded in SIS, Opt-out via portal, No opt-in required, Other
• What caller ID and voice message localization rules are required for automated calls to staff and parents (local number display, multilingual prompts)? Options: Local number display required, Multilingual prompts required, Standard caller ID ok
• How should priority be assigned across channels during an incident (push then SMS then voice, simultaneous across all channels, channel-specific for staff vs students)? Options: Simultaneous, Priority order - specify, Channel-specific
• Are there blackout windows or scheduled Do Not Disturb periods for non-critical messages that the delivery engine must respect (for example: after 10 PM campus local time)? Options: Yes - provide windows, No

Integrate PA system and digital signage override

• Which models or controllers power your public address (PA) system and digital signage (provide controller type or manufacturer model), and do they expose an integration endpoint?
• Do your PA and signage controllers support an API or accept simple network triggers (HTTP post, MQTT, serial), or will a hardware relay be required? Options: API / HTTP, MQTT, Serial / GPIO, Hardware relay required
• Who maintains the building wiring and AV access for each campus location and what lead time is required for on-site integration testing?
• Which buildings or zones need signage/PA override at go-live (list building IDs or campus zones), and are any of those on separate network segments?
• What fallback behavior should occur if digital signage or PA override fails during an alert (escalate to voice, send to on-site staff, trigger local alarm)? Options: Escalate to voice, Notify on-site staff, Trigger local alarm, Other
• Are there compliance or local code requirements for PA announcements (maximum duration, language, pre-announcement tone) that must be included in templates? Options: Yes - provide rules, No

Install and configure panic button hardware

• How many panic button units are required per building and what mounting locations do you prefer (office, classroom, receptionist desk, wall-mounted vs wearable)?
• Which panic hardware connectivity is available at your sites (Wi-Fi, PoE network, cellular), and do any buildings lack network connectivity? Options: Wi-Fi, Power over Ethernet (PoE), Cellular, No network
• Who will perform physical installation and on-site power/network testing, and do you need us to schedule installers or provide an installation playbook? Options: You will install, We schedule installers, Provide installation playbook
• What are the expected activation behaviors for each button type (single press send alert, held press for silent alarm, activate two-way voice) per building or role)? Options: Single press, Held press, Two-way voice, Custom
• Do you require tamper detection, battery health telemetry, or regular firmware update windows for panic devices? Options: Battery telemetry, Tamper detection, Firmware update schedule, None
• What inventory acceptance criteria apply at handoff (device count validated by serial number, test activation from each device)? Options: Serial number validation, Test activation from each device, Both

Configure building-level segmentation and geofencing

• Which building identifiers or campus zone names will you use for segmentation (building IDs, room numbers, GPS polygons), and provide a sample mapping file format?
• What geofence fidelity do you need for mobile push notifications (building-level polygon, campus quadrants, or GPS radius in meters)? Options: Building polygon, Campus quadrant, Radius (meters)
• How should people assigned to multiple buildings (roving staff, visiting vendors) be handled for targeted alerts? Options: Primary building only, Send to all assigned buildings, Use last-known GPS location
• Do you require schedule-based segmentation (class periods, shift schedules) that changes target audiences by time of day? Options: Yes - provide schedules, No
• What acceptable coverage threshold do you require for building-level targeting at go-live (for example: 95% of occupants correctly mapped to a building)? Options: 90%, 95%, 99%, Other
• Who will maintain the building-to-contact mapping after deployment, and do you want a role created for building roster owners? Options: We will maintain, You maintain, Create building roster owners

Set up two-way incident communication channels

• Which two-way channels do you want enabled for incident response (in-app chat, SMS reply routing, voice call-back to incident commander)? Options: In-app chat, SMS reply routing, Voice call-back, Email
• What routing rules should apply for replies from recipients (route to building admin, to incident command center, to local law enforcement liaison)? Options: Building admin, Incident command center, Local law enforcement liaison, Other
• Which staff roles need access to two-way conversations and should discussion transcripts be archived to the incident log? Options: All responders, Command staff only, Archive transcripts, Do not archive
• Do you require automated reply triage (keyword detection like 'injury', 'locked', 'safe') and escalation to on-duty security? Options: Yes - keyword list provided, No
• What maximum acceptable reply latency and delivery reliability do you require for two-way channels during an incident? Options: <5 seconds, <30 seconds, <2 minutes
• Who will be responsible for moderating two-way threads during exercises and actual incidents?

Define escalation paths and channel fallback rules

• Which incident types require escalation to which roles (medical emergency -> nurse and campus police; active shooter -> incident commander and district safety director), list by scenario?
• What channel fallback sequence should apply when a primary channel is undeliverable (for example SMS failure -> voice call -> push notification)? Options: SMS -> Voice -> Push, Push -> SMS -> Voice, Simultaneous across channels, Custom
• How many escalation levels should be defined before alerting external agencies or district leadership? Options: 1, 2, 3, Custom
• Do you require automatic escalation based on lack of acknowledgment from recipients within a timeframe (no ACK within 2 minutes escalates)? Options: Yes - specify timeout, No
• Which contact roles should never be bypassed in an escalation chain (for example: on-duty campus police, safety director)?
• Who will own the documented escalation playbook and how will changes be approved and distributed? Options: You own playbook, We help maintain, Joint ownership

Configure notification templates and prewritten messages

• Which incident templates do you require at minimum (Lockdown, Shelter-in-Place, Evacuate, All-Clear, Medical Emergency), and in what languages? Options: Lockdown, Shelter-in-Place, Evacuate, All-Clear, Medical Emergency
• What personalization tokens must be supported in templates (building name, room number, sender role, estimated time to resolution)?
• Do templates need to include pre-approved legal or regulatory language required by your district or state notification policy? Options: Yes - provide language, No
• Which channels require shortened variants of templates (SMS character limits, voice script vs text vs signage), and who will approve final wording? Options: SMS, Voice, Digital signage, All
• How many template approval levels are required before a template is made available to operators (draft -> legal -> safety director -> publish)? Options: 1, 2, 3, Custom
• Who will maintain multilingual translations and do you require translation management integrated into the template workflow? Options: We maintain, You maintain, Require translation workflow

• Subscription Agreement (Order Form)
• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Service Level Agreement (SLA)
• Data Processing Agreement (DPA)
• Hardware Purchase Agreement
• Integration & Data Access Appendix
• Training & Knowledge Transfer Addendum
• Public-Sector Procurement & Security Rider (applies if you are a public entity)

• Go-live Health Check (weeks 1-4)
• First Measurement Review (weeks 4-10)
• Acceptance Gate Review (around day 90)
• Quarterly Operational Review (ongoing)

• Confirm and publish the calendar of live-test exercises with assigned owners and test scopes.
• Run the agreed live-test, capture channel-level delivery logs, and upload evidence to the shared channel before the Acceptance Gate.
• Restate acceptance criteria and evidence requirements from Solution Scope
• Capture a documented acceptance decision against the Solution Scope targets, with pass/fail recorded per criterion.
• Confirm incumbent decommission approach and schedule data archival or retention as required.
• Define remediation tasks, owners, and verify dates for any failed criteria to close within the agreed remediation window.
• Publish the acceptance decision and attach the evidence bundle to the shared project record.
• If incumbent is being retired, publish the decommission schedule, data archival procedures, and the final fall-back cutover plan.
• Create a remediation tracker for any failed acceptance items with owners and fixed completion dates.
• Trended performance review
• Confirm the solution remains within the tolerances for percent reached within 60 seconds and live-test success rate, or document adjustments required.
• Clear or re-prioritize the open issues and enhancement backlog with owners and target completion quarters.
• Lock the next 12 months of live-test dates and owners and confirm the shared channel response SLAs.
• Publish the quarterly performance dashboard to the shared channel with annotated trends and any corrective actions.
• Update the enhancement backlog with agreed priorities and publish the next expected delivery quarter.
• Re-confirm success criteria and owners
• Confirm all deployment owners and the immediate remediation owner for each open issue.
• Validate integration endpoints are online and report any gaps requiring urgent fixes.
• Agree date range for the first measurement meeting and the next live-test exercise.
• Document all open deployment defects with clear owners and target resolution dates.
• Publish a go-live health snapshot to the shared channel and notify the operations list.
• Schedule the First Measurement Review within 4 to 10 weeks and record the live-test date.
• Present first measurement data versus targets recorded in the Solution Scope
• Determine whether percent of recipients reached within 60 seconds and contact database sync success rate are trending toward the Solution Scope targets.
• Assign root-cause remediation tasks with owners and dates to close any measured gaps before the Acceptance Gate.
• Confirm the next live-test scope and success criteria that will feed the Acceptance Gate evidence package.
• Produce a measurement report comparing each named metric to the Solution Scope targets and circulate to stakeholders.
• Execute targeted fixes for contact database sync failures and report a follow-up sync success metric by the agreed date.
• Present consolidated outcome data and live-test evidence
• Open issues and enhancement backlog
• Deployment and integration validation
• Root-cause diagnosis for any gaps
• Document pass or fail per acceptance criterion and capture decision
• Early adoption and activation signals
• Schedule and assign recurring live-test exercises
• Live-test and activation workflow recap
• Open defects and blockers
• Agree corrective actions and timeline to Acceptance Gate
• Shared channel health and escalation paths
• Incumbent system decommission status
• Schedule first measurement and live-test
• Agree remediation plan for any failed criteria
• Short Q&A and next operational actions