Unified Fire Authority Request for Proposal #RFP 2026-09

COUNTYWIDE EMERGENCY ALERTING AND

COMMUNITY MASS NOTIFICATION SYSTEM

INFORMATION & REQUIREMENTS

I. OVERVIEW

Salt Lake County contracts with Unified Fire Authority (UFA) to administer and support the County’s Emergency Management program on its behalf. Under this arrangement, UFA performs designated emergency management functions and provides the administrative, operational, and coordination support necessary to carry out the County’s emergency management responsibilities.

For purposes of this Request for Proposals (RFP), references to the “County” mean Salt Lake County, acting through UFA as its contracted Emergency Management administrator.

UFA will administer this procurement and serve as the primary point of contact for solicitation activities, vendor communications, contract administration, implementation coordination, and ongoing contractor oversight. The selected Contractor shall work directly with UFA to meet the County’s emergency alerting requirements and coordinate with participating jurisdictions, public safety agencies, and authorized partner organizations, as applicable. This administrative arrangement does not alter the respective legal status or authorities of Salt Lake County, UFA, or participating jurisdictions.

II. OBJECTIVE

Unified Fire Authority invites qualified vendors to submit proposals to provide, implement, host, maintain, and support a secure, reliable, and scalable countywide emergency alerting and community mass notification system. The system shall support Salt Lake County and participating municipalities, public safety agencies, special service districts, and other eligible public entities that elect to participate under the resulting contract.

The UFA seeks a common platform to deliver geographically targeted public warnings, emergency notifications, and protective-action instructions in a timely manner. Required capabilities shall include authorized integration with the Federal Emergency Management Agency’s (FEMA) Integrated Public Alert and Warning System (IPAWS), opt-in community notifications, two-way communications, multichannel message delivery, multilingual capabilities, geographic targeting, alert-status tracking, and coordinated administration across participating jurisdictions. The platform shall support urgent emergency notifications and approved non-emergency public information while providing appropriate access controls, operational safeguards, and accountability for authorized users.

The resulting contract is intended to establish a coordinated, scalable alerting capability that supports participating jurisdictions while allowing for jurisdiction-specific operational needs, authorization requirements, and implementation schedules.

UFA will serve as the lead contracting and coordinating entity. Participating jurisdictions may include County departments, municipalities, public safety agencies, special service districts, and other public entities approved by the County. The UFA does not guarantee a minimum number of participating entities, users, contacts, messages, or revenue. The proposal must specify how the platform and pricing scale as participants join or leave.

The awarded contractor shall contract with the UFA under the master agreement.

Participation by another public entity will be subject to UFA approval and an applicable participation agreement, order form, or other written instrument approved by UFA Procurement and Legal Counsel. The Contractor shall not assume that a jurisdiction is enrolled, authorized to originate IPAWS alerts, or financially obligated until the applicable written approval is complete.

III. CRITERIA FOR EVALUATION

Awards of orders will be on the basis of:

Evaluation category Points Evaluation focus

System capabilities and functional fit

30%

IPAWS/FEMA-aligned workflow; geofencing; opt-in registration; multichannel delivery; two-way communication; multilingual/accessibility; status tracking; templates, preplans, activation request;

exercise environment; reports.

Pricing and total cost of ownership 25%

Clear line-item pricing; five-year cost; renewal pricing;

transparent usage rates; included services; cost predictability; disclosure of all fees and escalation.

Fiscal approach and multi-jurisdiction cost model 25%

Fair and auditable allocation; staggered onboarding and proration; consolidated and jurisdiction-level reporting;

avoidance of duplicate costs; flexibility as participants join or leave.

Implementation, onboarding, training, and support

20% Feasible transition plan; data migration; onboarding cohorts; 24/7 critical support; training; exercises;

service levels and continuity.

TOTAL 100

IV. QUALIFICATION OF OFFERORS

Offerors will not be considered unless they meet the following requirements:

All work as defined in the proposal content must be completed without the need for additional requests for proposals or bids.

V. PROPOSAL SUBMISSION

Sign and return the Proposal Response Cover Sheet (ATTACHMENT 1). The form must be signed by a company representative authorized to bind the Offeror contractually.

Submit all required information as outlined in the Proposal Content and Evaluation Criteria section of ATTACHMENT 1.

UFA allows for quotations to be submitted electronically. Electronic quotations should be submitted through a secure mailbox at Bonfire (U3P) https://utah.bonfirehub.com/portal/?tab=openOpportunities until the date and time as indicated in this document. It is the sole responsibility of the supplier to ensure their quotation reaches Bonfire before the closing date and time. There is no cost to the supplier to submit Unified Fire Authority electronic quotations via Bonfire. Here is a link to the Division of Purchasing’s website where it provides training materials for vendors on the Bonfire platform – https://share.vidyard.com/watch/nRJyoedyaNwRaWv43chZje Electronic quotations may require the uploading of electronic attachments.

The submission of attachments containing embedded documents is prohibited.

Submission Deadline: Thursday, December 3, 2026 10:00 AM (MST)

