The Panic Button RFP Guide: What to Require Before You Buy
By the time a panic alert system fails, the failure is usually years old: it was written into the RFP, or left out of it. Procurement documents decide whether a district or facility buys a working safety program or an expensive dispute, because vendors build to the requirements as written, and requirements that specify a brand, skip the statutory floor, ignore total cost, or omit acceptance testing get exactly what they asked for. This guide is the requirements list we would want to answer as a vendor, which is the most honest way to write one.
Rule One: Specify the Function, Not the Device
Strong RFPs describe what the system must do and let device classes compete on the merits. The functional core for silent alerting is consistent everywhere: activation must be silent at the point of use, immediate, and possible with one action; the alert must reach designated responders with the activation location; the system must work during the conditions emergencies create, which means no dependence on a single network that fails in a power event or a crowded incident; and the response must be programmable, so one press can drive the right sequence for the scenario. Requirements written around a specific product’s feature list read as pre-decided and exclude better answers; requirements written around function force every bidder to prove the outcome. The one place device class belongs in the document: require bidders to state plainly which positions their proposal protects with fixed hardware, which with carried devices, and why, because that mapping, not the brochure, is the design. Our fixed vs. wearable guide is the background for evaluating those answers.
Rule Two: Write the Statutory Floor Into the Document
If your state has a school panic alert law, its requirements are your minimum spec, and they vary meaningfully. New Jersey’s original Alyssa’s Law defined the template: silent, direct, manually activated alarms linked to law enforcement. Texas requires classroom-level coverage. Oklahoma requires integration with the 911 system and vendors meeting state criteria. Washington directs districts to design alert systems in collaboration with law enforcement and 911 authorities. Florida’s program centers on mobile panic alert connectivity. An RFP that quotes its own state’s language, and requires bidders to certify compliance with it item by item, prevents the worst procurement outcome: a system that works and is still non-compliant. Our state-by-state Alyssa’s Law guide maps every statute, and each state guide details the language worth quoting.
Rule Three: Demand Five-Year Total Cost, Itemized
The most consequential number in most panic system purchases never appears in the bid: the recurring cost. Per-user licensing, per-building platform fees, mandatory monitoring, support tiers, and renewal escalations can multiply a modest hardware price into the largest line in the safety budget, forever. Require every bidder to disclose total five-year cost, itemized, including every recurring fee at projected headcount, every cost that survives a cancellation, and, in one sentence, what stops working if payments stop. That last question separates owned systems, which keep functioning, from service-dependent platforms, whose protection has a billing status. Boards comparing a one-time owned purchase against a subscription should compare five-year totals, not year-one totals; published owned-system pricing is on our kits and pricing page as a reference point.
Rule Four: Acceptance Testing With Teeth, in a Written Contract
The most expensive documented panic system failure in public record is a procurement story. A major district bought a badge-based crisis alert system for 26 schools, found tracking that failed in multi-story buildings and devices dead by the dozen in testing, withheld payment, sued, and settled for a partial refund that still left it out more than $655,000 for a system it removed at its own initiative. Two contract lessons are sitting in that record. First, the district’s dispute was complicated by having bought through purchase orders rather than a single written contract, which muddied its remedies; require a written agreement. Second, define acceptance before installation: test activations from every mapped position including the building’s worst spots, response-time measurement, a device-failure threshold, and payment milestones tied to passing, with the final payment held until the system demonstrates the function the RFP specified. The full failure taxonomy is in why panic alert systems fail; the RFP is where every one of those modes gets prevented or purchased.
Rule Five: Require the Response, Not Just the Alarm
An alert that reaches a phone tree is not a response. Require bidders to describe, specifically, what happens in the sixty seconds after activation: who is notified, in what order, through what infrastructure, and what the system itself does, pages, announcements, displays, lockdown sequences, without a human relay. Systems that integrate with existing PA, bells, and displays turn the press into a building-wide response and reuse infrastructure the facility already owns; require bidders to inventory what they can reuse and price what they cannot. And require a training and drill plan as a deliverable, not a brochure promise, because the evidence is blunt: deployments fail on adoption and response far more often than on hardware.
Evaluating the Responses: Read for What Is Missing
When the proposals arrive, the tell is rarely in what a bidder wrote; it is in what a bidder skipped. A response that answers the five-year cost requirement with a year-one table is hiding the recurring line. A response that certifies statutory compliance in a single sentence instead of item by item has not read your statute. A response that describes response integration as a future roadmap is selling an alarm, not a system. And a response that resists acceptance testing tied to payment is telling you how confident it is that the system will pass. Score against the checklist mechanically, require clarifications in writing, and weight the mapping question, which positions get which device class and why, above every feature claim, because that answer is the only one that describes your building instead of the bidder’s product.
The Checklist, Compressed
A strong panic button RFP requires: silent, immediate, single-action activation with location; function under emergency conditions, stated network dependencies disclosed; the state statutory floor quoted and certified item by item; fixed-versus-carried mapping by position, justified; five-year total cost, itemized, with the what-stops-working-if-we-stop-paying answer; a written contract with defined acceptance tests, failure thresholds, and payment tied to passing; response integration with existing communication systems, inventoried and priced; and training plus a drill calendar as deliverables. Any bidder uncomfortable with that list is telling you something worth knowing before the purchase instead of after.
Frequently Asked Questions
Should our RFP specify fixed buttons or wearables?
Specify the function and the positions, then require bidders to map device classes to positions with justification. Fixed stations typically win fixed positions like classrooms, desks, and counters; carried devices exist for genuinely mobile roles. The mapping is the design decision, and it belongs in the bid where you can evaluate it.
What is the most commonly missed RFP requirement?
Total five-year cost including all recurring fees. Year-one pricing hides per-user subscriptions that grow with headcount and never end, and it hides the difference between owned hardware that keeps working and platforms whose protection expires with a missed renewal.
Can we require compliance with our state’s panic alert law?
You should quote the statute’s operative language in the RFP and require item-by-item certified compliance in every response. State requirements differ, from classroom-level coverage to 911 integration to law-enforcement collaboration, and certification puts the compliance burden where it belongs, on the bidder, in writing.
If you are drafting requirements now, start with the checklist above, and pressure-test it against a real proposal: request a quote, and you will get an itemized, owned-system answer built to be compared line by line.