Proposals received after the deadline will not be considered.

Proposals will then be sent to UFA appointed Selection Committee for evaluation.

VI. ACCEPTANCE

A. Any proposal received will be considered an offer, which may be accepted by UFA based upon initial submission without discussions or negotiations.

B. By submitting a proposal in response to this Request, Offeror agrees that any proposal it submits may be accepted by UFA at any time within ninety (90) days from the date of submission deadline.

C. UFA reserves the right to reject any or all proposals and to waive minor technicalities and irregularities in proposals received, and/or to accept any portion of the offer if deemed in the best interest of UFA. Failure of Offeror to provide, in its proposal, any information requested in the RFP may result in rejection for non-responsiveness.

https://utah.bonfirehub.com/portal/?tab=openOpportunities https://share.vidyard.com/watch/nRJyoedyaNwRaWv43chZje

D. The UFA may accept all or part of any offer and may make multiple awards.

Offerors shall identify volume discounts if any or all products are selected.

VII. ADDITIONAL INFORMATION

For additional information concerning the services specified in this Request for Proposal, interested parties may contact Erica Langenfass via email at elangenfass@unifiedfireut.gov. Correspondence between suggested Offerors and UFA must be in written format.

For information concerning Request for Proposal procedures and regulations (i.e., submission deadline, forms required, etc.), or Americans with Disabilities (ADA) accommodations, interested parties may contact Erica Langenfass, Purchasing Agent, via e-mail at elangenfass@unifiedfireut.gov or Telecommunications Relay Services (TRS) at 711.

mailto:elangenfass@unifiedfireut.gov

ATTACHMENT 1

Proposal Response Cover Sheet

Countywide Emergency Alerting and Community Mass Notification System

TO: Unified Fire Authority

COUNTYWIDE EMERGENCY ALERTING AND COMMUNITY MASS NOTIFICATION SYSTEM

3380 South 900 West Salt Lake City, Utah 84119

The undersigned, having carefully read and considered the Request for Proposal to provide a COUNTYWIDE EMERGENCY ALERTING AND COMMUNITY MASS NOTIFICATION SYSTEM, does hereby offer to perform such Plan on behalf of UFA, in the manner described and subject to the terms and conditions set forth in the attached proposal.

OFFEROR

Company Name: _________________________________________________________________

Doing business as: [ ] an individual [ ] a partnership [ ] a corporation (mark appropriate box), duly organized under the laws of the State of _____________________________________.

BY: ______________________________________ ____________________________________

(Signature of authorized representative) (Please Print or Type Name)

PRINCIPAL OFFICE ADDRESS:

Street Address _____________________________________________________________________

City ________________________________________________ County ______________________

State ________________________________________________ Zip Code____________________

Telephone ( ) Fax ( ) _

Mailing Address ____________________________________________________________________

E-mail Address ____________________________________________________________________

TAXPAYER IDENTIFICATION NUMBER:

(Attach IRS Form W-9 “Request for TIN and Certification”)

Employer I.D. No. ______________________ OR Social Security No. _____________________

(Corporation or Partnership) (Individual)

ALL PROPOSALS MUST INCLUDE THIS COVER SHEET & THE PROPOSAL

CONTENT & EVALUATION REQUIREMENTS LISTED ON NEXT PAGE

PROPOSAL CONTENT & EVALUATION CRITERIA

EXHIBIT A – SCOPE OF WORK

COUNTYWIDE EMERGENCY ALERTING AND COMMUNITY MASS

NOTIFICATION SYSTEM

PROPOSALS SUBMITTED FOR EVALUATION MUST INCLUDE, AT A MINIMUM, THE

FOLLOWING INFORMATION AND MATERIALS:

A. GENERAL

The Offeror shall provide a countywide emergency alerting and community mass notification system. The will:

• Provide a dependable, easy-to-use public alerting platform for authorized County and participating-jurisdiction users.

• Support IPAWS alert origination and testing in accordance with FEMA requirements, applicable authorization, and the alerting authority’s approved procedures.

• Enable jurisdictions to maintain local operational control and data separation while participating in a coordinated countywide system.

• Improve reach through multiple delivery channels, resident self-registration, opt-in subscriptions, geospatial targeting, and accessible multilingual communications.

• Provide measurable delivery, response, and audit records to support incident documentation, after-action review, and continuous improvement.

• Use a transparent fiscal model with clear line-item pricing, predictable recurring costs, and an equitable method for allocating shared costs among participating entities.

• Allow staggered jurisdiction onboarding to avoid premature termination of existing systems, duplicate payments, or gaps in public alerting coverage.

B. QUALIFICATIONS

Proposals shall be organized in the following order. Offerors must answer every item and identify any exception, limitation, dependency, or additional cost.

1. Executive summary and statement of interest.

2. Company profile, ownership, years in business, organizational structure, staffing, and any material litigation or service interruptions relevant to performance.

3. Description of the proposed platform, hosting model, modules, licensing basis, and included versus optional capabilities.

4. Completed requirement-by-requirement compliance matrix for all items in Section 3.

5. IPAWS capability and FEMA alignment response, including software approval/certification status, test capability, originator authorization prerequisites, and implementation responsibilities.

6. Architecture, security, privacy, availability, disaster recovery, data ownership, retention, and data portability documentation.

7. Multi-jurisdiction administration, permissions, tenant separation, and governance models.

8. Public registration, opt-in consent, multilingual messaging, accessibility, two-way response, geofencing, and reporting examples.

9. Implementation and staggered jurisdiction transition plan, including sample cohort schedule and assumptions.

10. Training, drill/exercise, onboarding, ongoing support, escalation, and service-level commitments.

11. At least three comparable public-sector implementations, including customer, scope, dates, contact name, telephone, email, and relevance to this project.

12. Key project personnel and subcontractors, qualifications, assigned roles, and availability.

13. At least three references using the proposed platform for emergency public alerting or mass notification.

14. Completed separate cost proposal and fiscal approach response under Section 7.

15. Signed offeror certification and acknowledgment of all addenda.

C. REQUIRED PLATFORM

The Contractor shall provide a hosted, browser-accessible emergency alerting platform and all associated licensing, configuration, implementation, data migration, integration, training, documentation, maintenance, upgrades, technical support, and offboarding assistance.

Authorized users must be able to access the system through supported desktop and mobile browsers and, where available, a mobile application.

The County’s preferred deployment model is a vendor-hosted, cloud-based solution that minimizes the need for County-managed production infrastructure. Proposers shall identify and describe all available hosting and deployment options, including vendor-hosted cloud, County-hosted, and hybrid configurations, if offered. For each option, the Proposer shall document the system architecture, infrastructure requirements, security responsibilities, disaster recovery capabilities, staffing and maintenance requirements, ongoing support obligations, and any differences in functionality, performance, availability, scalability, or service levels. All implementation, licensing, recurring, and other associated costs shall be separately itemized by deployment model to support a clear comparison of total cost of ownership.

The UFA reserves the right to select the deployment model that best meets its operational, security, financial, and emergency management requirements. Any County-hosted or hybrid production infrastructure requires the County’s prior written approval.

D. COUNTYWIDE AND MULTI-JURISDICTION ADMINISTRATION

• Support a hierarchy that can include County-level administrators, participating jurisdiction administrators, agencies, departments, divisions, operational groups, and authorized alert originators.

• Allow the UFA to establish systemwide policies while permitting participating jurisdictions to manage their own authorized users, contact data, subscriptions, templates, and local notifications within delegated permissions.

• Enforce logical separation of jurisdictional data and administrative functions. A user in one jurisdiction must not access another jurisdiction’s restricted records unless expressly authorized.

• Support role-based access control, configurable privileges, multiple administrators, approval workflows, and delegation of authority.

• Support named individual accounts, multifactor authentication (MFA) for privileged users, account deactivation, and an auditable record of administrative actions.

• Describe any license, administrator, jurisdiction, concurrent-user, contact-volume, or message-volume limits.

E. IPAWS INTEGRATION AND FEMA ALIGNMENT – MANDATORY

The proposed system must support authorized alert origination through FEMA’s Integrated Public Alert and Warning System (IPAWS), including the IPAWS-OPEN interface and Common Alerting Protocol (CAP) workflows applicable to the offered service. The contractor shall describe the precise IPAWS functionality, including the FEMA approval or certification status applicable to the software, the role of any subcontractor or third-party provider, and the prerequisites that remain the responsibility of the UFA or each participating alerting authority.

• Support creation, validation, transmission, and status review of IPAWS alerts using the applicable FEMA-approved interface and required message fields, geographic targeting, alert types, and distribution options supported by the platform.

• Support test workflows using the IPAWS Test and Development environment where available and authorized. The contractor shall clearly distinguish test messages from live public alerts and provide safeguards against accidental public release.

• Support applicable IPAWS dissemination pathways available to the authorized alert originator, including Wireless Emergency Alerts (WEA), the Emergency Alert System (EAS), and other IPAWS-connected channels where supported and authorized. Clearly identify channels not included or not controlled by the vendor.

• Support CAP-compliant message creation and validation, required fields, geographic polygons or supported geocodes, message updates and cancellations, expiration, and appropriate alert identifiers/references.

• Provide a clear workflow for originator authentication, authorization, review/approval, transmission, error handling, and audit retention.

• Provide implementation guidance, technical documentation, training, and ongoing support for IPAWS configuration, testing, and operational use.

• Explain how each jurisdiction’s IPAWS permissions, credentials, and operational authority are established and maintained. Do not represent that purchasing the platform automatically grants a jurisdiction authority to originate IPAWS alerts.

• Disclose any FEMA approval, Memorandum of Agreement, software approval, credentialing, or training requirements relevant to the offered IPAWS functionality, and identify who is responsible for each prerequisite.

• The provider shall be responsible for updating and maintaining the County‘s IPAWS Collaborative Operating Group (COG) configuration within the alerting platform upon the County’s biennial COG renewal, ensuring continued compliance with FEMA IPAWS requirements and standards.

UFA retains responsibility for alert decisions, message content, legal authority, and approval of protective-action instructions for IPAWS messaging.

F. OPT-IN COMMUNITY ALERTING AND PUBLIC REGISTRATION

• Provide a public-facing, mobile-responsive registration webpage and/or portal that allows residents and other eligible subscribers to opt in to alerts and manage their preferences without requiring staff assistance.

• Allow subscribers to register, verify contact information where supported, update contact details, select preferred delivery methods and languages, subscribe to relevant jurisdictions or geographic areas, and opt out in accordance with applicable law and platform procedures.

• Support subscriptions by location, topic, alert category, jurisdiction, or other configurable criteria, while allowing the UFA to define which options are offered to the public.

• Support bulk import of existing opt-in subscriber records and self-registration. Explain import formats, deduplication, validation, consent records, and treatment of invalid or conflicting data.

• Provide configurable public-facing instructions, frequently asked questions (FAQ), how-to guidance, privacy notices, subscription terms, and accessibility information.

• Clearly disclose any fees to residents, mobile-app costs, advertising, data monetization, or use of third-party services. The UFA prefers no fee to residents for subscribing to or receiving alerts.

• Provide a method to export subscriber and consent records in a standard, machine-readable format for County-controlled retention and transition.

G. MULTI-CHANNEL NOTIFICATION DELIVERY

The platform shall support sending a single alert or coordinated message through multiple delivery channels, as selected by the authorized sender and available for the recipient. Offerors must identify included channels, third-party dependencies, message limits, per-channel charges, and any recipient device or carrier limitations.

• SMS/text messaging to mobile phones.

• Automated voice calls to mobile, landline, and supported VoIP numbers, including text-to-speech and recorded audio where available.

• Email.

• Mobile applications push notifications, if offered.

• Web-based public alert pages or embeddable alert feeds.

• Social media publishing or integrations, where supported and authorized.

• Desktop or internal notification channels only if included in the proposed service; identify them separately from public alerting.

• IPAWS pathways as described.

Offerors shall describe message throughput and expected delivery performance by channel, including calls/messages per minute or hour where applicable, queuing and throttling controls, prioritization during high-volume events, carrier or provider dependencies, and how delivery capacity is protected during regional or national incidents. The platform must allow an authorized administrator to cancel or terminate an in-progress message when technically feasible.

H. TWO-WAY COMMUNICATION AND RECIPIENT RESPONSE

• Allow recipients to respond to messages by text, web form, mobile application, or interactive voice response (IVR), as supported by the channel.

• Support configurable response prompts, polls, acknowledgments, and questions such as “Are you safe?”, “Do you need assistance?”, or “Can you report to this location?”

• Display responses in near real time and associate them with the relevant alert, recipient, timestamp, and delivery channel, subject to privacy controls.

• Support response summaries and exportable reports for incident documentation and after-action review.

• Allow the sender to distinguish delivery confirmation, message opened/read where supported, recipient acknowledgment, and an actual response. Do not treat these as equivalent statuses.

• Describe reply handling, inbound message costs, response limits, privacy controls, and retention settings.

I. GEOFENCING AND TARGETED MESSAGING

• Provide map-based targeting using a geographic information system (GIS) interface.

• Allow authorized users to draw or upload a polygon, select a radius or area, select saved geographic zones, or target a defined jurisdiction or subscription group.

• Support targeted messaging using available address, geocoding, subscriber location, or geographic data. Explain data sources, accuracy limits, update frequency, and any licensing fees.

• Support saved zones and preconfigured geographic areas such as jurisdictions, evacuation areas, warning areas, facilities, or other County-defined geographies.

• Display an estimated target area and audience before sending, with safeguards to help users detect accidental over-targeting or under-targeting.

• Explain how targeting works for IPAWS versus opt-in SMS, voice, email, and app notifications; identify differences between device-based location targeting and contact-address targeting.

• Allow the user to preview the selected geography and message audience before activation and preserve the selected geometry and audience criteria in the audit record.

J. MULTILINGUAL AND ACCESSIBLE COMMUNICATIONS

• Support composing and distributing messages in multiple languages, including the ability to send the same alert in multiple languages and/or select recipients by language preference.

• List every supported language and identify which functions are available for each language, including translation, text-to-speech, recorded voice, IVR prompts, subscription pages, and help content.

• Identify whether translations are human, machine-generated, or vendor-reviewed. Describe quality assurance and the process for UFA to review high-consequence protective-action language.

• Allow UFA-approved translated message templates to be stored, versioned, and reused.

• Support accessible public webpages and digital content consistent with applicable law and recognized accessibility standards, including WCAG 2.1 Level AA or a more current applicable standard required by the UFA.

• Support screen readers, keyboard navigation, mobile-responsive layouts, readable contrast, and accessible form controls. Provide an accessibility conformance report or equivalent documentation.

Automated translation must not be represented as a substitute for participating agencies' approval of emergency instructions. Participating jurisdictions retain authority over the final language and protective-action guidance.

K. ALERT STATUS, DELIVERY TRACKING, AND REPORTING

• Provide a live or near-real-time dashboard showing alert status by channel and, where available, recipient or destination.

• Define status terms, including queued, attempted, sent, delivered, failed, expired, canceled, acknowledged, and responded. Explain which statuses are supported by each channel and the evidence used to assign them.

• Identify invalid numbers, bounced emails, failed messages, carrier rejections, and other detectable delivery failures; support retry or resend where appropriate.

• Provide reports on alert creation, approval, sender identity, message content, targeting, selected channels, transmission times, delivery outcomes, response results, updates, cancellations, and system errors.

• Allow reports to be filtered by jurisdiction, incident, alert, date/time, channel, geography, or status and exported in common machine-readable formats.

• Maintain an audit trail of user activity and configuration changes, including who did what and when, in accordance with the County-approved retention schedule.

L. DATA IMPORT, SYNCHRONIZATION, AND MANAGEMENT

• Support initial import of contact lists, opt-in subscriber records, jurisdictional boundaries, saved geographic zones, templates, and other agreed data.

• Accept common structured formats such as CSV and Excel and provide documented APIs or other secure integration options where available.

• Support validation, duplicate detection, field mapping, error reporting, and reconciliation before data is activated.

• Provide a self-service mechanism for public registration and preference updates.

• Explain options for scheduled or automated synchronization with UFA or jurisdictional systems, including APIs, SFTP, or other supported secure methods.

• Maintain data ownership with the UFA or originating participating entity, subject to applicable law and participation agreements.

• Provide full data export and reasonable transition assistance at termination, including subscriber records, consent/preferences, templates, GIS/geofence configurations, logs, reports, and administrative records in a documented format.

• Provide comprehensive API documentation and representative code examples demonstrating the platform’s ability to integrate with external applications, databases, and systems.

Examples using Python programming language are preferred.

M. TRAINING, DRILLS, EXERCISES, AND PRACTICE ENVIRONMENT

• Provide a training environment separated from production, with safeguards preventing test messages from reaching the public or live IPAWS distribution pathways.

• Support drills, exercises, tabletop scenarios, functional tests, and practice alert activation using synthetic or approved test data.

• Allow the UFA to configure exercise scenarios, message templates, roles, recipients, and evaluation criteria without inadvertently launching live alerts.

• Provide initial role-based training for UFA administrators, jurisdiction administrators, alert originators, reviewers/approvers, and report users.

• Provide refresher training, new-user onboarding, training for software updates, and train-the-trainer materials throughout the contract term.

• Provide attendance records, training materials, job aids, recorded sessions where available, and a proposed annual training plan.

• Describe any fees for training, travel, exercise support, additional sessions, or use of a sandbox environment.

N. PREPLANS, MESSAGE TEMPLATES, AND ACTIVATION REQUEST WORKFLOW

• Provide configurable preplan templates for common hazards and incidents, including but not limited to severe weather, wildfire, flooding, hazardous materials incidents, evacuation, shelter-in-place, road closures, public health emergencies, infrastructure disruption, and all-clear messages.

• Allow the UFA to develop, approve, version, store, and distribute pre-scripted messages with protective actions, geographic selection guidance, translation fields, expiration times, and channel-specific formatting.

• Provide an electronic alert activation request form that authorized staff or partner agencies can submit to request an alert. The form should capture the requesting entity, incident details, hazard, urgency, proposed geography, protective action, target audience, languages, requested channels, proposed message, approval authority, and supporting attachments.

• Support configurable review, approval, escalation, return-for-correction, and audit workflows. The workflow must distinguish a request for an alert from authority to issue or transmit an alert.

• Allow authorized users to convert an approved request into an alert without re-entering all information, where feasible.

• Provide a public or internal knowledge webpage with system instructions, how-to articles, frequently asked questions, role-specific job aids, and contact paths for technical or operational assistance.

• Explain how templates and preplans can be exported, version-controlled, and maintained during contract transition.

O. SYSTEM ARCHITECTURE, DIALING INFRASTRUCTURE, RELIABILITY, AND SECURITY

• Describe the hosting model, system architecture, primary and redundant hosting locations, data storage locations, network design, dependencies, subcontractors, and any material third-party services.

• Describe high availability, geographically separate redundancy, automated failover, disaster recovery, backup frequency, recovery time objective (RTO), recovery point objective (RPO), and continuity arrangements.

• Provide historical uptime data for the most recent three years, including material outages, duration, cause, effect on alerting, corrective action, and whether any customer was unable to send alerts.

• Propose a minimum service availability target of 99.9% per calendar month, excluding only those exclusions expressly approved in the final contract. Identify service credits or other remedies for failure to meet the agreed service level.

• Describe outbound voice infrastructure, SMS/email delivery providers, carrier relationships, service-level agreements, calling capacity, throttling, caller ID options, and protections against congestion.

• Encrypt sensitive data in transit and at rest; describe key management, vulnerability management, security testing, patching, logging, incident response, backup protection, and breach notification timelines.

• Support MFA for privileged accounts and modern single sign-on (SSO) using SAML 2.0, OAuth 2.0/OIDC, or equivalent standards where supported by the County.

• Provide role-based access controls, least-privilege permissions, account lifecycle controls, and audit logging.

• Identify available independent security attestations or certifications, such as SOC 2 Type II or equivalent, and provide a current security overview under appropriate confidentiality controls.

• Disclose known material security incidents affecting the offered platform during the previous three years and summarize remediation, subject to applicable law and contractual confidentiality requirements.

• Describe data retention, deletion, data residency, backup retention, subcontractor access, and procedures for secure return or destruction of all data at contract end.

P. INTEGRATION AND INTEROPERABILITY

• The proposed platform must support integrated Reverse 911 (emergency telephone notification) capabilities, allowing g authorized 911 dispatch centers to initiate, manage, and distribute geographically targeted emergency notifications using the same platform as the County public alerting system.

• Provide documented APIs, supported data formats, authentication methods, rate limits, and integration fees.

• Describe integrations with GIS, 911/public safety systems, web content management systems, public alert feeds, social media, and other relevant systems.

• Identify any current integrations used by public-sector customers in Utah or comparable jurisdictions, without implying those integrations are included unless they are included in the price proposal.

• Support export and reuse of message content, recipient data, alert history, templates, and geospatial configurations to reduce vendor lock-in.

Identify all integration work that requires IT resources, external licenses, third-party procurement, or custom development.

Q. VENDOR-SUPPORTED ONBOARDING, TRAINING, AND TECHNICAL SUPPORT

• Assign a project manager and technical lead for implementation and a named account/support contact for ongoing service.

• Provide an onboarding plan covering kickoff, requirements validation, participant enrollment, configuration, data migration, user provisioning, testing, training, launch readiness, and transition to operations.

• Provide initial and ongoing training to all authorized users, including personnel from additional agencies that join the platform throughout the contract period. Training shall also be provided for newly added users within participating agencies.

• Provide 24/7/365 access to technical support for critical incidents affecting emergency alerting. State the channels for support, severity definitions, acknowledgment targets, escalation path, and target restoration times.

• Describe support staffing locations, holiday coverage, language availability, escalation to engineering, and whether support personnel can assist authorized administrators during a critical system incident.

• Provide service notices for planned maintenance, unplanned outages, material changes, and security events.

• Include routine software updates, maintenance, and security patches in the recurring license fee unless separately identified in the price proposal.

R. VENDOR-SUPPORTED ONBOARDING, TRAINING, AND TECHNICAL SUPPORT

• Assign a project manager and technical lead for implementation and a named account/support contact for ongoing service.

• Provide an onboarding plan covering kickoff, requirements validation, participant enrollment, configuration, data migration, user provisioning, testing, training, launch readiness, and transition to operations.

• Provide initial and ongoing training to all authorized users, including personnel from additional agencies that join the platform throughout the contract period. Training shall also be provided for newly added users within participating agencies.

• Provide 24/7/365 access to technical support for critical incidents affecting emergency alerting. State the channels for support, severity definitions, acknowledgment targets, escalation path, and target restoration times.

• Describe support staffing locations, holiday coverage, language availability, escalation to engineering, and whether support personnel can assist authorized administrators during a critical system incident.

• Provide service notices for planned maintenance, unplanned outages, material changes, and security events.

• Include routine software updates, maintenance, and security patches in the recurring license fee unless separately identified in the price proposal.

S. STAGGERED JURISDICTION ENROLLMENT AND CONTRACT TRANSITION

1. Contract Term

The anticipated master contract term is Five (5) years from the effective date, with up to two (2) one-year renewal options at UFA’s discretion, subject to funding, satisfactory performance, and applicable approvals.

2. Staggered Onboarding

The UFA intends to establish a countywide platform while allowing participating jurisdictions to transition from existing alerting contracts at different times. The contractor shall support staggered enrollment and activation dates rather than requiring all jurisdictions to migrate simultaneously.

The master contract shall establish the governing terms and baseline pricing. Each participating jurisdiction’s activation date, configuration, service tier, applicable costs, and billing start date shall be documented in an approved participation instrument or order form.

• Recurring charges for a jurisdiction shall begin on its agreed production date, not merely on the master contract effective date.

• The contractor shall provide a transition schedule showing each cohort, prerequisites, data migration, configuration, training, testing, cutover, and legacy-system end date.

• The contractor shall support parallel testing and, where necessary, a limited period of dual operation to protect continuity. Any dual-running fees must be separately itemized and approved in advance.

• The contractor shall not require a jurisdiction to terminate an existing contract early or incur a penalty. The vendor shall accommodate enrollment when the jurisdiction is contractually able to transition.

• The contractor shall avoid duplicate recurring charges for the same jurisdiction and period unless the UFA has expressly approved the cost and identified the operational need.

• The UFA may add eligible participants during the master contract term at the agreed pricing schedule, subject to scope, capacity, and written approval.

• At the end of the master contract, the contractor shall provide transition assistance regardless of staggered onboarding dates. The contractor shall not impose an undisclosed fee or withhold data to impede transition.

3. Required Transition Plan

Offerors shall submit a transition plan with a sample cohort schedule and identify how the system will maintain service continuity during enrollment. The plan must explain how existing contact lists, opt-in records, geofences, templates, administrative roles, alert history where exportable, and jurisdiction-specific configurations will be migrated. The contractor shall identify assumptions and any costs for overlapping licenses, data conversion, custom integration, or additional training.

Required transition milestone Offeror response / commitment Kickoff and stakeholder confirmation [Offeror to complete] Jurisdiction inventory and readiness review [Offeror to complete]

Data extraction, mapping, and validation [Offeror to complete]

Configuration and administrator provisioning [Offeror to complete]

Test environment and scenario validation [Offeror to complete]

Training and readiness sign-off [Offeror to complete] Production activation/cutover [Offeror to complete] Legacy contract end/overlap period [Offeror to complete] Post-launch monitoring and acceptance [Offeror to complete]

4. Implementation Deliverables and Acceptance Deliverable Minimum contents

Project management plan Roles, schedule, dependencies, risk register, communication plan, escalation path, and decision log.

Solution design Architecture, role model, jurisdiction separation, workflows, data model, integrations, and security configuration.

Data migration plan and results

Source inventory, mapping, validation, exception report, reconciliation, and acceptance record. Examples demonstrating API program capabilities to integrate with external applications, databases, and systems.

IPAWS implementation package

Prerequisites, role/authority mapping, configuration, test plan, training plan, and documented test results.

Public registration and help content

Registration page, subscription options, privacy/consent language, FAQ, how-to guidance, and accessibility review.

Templates and activation workflow

Approved template library, preplans, electronic request form, review/approval workflow, and test results.

Training package Role-based sessions, job aids, recordings where available, exercise environment, and attendance records.

Operational readiness report

Functional test results, open issues, mitigation plan, support contacts, and go-live recommendation.

Operations and continuity documentation

Support process, SLA, incident response, backup/recovery, maintenance, data export, and offboarding instructions.

Acceptance criteria and payment milestones shall be established in the final contract. The UFA may require remediation and retesting of material defects before accepting a deliverable or authorizing production activation. Production activation shall not occur until the County’s designated project lead approves readiness in writing.

5. Demonstrations and Scenario-Based Evaluation

The UFA may invite shortlisted offerors to demonstrate the proposed production-equivalent platform. Demonstrations may be scored and may include the following scenarios:

• Create a geospatially targeted evacuation or shelter-in-place alert, preview the audience, select channels, obtain required approval, send a test message, and display status results.

• Demonstrate the IPAWS workflow, required fields, validation, test environment, safeguards against unintended live release, and handling of an update or cancellation. Any live IPAWS transmission is prohibited during a demonstration.

• Show a resident registering, choosing language and alert preferences, updating information, and opting out.

• Send a multilingual alert and demonstrate how translations are reviewed, selected, and delivered by channel.

• Demonstrate two-way response collection, real-time response reporting, failed-delivery identification, and report export.

• Submit an electronic activation request, route it through approval, convert it to an alert, and preserve the audit trail.

• Demonstrate the exercise/training environment and show how the vendor prevents training messages from reaching the public.

• Demonstrate how two participating jurisdictions are separated administratively while UFA administrators retain approved oversight.

The UFA may request that offerors use standardized test data and may ask follow-up questions.

Offerors shall not use actual resident contact data or send public notifications during a demonstration without written UFA authorization.

6. Cost Proposal and Fiscal Approach

6.1 Separate Cost File — Mandatory

The cost proposal must be submitted as a separate file from the technical proposal. All pricing must be stated in U.S. dollars and must be clear, complete, auditable, and easy to compare across offerors. Bundled or ambiguous pricing without a supporting line-item breakdown may reduce the proposal score or result in a finding of non-responsiveness.

Offerors shall provide a completed price schedule for the full five-year base term and each optional renewal year. Identify all one-time, recurring, usage-based, optional, pass-through, third-party, implementation, transition, and termination charges. For every line item, state the unit of measure, quantity or pricing basis, unit rate, annual extended price, one-time cost, and assumptions.

6.2 Required Line-Item Price Schedule

The pricing template is intended as a guide to assist proposers in presenting their pricing and associated cost components. It is not an exhaustive list, and proposers may include additional line items or cost categories as necessary to provide a complete and transparent pricing proposal.

Line item Pricing basis / required disclosure Platform subscription/license

Annual base fee; identify what functionality, jurisdictions, administrators, contacts, and users are included.

Jurisdiction enrollment One-time and recurring fee per participating jurisdiction, if any.

UFA administration Countywide administrator, governance, and oversight costs.

Public opt-in registration Setup and recurring costs; identify registration/contact limits and any fees.

IPAWS integration Setup, recurring, certification/support, testing, and any third-party charges.

Reverse 911 Setup and recurring costs; identify registration/contact limits and any fees.

Message delivery SMS, voice minutes/calls, email, push, social/web, and other channels; state included volumes, overage rates, and unlimited-use options.

GIS/geofencing Included functionality, GIS data/geocoding fees, map or polygon limits, and optional integrations.

Multilingual services Translation, human review, text-to-speech, voice recording, language additions, and per-message charges.

Implementation and data migration

Project management, configuration, import, validation, custom development, and integrations. Any associated licensing or costs for API .

Training and exercises Onboarding, role-based training, annual refresher training, exercise support, travel, and additional sessions.

Technical support Standard and 24/7/365 critical support; identify any premium support fees.

Hosting, maintenance, upgrades

All recurring infrastructure, maintenance, software updates, patching, backup, and disaster recovery costs.

Third-party services Provider name, purpose, pricing, rate adjustment terms, and whether the charge is pass-through.

Transition / dual operation

Cost for parallel operations, migration from incumbent systems, and cutover support.

Optional modules Each option listed separately with unit rate and annual cost.

Renewal years Annual price for each option year and any permitted escalation.

Offboarding/data export Cost for standard export, transition assistance, and any optional services.

Other fees Identify separately; do not leave unspecified charges implicit.

Total cost of ownership One-time total, annual recurring total, five-year base-term total, and each renewal-year total.

6.3 Pricing Transparency and Cost Controls

• Identify whether pricing is based on population, registered contacts, total records, jurisdictions, administrators, message volume, minutes, modules, or another metric.

• State all included allowances and every threshold that could cause additional charges.

Provide example calculations for a low-, medium-, and high-participation scenario using assumptions supplied by the UFA or clearly labeled illustrative assumptions.

• Provide at least one pricing option that maximizes cost predictability for high-volume emergencies and explain any included or unlimited SMS, voice, and email allowances.

• State whether rates are fixed during the base term. Any proposed escalation must identify the amount or formula, frequency, cap, and advance-notice period. Unspecified escalation is not permitted in the proposed pricing schedule.

• Identify any minimum annual commitment, minimum number of jurisdictions, early termination charge, overage, transaction, carrier, support, training, or data-export fee.

• State whether the UFA can add participants at the contracted rate and whether pricing decreases if participation or usage is lower than projected.

• Describe invoice timing, detail, payment terms, allocation reports, and support for jurisdiction-level cost attribution.

• Identify if the contractor can charge a participating jurisdiction directly without changing its price outside the approved participation instrument and master contract.

6.4 Fiscal Approach and Cost Allocation

Offerors shall propose a transparent fiscal approach that enables the UFA to administer a shared countywide platform and allocate costs fairly among participating entities. The proposal shall identify a recommended allocation methodology and alternatives, such as a fixed Countywide base allocation plus jurisdiction-level subscription fees, population-based allocation, service-tier allocation, or another auditable method. The offeror shall not assume the UFA has selected an allocation method.

The fiscal approach response must address:

• Which costs are fixed, variable, usage-based, optional, or directly attributable to an individual jurisdiction.

• How costs change as jurisdictions join at different dates, increase registrations, add administrators, or select optional services.

• How the vendor will support proration, cohort start dates, annual true-ups if applicable, and jurisdiction-level invoices or reports.

• How the vendor will avoid double billing during transition from legacy systems and how any dual-operation charges are calculated.

• How pricing remains transparent and comparable over the five-year base term and renewal options.

• Whether the UFA may serve as fiscal agent and receive consolidated invoices with supporting detail by participant.

• What happens to the pricing schedule if a jurisdiction withdraws, is added midyear, or changes service tier.

Offerors shall provide an example allocation table using clearly stated hypothetical amounts and assumptions. The example is for evaluation only and does not establish County population, participant count, enrollment, or commitment.

7. Minimum Contract and Performance Provisions

The following provisions are intended as requirements for the resulting agreement and are subject to final approval.

7.1 Service Levels and Incident Management

• Contractor shall maintain the agreed monthly availability target and provide service-level reports at least quarterly.

• Contractor shall maintain a documented 24/7/365 escalation process for critical failures affecting alert origination or delivery.

• Contractor shall notify the UFA promptly of a material outage, security incident, suspected data exposure, or issue affecting IPAWS integration or delivery channels, consistent with the response times negotiated in the contract.

• Contractor shall provide a written incident summary, root-cause analysis, corrective actions, and prevention measures for material outages or security events.

• Contractor shall provide advance notice of planned maintenance and shall schedule disruptive maintenance to minimize operational impact where practicable.

7.2 Data Ownership, Privacy, and Retention

The UFA and applicable participating entities retain ownership of data they provide, and data generated on their behalf, subject to applicable law and the contract. The contractor may process such data only to perform the contracted services and may not sell it, use it for advertising, or use it for unrelated purposes. The contract shall establish requirements for retention, access, deletion, legal hold, backup, and breach notification.

7.3 Change Management and Subcontractors

The contractor shall notify the UFA of material changes to the service, hosting architecture, data location, key…