Attachment J - Functional and Technical Requirements (1).xlsx
XLSX spreadsheet 119 KB Posted
- Solicitation number
- RFP-128697
- Issued by
- Henrico County, Virginia
About this file
This file is Attachment J—Functional and Technical Requirements for RFP 26-2996-8ARA, a comprehensive Recreation Management Software System solicitation by Henrico County Recreation and Parks (HCRP) in Virginia. The RFP seeks a qualified vendor to provide a complete, secure, and scalable software solution supporting core recreation business functions including program management, facility reservations, membership administration, financial processing, and reporting. The solution must support deployment in secure cloud, hybrid, or on-premises environments and operate as a fully web-based system with real-time updates. Evaluation of vendor proposals will be conducted across thirteen technical criteria weighted at 100 percent: CUI & Mobile Platform Functionality (12%), Merchant Services and Payment Capabilities (12%), Security and Compliance (12%), Total Cost of Ownership (12%), Reporting Capabilities (12%), Administrative Functionality (5%), Support & SLAs (5%), Workflow Capabilities (5%), Membership Management (5%), Programming/Activity Management (5%), Reservation Management (5%), Communication Capabilities (5%), and Automation (5%).
The requirements document establishes detailed functional specifications across fifteen functional areas, with each requirement marked as either "Highly Desirable" (HD) or "Desirable" (D) and vendors required to respond using standardized codes: C (Complies), CM (Complies with Modification), CV (Complies with Additional Vendor Involvement), or DC (Does Not Comply). Key requirements include PCI DSS Level 1 compliance for payment processing, WCAG 2.1 AA accessibility standards, integration with Microsoft SQL Server 2025 or equivalent databases, Single Sign-On and Active Directory authentication, comprehensive audit trails and logging, support for multiple membership types and facility reservation workflows, automated communications and workflow management, and robust reporting with custom and ad-hoc capabilities. The vendor must provide implementation support including discovery, configuration, data migration with trial runs, comprehensive training across multiple modalities, a dedicated project manager, distinct development/test/production environments, and post-implementation hypercare support with multi-channel customer service and a continuous learning platform.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Addendum No. 1.pdf | ||
| RFP 26-2996-8ARA Recreation Management Software System.pdf | ||
| Rec and Parks Software Price Exhibit K .xlsx | XLSX spreadsheet |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Instructions Attachment J. Functional Areas Importance of each requirement is indicated as either "Highly Desirable" (HD) or "Desirable" (D). Requirements designated as "HD" have the highest importance.
Offers should indicate their capabilities for each requirement list. Here are the Four (4) valid responses:
C = Complies with Requirement. The base system provides the functionality. Standard Package Configuration of feature(s) allowed.
CM = Complies with Modification. Some coding changes required. Cannot be accomplished by Standard Configuration of package.
CV = Complies with Additional Vendor Involvement. Functionality available via engaging another vendor's offering(s).
DC = Does Not Comply. The functionality is not offered and cannot be provided.
| Basis of Evaluation for Technical Approach, Capability and Functionality | |
| Criterion #1 – CUI & Mobile Platform Functionality | 12% |
| This criterion evaluates the Offeror’s proposed customer‑facing and staff‑facing CUI and mobile platform capabilities in accordance with Section VI, Item 1. It considers the functional requirements detailed in Section II Functional Areas 5 and 9, and the specifications provided in Attachment J, Sheet 6 (Mobile) and Sheet 10 (Marketing & Communications). |
| Criterion #2 – Merchant Services, Payment Capabilities & Business Capabilities | 12% |
| This criterion evaluates the Offeror’s payment processing, merchant integration, financial workflows, and related business capabilities in accordance with Section VI, Item 2, based on the requirements in Section II Functional Area 8 and Attachment J, Sheet 9 (Financial & Payments). |
| Criterion #3 – Security and Compliance | 12% |
| This criterion evaluates the Offeror’s adherence to enterprise security standards, authentication and authorization practices, encryption, data protection, privacy, and regulatory compliance in accordance with Section VI, Item 3, as described in Section II Functional Area 2 and Attachment J, Sheet 3 (Security & Compliance). |
| Criterion #4 – Total Cost of Ownership (Price) | 12% |
| This criterion evaluates the Offeror’s complete pricing model, including licensing, hosting, implementation, maintenance, training, operation, and optional modules in accordance with Section VI, Item 4 and Tab 20 of the Proposal Response Format. |
| Criterion #5 – Reporting Capabilities | 12% |
| This criterion evaluates the Offeror’s reporting and analytics functionality in accordance with Section VI, Item 5, based on Section II Functional Area 14 and detailed in Attachment J, Sheet 15 (Reporting & Analytics). |
| Criterion #6 – Administrative Functionality | 5% |
| This criterion evaluates the Offeror’s administrative configuration capabilities, rule management, workflows, versioning, environment governance, template management, and supervisory controls in accordance with Section VI, Item 6, aligned with Section II Functional Area 7 and Attachment J, Sheet 8 (Administration & Controls). |
| Criterion #7 – Support & SLAs | 5% |
| This criterion evaluates the Offeror’s training program, implementation support, system documentation, maintenance processes, service‑level agreements, uptime commitments, and related support requirements in accordance with Section VI, Item 7, aligned with Section II Functional Area 15 and detailed in Attachment J, Sheet 16 (Training & Implementation). |
| Criterion #8 – Workflow Capabilities | 5% |
| This criterion evaluates the Offeror’s ability to provide configurable workflows that support administrative, programmatic, reservation, and approval processes in accordance with Section VI, Item 8 and aligned with Section II Functional Areas 7, 12, and 11, with specifications in Attachment J, Sheets 8 (Administration & Controls), 13 (Program & Activity), and 12 (Facility & Shelter Reservations). |
| Criterion #9 – Membership Management Capabilities | 5% |
| This criterion evaluates the Offeror’s ability to support membership configuration, eligibility rules, renewals, holds, scanning, access control, reporting, and usage tracking in accordance with Section VI, Item 9, aligned with Section II Functional Area 10 and documented in Attachment J, Sheet 11 (Membership Management). |
| Criterion #10 – Programming / Activity Management Capabilities | 5% |
| This criterion evaluates the Offeror’s ability to support program setup, eligibility rules, enrollments, waitlists, attendance, communications, transfers, and program lifecycle management in accordance with Section VI, Item 10, and aligned with Section II, Functional Area 12, as detailed in Attachment J, Sheet 13 (Program & Activity). |
| Criterion #11 – Reservation Management Capabilities | 5% |
| This criterion evaluates the Offeror’s ability to support facility search, booking workflows, permit management, availability controls, approvals, payments, and reservation reporting in accordance with Section VI, Item 11, and aligned with Section II, Functional Area 11, as documented in Attachment J, Sheet 12 (Facility & Shelter Reservations). |
| Criterion #12 – Communication Capabilities | 5% |
| This criterion evaluates the Offeror’s ability to support manual, scheduled, automated, and targeted communications including program notifications, cancellations, permit updates, alerts, and system‑generated messages in accordance with Section VI, Item 12, aligned with Section II Functional Area 9 and documented in Attachment J, Sheet 10 (Marketing & Communications). |
| Criterion #13 – Automation | 5% |
| This criterion evaluates the Offeror’s ability to support automated workflows, automated class activation and inactivation, automated communications, automated reporting, and automated waitlist management in accordance with Section VI, Item 13. It draws upon requirements across Section II Functional Areas 7, 9, 12, and 14, with specifications found in Attachment J, Sheets 8, 10, 13, and 15. | |
| Total | 100% |
1.Technical and Hosting
| 1 | Technical & Hosting | |||
| Requirement ID | Requirement Description | HD-D | Vendor Response | Vendor Notes-Comments |
| 1. Platform, Database & Hosting Requirements | ||||
| 1.1.1 | The solution shall support deployment in secure cloud, hybrid, or on‑premises environments aligned with County standards. If cloud‑hosted, the Vendor shall provide Tier IV–equivalent hosting infrastructure capable of supporting peak‑traffic loads, including high‑volume spikes during registration periods. | HD | C | |
| 1.2.2 | The solution shall support Microsoft SQL Server (2025 or newer) or vendor‑approved equivalent relational database platforms. The solution shall operate as a fully web‑based system with real‑time updates, compatible with both cloud‑hosted and locally hosted configurations. | HD | DC | |
| 1.2.3 | The system shall support Single Sign‑On (SSO) and Active Directory (AD) authentication using industry‑standard protocols to enable unified authentication and role‑based access across County systems. | HD | CM | |
| 2. System Compatibility, Browsers & Hardware Requirements | ||||
| 1.2.1 | The system shall be compatible with Microsoft Windows 11 Pro or higher and standard USB‑connected peripheral hardware. | HD | C | |
| 1.2.2 | The system’s online components shall support current versions of major web browsers, including Chrome, Edge, Firefox, and Safari. | HD | DC | |
| 1.2.3 | The Vendor shall provide a comprehensive list of hardware requirements for all applicable devices, including but not limited to touch screens, payment pin pads (semi‑integrated PCI-certified only), cameras, cash drawers, scanners, access devices. | HD | ||
| 1.2.4 | All recommended hardware and software must be compliant with a routed IP network and include detailed power and connectivity specifications (e.g., electrical requirements, PoE compatibility, wired/wireless network needs, and any required cabling or adapters). | HD | ||
| 1.2.5 | The Vendor shall provide complete hardware maintenance and support documentation, including service intervals, warranty terms, replacement procedures, and available technical support resources. | HD | ||
| 3. System Reliability, Synchronization & Performance | ||||
| 1.3.1 | The system shall maintain real‑time data synchronization across all administrative modules so configuration changes, transactions, and updates are immediately reflected across dependent workflows, reporting tools, and customer interfaces. | HD | ||
| 4. Environment Management & Configuration Governance | ||||
| 1.4.1 | The system shall provide environment management capabilities for development, testing, staging, and production environments, including controlled configuration migration, promotion workflows, and audit trails of all changes between environments. | HD | ||
| 1.4.2 | The system shall support configuration backup, restore, and rollback, including export and import of configuration sets, scheduled backups, and documented disaster‑recovery procedures. | HD | ||
| 1.4.3 | The system shall support feature‑flag governance, enabling administrators to enable or disable modules or features by role, site, group, or environment using auditable toggles. | HD | ||
| 5. System Updates, Versioning & Deployment Controls | ||||
| 1.5.1 | The system shall support versioning and update management that enables patches, upgrades, and feature rollouts with no downtime or minimal downtime, and shall include fully supported rollback mechanisms and published release notes. | HD | ||
| 1.5.2 | The Vendor shall provide a formal communication and deployment plan for system upgrades, maintenance windows, and service interruptions. | HD |
2. Security & Compliance
| 2 | Security & Compliance | |||
| Requirement ID | Requirement Description | HD-D | Vendor Response | Vendor Notes-Comments |
| 1. Identity, Authentication & Access Control | ||||
| 2.1.1 | The system shall enforce role‑based access controls (RBAC) to ensure that only authorized users may view or perform sensitive functions such as refunds, cancellations, account changes, or other high‑risk activities. | HD | ||
| 2.1.2 | The system shall provide secure authentication mechanisms, including Single Sign‑On (SSO) integration with Active Directory using industry‑standard protocols (e.g., SAML, OAuth 2.0), and shall support multi‑factor authentication for privileged and administrative roles. | HD | ||
| 2.1.3 | The system shall support configurable password‑policy controls, including password‑complexity rules, expiration intervals, and failed‑login lockout thresholds for customers and staff. | HD | ||
| 2.1.4 | The system shall include enterprise Identity and Access Management (IAM) capabilities, providing granular roles, permission groups, security hierarchies, and full AD/SSO integration across County systems. | HD | ||
| 2.1.5 | The system shall provide granular account‑level security controls allowing access restrictions by functional area and permissions for view, add, update, and delete, assignable to individual users or definable user groups. The system shall allow user‑level control over access to document templates and customizable page layouts based on assigned security rights. | HD | ||
| 2.1.6 | The system should provide a secure “Forgot Password” process that issues temporary passwords or validates security‑question responses for account recovery for customers. | D | ||
| 2.1.7 | The solution shall support configuration of system‑access restrictions, including the ability to limit access based on IP address for authorized end‑user devices. | HD | ||
| 2. Encryption, Data Protection & Privacy Controls | ||||
| 2.2.1 | The system shall protect all data in transit using TLS 1.3 or higher, and protect all data at rest using strong encryption with documented key‑management procedures and periodic key rotation. | HD | ||
| 2.2.2 | The system shall ensure secure handling and storage of sensitive information, including PII, PHI, payment tokens, and documents, in alignment with privacy‑by‑design principles and data‑minimization practices. | HD | ||
| 2.2.3 | The system should provide secure document‑storage capabilities including content‑type validation, malware scanning, granular access controls, versioning, and permissioned retrieval. | D | ||
| 2.2.4 | The system shall provide privacy controls including PII masking or redaction in logs and user interfaces, configurable consent notices, and opt‑in/opt‑out mechanisms for communications. | HD | ||
| 2.2.5 | The system shall support formal data‑retention and deletion schedules, including legal hold, archiving, and defensible deletion for regulated records. | HD | ||
| 2.2.6 | The system shall support data‑subject rights workflows, including the ability to retrieve, export, correct, and delete personal data as required under applicable privacy laws. | HD | ||
| 2.2.7 | The system shall operate independently of credit‑card terminals and shall not require direct device‑level communication with payment terminals for any transaction. | HD | ||
| 3. Compliance, Accessibility & Regulatory Requirements | ||||
| 2.3.1 | The system shall comply with all applicable federal, state, local, and industry‑specific regulations, including public records requirements, retention policies, PCI DSS, ADA/WCAG 2.1 AA, GDPR, HIPAA, and relevant financial and privacy rules. | HD | ||
| 2.3.2 | The Vendor shall provide an Accessibility Conformance Report (ACR) demonstrating WCAG 2.1 AA compliance as required by the Department of Justice. | HD | ||
| 2.3.3 | The System shall meet WCAG 2.1 AA accessibility guidelines, including keyboard navigation for frozen headers, proper table semantics, and screen-reader support. | HD | ||
| 2.3.4 | The Vendor shall specify all encryption and authentication protocols used for storing, transmitting, and accessing data; identify all jurisdictions where data (including backups and replicated copies) is stored or transmitted; and list all personnel, subcontractors, or representatives who may access County data. | HD | ||
| 2.3.5 | All system data shall be solely owned by Henrico County, and the Proponent shall not use County data for any purpose other than delivering the system’s required functionality. The system shall allow the County to obtain system data on demand or on a periodic schedule. | HD | ||
| 4. Payment Security & PCI Requirements | ||||
| 2.4.1 | The system shall provide secure online‑payment capabilities using a PCI DSS Level 1 compliant payment gateway, including CVV validation and encrypted autopay/tokenization. | HD | ||
| 2.4.2 | The system shall never store raw cardholder data, and all payment interactions shall use tokenized references and compliant processor integrations. | HD | ||
| 5. Logging, Monitoring & Auditability | ||||
| 2.5.1 | The system shall maintain comprehensive audit trails for sensitive actions and configuration changes, capturing user ID, timestamp, before‑and‑after values, and rationale. | HD | ||
| 2.5.2 | The system shall support supervisor overrides and dual‑control workflows for high‑risk actions such as reversing payments or modifying GL mappings, with full auditability. | HD | ||
| 2.5.3 | The system shall provide configurable security alerts and monitoring dashboards, including alerts for failed logins, anomalous access, abnormal data‑export activity, and privilege‑escalation events. | HD | ||
| 2.5.4 | The system shall provide system‑health, error‑log, and performance‑monitoring dashboards with configurable alert thresholds and retention policies. | HD | ||
| 6. API Security, Integrations & Network Controls | ||||
| 2.6.1 | The system shall implement secure API controls, including scoped authentication tokens, IP allow‑listing, rate limiting, and per‑endpoint authorization aligned with RBAC. | HD | ||
| 2.6.2 | The system shall integrate securely with County systems using authenticated, encrypted connections that maintain consistent identity and authorization rules across modules. | HD | ||
| 7. Security Testing, Patching & Vulnerability Management | ||||
| 2.7.1 | The system shall undergo pre‑deployment security testing, including secure code reviews, unit tests, user‑acceptance testing, vulnerability scanning, and performance testing. | HD | ||
| 2.7.2 | The system shall undergo periodic independent third‑party penetration testing. | HD | ||
| 2.7.3 | The system shall provide a vulnerability‑management program including timely security patching, remediation SLAs, and documented risk‑acceptance procedures where applicable. | HD | ||
| 2.7.4 | The system shall support zero‑downtime or minimal‑downtime deployment of critical security patches, including rollback plans and change‑management approvals. | HD | ||
| 8. Security Documentation, Availability & Disaster Recovery | ||||
| 2.8.1 | The Vendor shall publish security and compliance documentation, including policies, data dictionaries, control mappings, and annual compliance attestations (e.g., PCI attestation of compliance), accessible to authorized County staff. | HD | ||
| 2.8.2 | The Vendor shall provide uptime guarantees, disaster‑recovery procedures, and overall system‑availability commitments for hosted solutions. | HD |
3. Integration & Data Exchange
| 3 | Integration & Data Exchange | |||
| Requirement ID | Requirement Description | HD-D | Vendor Response | Vendor Notes-Comments |
| 1. Import, Export, Migration & Data Exchange Operations | ||||
| 3.1.1 | The solution shall support secure cloud, hybrid, or on‑premises hosting in accordance with County standards and shall operate as a web‑based system with real‑time updates. | HD | ||
| 3.1.2 | The system shall support data import, including but not limited to GIS residency datasets, historical records, and household/account information. Import tools shall support household merges, unmerges, and preservation of existing data during system transitions. | HD | ||
| 3.1.3 | The system shall support automated and manual data extraction, including scheduled batch exports, ad‑hoc downloads, and administrator‑configured queries in formats such as CSV, Excel, and JSON. | HD | ||
| 3.1.4 | The system shall support standard data export formats for structured and unstructured data and the Vendor shall provide a catalog of all supported export formats. | HD | ||
| 3.1.5 | The system shall enable cross‑system synchronization, ensuring that updates, cancellations, and modifications in any module are reflected across all dependent or integrated components, including accounting, payments, facilities, and reporting systems. | HD | ||
| 2. APIs, Interoperability & External System Integrations | ||||
| 3.2.1 | The solution shall provide a fully documented Application Programming Interface (API) that supports two‑way, real‑time or near‑real‑time data exchange with external systems. | HD | ||
| 3.2.2 | APIs shall be secure and standards‑based, supporting REST/JSON, SFTP, or equivalent protocols, and shall enable external vendors, enterprise systems, and County services to retrieve, update, and exchange core data. | HD | ||
| 3.2.3 | The system shall expose data dictionaries, schemas, and lookup codes (including GL, tax, residency, facility, activity, and program classifications) to ensure consistent interpretation of data by external systems. | HD | ||
| 3.2.4 | The system should support the exchange of documents and scanned attachments (e.g., waivers, certifications, insurance forms) via the API, allowing external systems to retrieve and reference these artifacts. | D | ||
| 3.2.5 | The system shall support integration with payment services and workflows, ensuring that fees, refunds, adjustments, and discounts are accurately reflected in downstream accounting and reporting systems. | HD | ||
| 3.2.6 | The solution shall support integration with external platforms, including but not limited to ESRI ArcGIS (address validation, mapping, geolocation), Digital signage systems (real‑time or scheduled data feeds) Enterprise reporting platforms (Crystal Reports, SSRS, or equivalent) Social media platforms such as Facebook, Twitter, and Instagram for publishing approved content or notifications. | HD | ||
| 3.2.7 | The system should support integrated communications triggers, enabling automated notifications (e.g., ADA alerts, required forms, class updates, facility updates) to designated staff or customers based on system‑defined events. | D | ||
| 3.2.8 | The system should support publishing program schedules and facility reservations as subscribable iCalendar (ICS) feeds and Microsoft Graph API integration to write/read calendars as configured, with granular permissions. (supporting API to Outlook/Microsoft 365 calendars) | D | ||
| 3.2.9 | The system should integrate with Microsoft SharePoint Online for storage of documents. | D | ||
| 3. GIS & Location‑Based Integrations | ||||
| 3.3.1 | The system shall integrate with GIS services to import addresses, validate residency status, detect duplicates, and support geolocation‑based functionality within reservations, facilities, event management, and household records. | HD |
4. Access Control
| 4 | Access Control | |||
| Requirement ID | Requirement Description | HD-D | Vendor Response | Vendor Notes-Comments |
| 1. Credential Production, Scanning & Access Validation | ||||
| 4.1.1 | The solution shall support the production and use of scannable credentials, including membership cards, passes, printed receipts, and mobile‑displayed identifiers,for validating customer access at controlled entry points, and shall allow validation for both members and drop‑in guests. | HD | ||
| 4.1.2 | The system shall provide barcode and QR‑code creation and scanning capabilities, including smartphone check‑in, class check‑in, ticket scanning, and kiosk‑mode functionality across multiple devices and locations. | HD | ||
| 4.1.3 | The system should support mobile‑device scanning of memberships, including display of remaining punches or expiration details, and shall support remote scanning at non‑networked locations through a mobile or web application. | D | ||
| 4.1.4 | A mobile platform shall support generating unique barcodes or QR codes for activities and memberships to enable fast check‑ins and real‑time validations. | HD | ||
| 2. Entry‑Point Controls, Restrictions & Validation Rules | ||||
| 4.2.1 | The solution shall validate customer credentials at control points and shall alert staff or patrons when an invalid or unauthorized barcode or identifier is presented. | HD | ||
| 4.2.2 | The system shall enforce access restrictions based on hours of operation, membership status, required waivers, and other user‑defined rules, including pre‑defined visit‑limit rules such as punch‑card‑based access. | HD | ||
| 4.2.3 | The system shall allow staff to scan a customer’s credential at a control desk to display associated account information, including membership type, waiver status, and staff‑facing notes or alerts on customer accounts. | HD | ||
| 3. Logging, Reporting & Audit | ||||
| 4.3.1 | The system shall automatically record all entries processed at control points and shall provide reporting tools to monitor attendance, usage patterns, and access history. | HD |
5. Mobile
| 5 | Mobile | |||
| Requirement ID | Requirement Description | HD-D | Vendor Response | Vendor Notes-Comments |
| 1. Mobile Application & User Interface | ||||
| 5.1.1 | The system shall provide full mobile compatibility or a dedicated mobile application that allows customers and staff to make reservations, view schedules, manage bookings, complete registrations, sign up for memberships, and perform key system functions from any smartphone or tablet. | HD | ||
| 5.1.2 | The system shall include a modern, responsive mobile user interface that adapts automatically to various screen sizes and supports intuitive touch‑based navigation. | HD | ||
| 5.1.3 | The system shall provide both full mobile‑responsive web compatibility and a native mobile application for iOS and Android. | HD | ||
| 2. Mobile Scanning, Check‑In & Attendance Tracking | ||||
| 5.2.1 | The system should support mobile QR‑code and barcode scanning to enable attendance tracking, membership validation, ticketing, and activity check‑ins directly from mobile devices. | D | ||
| 5.2.2 | The system should allow smartphone‑based check‑in and check‑out, including real‑time attendance capture for programs, events, and facilities. | D | ||
| 5.2.3 | The system should support mobile digital punch‑clock functionality that allows authorized contacts, such as guardians, to check participants in or out during drop‑off and pick‑up. | D | ||
| 5.2.4 | The software shall support the creation and scanning of unique QR codes and barcodes for activities and memberships, enabling fast check‑ins and validations across multiple devices and locations, including remote or non‑networked locations via a mobile or web application. | HD | ||
| 5.2.5 | The system should be capable of tracking activity attendance and allowing customers to check themselves in digitally through a mobile device. | D | ||
| 3. Mobile Kiosk & Multi‑Device Support | ||||
| 5.3.1 | The system shall support a mobile kiosk mode offering touch‑friendly workflows for on‑site self‑service check‑in, waiver completion, and registration. | HD | ||
| 5.3.2 | The system shall support device assignment and simultaneous scanning, ensuring that multiple mobile devices can operate at the same location without conflict and can be tied to specific staff members or workstations. | HD | ||
| 4. Mobile Forms, Waivers & Signatures | ||||
| 5.4.1 | The system should support mobile electronic signatures, enabling users to sign waivers, forms, and payment authorizations directly from a smartphone or tablet. | D | ||
| 5. Mobile Mapping, Geolocation & Facility Data | ||||
| 5.5.1 | The system shall integrate with mobile mapping services, including maps and GIS data, to display facility locations, directions, and geolocation‑based features within the mobile interface. | HD | ||
| 5.5.2 | The system shall allow customers to download or view detailed booking information on a mobile device. | HD | ||
| 6. Mobile Rosters & Staff Tools | ||||
| 5.6.1 | The system should provide real‑time mobile access to rosters and attendance data, allowing staff to view participant lists, verify enrollment, and update attendance from any mobile device. | D | ||
| 7. Mobile Notifications | ||||
| 5.7.1 | The mobile solution shall support push notifications, including event reminders, account‑balance alerts, and notifications when waitlist openings become available. | HD | ||
| 8. Attendance & Self‑Check‑In for Communication Triggers | ||||
| 5.8.1 | The system should support digital activity attendance tracking and allow customers to check themselves in digitally or via mobile device, enabling communications tied to attendance events where required. | D |
6. Profile Setup & Account Mgmt
| 6 | Profile Setup & Account Management | |||
| Requirement ID | Requirement Description | HD-D | Vendor Response | Vendor Notes-Comments |
| 1. Household & Individual Account Management | ||||
| 6.1.1 | The system shall provide comprehensive household and individual account management, supporting multiple contacts, multiple addresses, multiple email and phone entries, photos, residency verification, emergency contacts, ADA and inclusion needs, and duplicate‑prevention tools. | HD | ||
| 6.1.2 | The system shall allow creation and full management of household accounts, including adding and removing household members, designating a primary contact, and supporting multiple family members registering for different programs simultaneously. | HD | ||
| 6.1.3 | The system shall store comprehensive profile data for each household member, including name, birthdate, contact numbers, multiple email addresses, physical and mailing addresses, employer information, emergency contacts, and other customizable fields, with administrators able to specify required fields. | HD | ||
| 6.1.4 | The system shall support entry and tracking of household‑level attributes, including organizational information such as organization name, type, and EIN, multiple contacts for organizations, and residency classification. | HD | ||
| 2. Verification, GIS Integration, Photos & Special‑Needs Tracking | ||||
| 6.2.1 | The system shall support real‑time address validation and GIS data integration to ensure accurate household addresses, confirm residency status, and prevent duplicate household creation. | HD | ||
| 6.2.2 | The system shall allow households and staff to upload and store photos for household members—including participants and guardians—and display these photos wherever needed for verification or attendance. | HD | ||
| 6.2.3 | The system shall support recording and management of accessibility, inclusion, medical, ADA‑related needs, special‑needs indicators, and associated notes, including the ability to trigger automated internal notifications when required. | HD | ||
| 3. Communication Preferences & Contact Preferences | ||||
| 6.3.1 | The system shall allow households and users to maintain multiple communication preferences, including email versus text selections, receipt‑only notification options, and designation of preferred contacts. | HD | ||
| 6.3.2 | The system shall allow customers to opt in or opt out of email lists and shall support delivery of email communications in both text and HTML formats. The system shall support automated email reminders for activities such as upcoming program registrations, facility bookings, court times, pass renewals, and fee‑assistance renewals. | HD | ||
| 4. Account Creation, Authentication, Custom Fields & Status Codes | ||||
| 6.4.1 | The system shall allow users to securely create accounts, set passwords, answer security questions, retrieve usernames and passwords, and optionally authenticate using approved social sign‑in providers. | HD | ||
| 6.4.2 | The system shall allow administrators to enforce required fields during account creation and shall support the creation, modification, and removal of user‑defined custom fields. The system shall automatically assign unique identifiers such as customer ID numbers and PINs at the time of account creation. | HD | ||
| 6.4.3 | The system shall support configurable customer status codes, including but not limited to active, suspended, frozen, and deceased, and shall enforce associated business rules such as preventing transactions or renewals when an account is frozen due to outstanding balances. The Proponent shall describe the operational impact of each status code. | HD | ||
| 6.4.4 | The system shall enforce the requirement that at least one adult be designated as the primary account holder for each household account. | HD | ||
| 5. Search, Record Management & Duplicate Prevention | ||||
| 6.5.1 | The system shall provide robust search tools for locating households, individuals, organizations, activities, and facilities using partial matches for names, addresses, phone numbers, email addresses, or activity identifiers. | HD | ||
| 6.5.2 | The system shall include comprehensive household search and record‑management capabilities that allow staff to search by partial name, phone number, email address, physical address, or nickname, and that maintain full household change history. | HD | ||
| 6.5.3 | The system shall provide duplicate‑detection for new records created by staff or customers online, shall warn users of potential duplicate accounts, and shall allow merging of duplicate accounts with full consolidation and retention of account history. | HD | ||
| 6. Waivers, Documents, Attachments & Alerts | ||||
| 6.6.1 | The system shall allow households to complete, store, and manage waivers and required documents, including tracking waiver dates, supporting electronic signatures, linking forms to household records, and storing uploaded document attachments. | HD | ||
| 6.6.2 | The system shall allow scanned documents—including tax forms, proof‑of‑residency documentation, insurance documentation, and membership agreements—to be associated with household and customer records. The Proponent shall identify any hardware requirements related to scanning devices. | HD | ||
| 6.6.3 | The system shall support user‑defined notes and alerts on household or customer records, including effective and expiration dates, and shall automatically post or remove alerts at the specified times. Alerts shall display when staff access the household or when customers log into the web portal. | HD | ||
| 7. Customer Database & List Building | ||||
| 6.7.1 | The solution shall maintain a single, centralized customer database across all modules, providing a unified, authoritative view of all household and individual account information. | HD | ||
| 6.7.2 | The system shall allow creation of an unlimited number of customer lists for email, text messaging, and hard‑copy mailings, and shall support automated list‑building tools that segment audiences using user‑defined parameters. | HD | ||
| 8. Vendor Communication Requirements | ||||
| 6.8.1 | The Vendor should provide for system upgrades and all other maintenance or service interruptions through the CUI. | D |
7. Administration & Controls
| 7 | Administration & Controls | |||
| Requirement ID | Requirement Description | HD-D | Vendor Response | Vendor Notes-Comments |
| 1. Administrative Configuration & Rule Management | ||||
| 7.1.1 | The system shall provide comprehensive administrative configuration tools that allow administrators to create, edit, activate, deactivate, and archive activities, classes, events, and modules. | HD | ||
| 7.1.2 | The system shall support advanced rule‑based configuration, including prerequisites, age rules, late‑fee rules, blackout dates, eligibility criteria, and automatic inactivation, customizable by module. | HD | ||
| 7.1.3 | The system shall allow administrators to design and deploy custom data structures, including custom fields, question banks, survey sets, roster templates, code lists, and reusable configuration components. | HD | ||
| 7.1.4 | The system shall provide configurable automated workflows, including auto‑activation and expiration of programs, late‑fee triggers, rule‑driven notifications, and other conditional administrative processes. | HD | ||
| 2. Administrative Logging, Change Tracking & Validation | ||||
| 7.2.1 | The system shall maintain complete administrative change logs recording user ID, timestamp, original value, new value, and the fields affected for every configuration update. | HD | ||
| 7.2.2 | The system shall maintain real‑time data synchronization across administrative modules so that configuration updates are immediately reflected in all dependent workflows, reports, and customer‑facing views. | HD | ||
| 7.2.3 | The system shall perform real‑time cross‑module data validation to ensure that customer information, residency status, eligibility rules, fees, and reservation data remain consistent throughout the system. | HD | ||
| 3. Administrative Dashboards, Views & Search Tools | ||||
| 7.3.1 | The system should provide configurable administrative dashboards and views that allow staff to adjust widgets, filters, analytics components, and layout configurations for operational oversight. | D | ||
| 7.3.2 | The system should provide advanced search‑configuration tools enabling administrators to define searchable attributes, indexing strategies, and custom filter rules for major record types. | D | ||
| 7.3.3 | The system should provide sticky/frozen column and row headers across all grid/list views and reports in all modules, maintaining header visibility during vertical and horizontal scrolling. | D | ||
| 4. Document & Data Management Configuration | ||||
| 7.4.1 | The system should include structured document‑management configuration tools supporting upload, tagging, storage, versioning, permissions, and secure foldering for administrative documents, including waivers and policies. | D | ||
| 7.4.2 | The system shall provide a complete data dictionary and schema documentation describing tables, field definitions, validation rules, code sets, enumerations, and integration points. | HD | ||
| 5. Updates, Versioning & Environments | ||||
| 7.5.1 | The system shall support versioning and update‑management capabilities, allowing patches and feature rollouts without system downtime and including rollback mechanisms and documented release notes. | HD | ||
| 7.5.2 | The system shall provide environment management across development, testing, staging, and production, including controlled configuration migration, promotion workflows, and detailed audit trails of inter‑environment changes. | HD | ||
| 7.5.3 | The system shall support configuration backup, restoration, and rollback, including export and import of configuration sets, scheduled backups, and documented disaster‑recovery parameters. | HD | ||
| 7.5.4 | The system shall support feature‑flag governance, enabling administrators to enable or disable modules or features by role, site, group, or environment with auditable toggle actions. | HD | ||
| 6. Bulk Actions, Hierarchies, Defaults & Templates | ||||
| 7.6.1 | The system shall support bulk administrative actions, including batch editing of activities, reservations, codes, pricing rules, and classifications across multiple modules. | HD | ||
| 7.6.2 | The system shall enable configuration of hierarchical structures such as facility trees, program categories, organizational groupings, and nested classifications for navigation and reporting. | HD | ||
| 7.6.3 | The system shall allow administrators to set global system defaults, including time zones, operating hours, naming conventions, standardized labels, GL/tax codes, and activity categories. | HD | ||
| 7.6.4 | The system shall enable creation and management of system‑wide templates, including communication templates, form and waiver templates, survey templates, and report and receipt templates. | HD | ||
| 7. Alerts, Prompts, Notices & Segmentation | ||||
| 7.7.1 | Administrators shall be able to activate, deactivate, and modify a variety of system alerts without vendor intervention and may configure these notifications to repeat, escalate, or expire based on business rules. | HD | ||
| 7.7.2 | The system shall support configurable pop‑up notices and administrative flags, allowing staff to design rule‑based prompts, warnings, and informational messages. | HD | ||
| 7.7.3 | The system shall support administrative segmentation and tagging that allows classification of households, organizations, passes, and events for reporting, communication, and operational targeting purposes. | HD | ||
| 8. Supervisory Controls & Role‑Based Authority | ||||
| 7.8.1 | The system shall provide supervisor‑level controls that enable role‑based override authority, restricted access to sensitive configuration areas, and dual‑approval workflows for high‑risk administrative changes. | HD | ||
| 9. Session Management & Inactivity Controls | ||||
| 7.9.1 | The system shall allow administrators to define a timeout to remove held items from incomplete or inactive transactions. | HD | ||
| 7.9.2 | The system shall provide a configurable timeout mechanism that monitors session activity, releases items when transactions become inactive, and returns those items to availability; administrators shall be able to apply timeout settings system‑wide or by module and access logs of released items. | HD | ||
| 10. Display, Branding & Database Visibility Controls | ||||
| 7.10.1 | The system shall allow full customization of the site’s look and feel, including configurable control of colors, fonts, backgrounds, headers, images, graphics, and custom hyperlinks. | HD | ||
| 7.10.2 | The system shall provide controls to determine what database information is permitted for online display or processing, ensuring that information used for web display or customer interaction only needs to be maintained once. | HD | ||
| 7.10.3 | The system shall include administration‑support resources such as vendor‑provided user guides, staff training materials, administrator documentation, configuration tutorials, knowledge‑base access, and responsive technical support. | HD |
8. Financial & Payments
| 8 | Financial & Payment | |||
| Requirement ID | Requirement Description | HD-D | Vendor Response | Vendor Notes-Comments |
| 1. Fee Engine, Billing Rules & Pricing Structures | ||||
| 8.1.1 | The system shall support a flexible fee engine capable of applying multiple fees per reservation or transaction, with pricing determined by customer type, residency, location, date, program rules, and reservation requirements. | HD | Technica | |
| 8.1.2 | The system shall support complex billing scenarios, including hourly rates, facility‑specific fees, amenity fees, security deposits, multi‑fee structures, multi‑payor scenarios, and split payments. | HD | ||
| 8.1.3 | The system shall allow authorized users to create and edit activities or reservations with associated fee rules, discount rules, and pricing structures that may be applied manually or automatically. | HD | ||
| 2. Discounts, Scholarships & Fee Assistance | ||||
| 8.2.1 | The system shall provide configurable discount tools, including scholarships, multi‑pass discounts, multi‑registrant discounts, second‑household discounts, prorated fees, and support for multiple simultaneous discounts. | HD | ||
| 8.2.2 | The system shall support multiple discount structures, including percentage‑based discounts, declining balances, and fixed‑value discounts, and shall support configuration of maximum dollar or usage limits by customer type, account, or individual for designated terms. | HD | ||
| 8.2.3 | The system shall support creation and management of Fee Assistance programs, allowing assignment of assistance to individuals within a household, definition of program term lengths, assignment of multiple subsidies per customer, and configuration of fee‑assistance‑based adjustments. | HD | ||
| 8.2.4 | The system shall track Fee Assistance balances, usage, and expiration dates and shall provide customers with online access to view their remaining balances and applicable terms. | HD | ||
| 3. Payment Processing & PCI Compliance | ||||
| 8.3.1 | The system shall be fully PCI‑compliant and shall incorporate a PCI Level 1 compliant payment gateway with CVV validation and encrypted transmission for all credit‑card‑related transactions. | HD | ||
| 8.3.2 | The system shall securely support payments made by credit/debit card, cash, check, money order, e‑check, bank transfer, and digital wallets such as Apple Pay and Google Pay. | HD | ||
| 8.3.3 | The system shall integrate with approved third‑party payment processors, shall not store raw credit‑card data internally, and shall support BYO merchant services that interoperate without introducing non‑standard processors or workflows, including preferred integration with the County’s standardized processor (e.g., Paymentus). | HD | ||
| 8.3.4 | The system shall support point‑of‑sale transactions, registrations, reservations, memberships, and all other fee‑based activities using consistent financial controls and reconciliation processes. | HD | ||
| 8.3.5 | The system shall automatically post and reconcile credit‑card transactions daily with minimal to no manual intervention. | HD | ||
| 4. Checkout, Payment Plans & Auto‑Draft | ||||
| 8.4.1 | The system shall provide a checkout process that includes transaction review and prioritizes the application of available account credit before other payment methods. | HD | ||
| 8.4.2 | The system shall support payment plans, including installment schedules with configurable intervals such as weekly, monthly, or custom periods. | HD | ||
| 8.4.3 | The system shall support auto‑draft and recurring membership or installment payments using encrypted financial data, including EFT and automatic credit‑card billing for scheduled or continuous‑payment memberships until canceled by the customer. | HD | ||
| 8.4.4 | The system shall send automatic notifications for declined payments and failed scheduled billing attempts. | HD | ||
| 8.4.5 | The System shall automate dunning (payment, due, installment due, outstanding balances), with configurable sequences, per‑program overrides, and exclusion lists (e.g., fee waivers). | HD | ||
| 5. Cancellation, Refunds & Adjustments | ||||
| 8.5.1 | The system shall support cancellation and refund workflows configured by module, allowing manually processed refunds and customer‑initiated cancellations used in conjunction with automated refund rules based on deadlines and policy configurations. | HD | ||
| 8.5.2 | The system shall process full and partial refunds, including membership‑pass refunds, security‑deposit refunds, and refund adjustments tied to fee changes or discount corrections. | HD | ||
| 8.5.3 | The system shall support refund methods including, at minimum, check and account credit. | HD | ||
| 8.5.4 | The system shall support reversals, corrections of miscoded transactions, and payment adjustments subject to supervisor approval. | HD | ||
| 6. Financial Records, History, Audit Trails & Cashiering | ||||
| 8.6.1 | The system shall maintain a complete archived transaction history, including payment details, customer or household identifiers, GL codes, transaction dates, and the identity of the user who processed each transaction. | HD | ||
| 8.6.2 | The system shall provide a comprehensive audit trail for all financial adjustments, including fee changes, refunds, payment‑plan changes, GL corrections, and credit memos, with timestamps, user IDs, and justification. | HD | ||
| 8.6.3 | The system must include a cashiering module that maintains customer account balances (fees, payments, credits, deposits, etc.) and integrates with the County’s payment processor. | HD | ||
| 8.6.4 | The system shall allow supervisors to void, edit, or correct transactions, with all such corrections reflected consistently across financial reporting and GL summaries. | HD | ||
| 8.6.5 | The system shall enable transaction‑specific inquiries, including identification of who paid fees for an attendee, household financial histories, and export of activity‑related financial data. | HD | ||
| 8.6.6 | The system shall support importing legacy financial data without loss of accuracy, maintaining historical logs of changes including fee waivers and staff‑entered notes. | HD | ||
| 7. Gift Cards, Credits & Balance Tracking | ||||
| 8.7.1 | The system shall support issuance and tracking of gift cards or certificates with unique single‑use codes, configurable expiration dates, and eligibility for use both online and in person. | HD | ||
| 8.7.2 | The system shall support tracking account credit balances, deposit balances, and aging of credit‑on‑account items. | HD | ||
| 8. Reconciliation & Financial Reporting | ||||
| 8.8.1 | The system shall support daily reconciliation, payment posting, refund processing, and tracking of payment‑plan activity. | HD | ||
| 8.8.2 | The system shall generate comprehensive financial reports including payment summaries, refund reports, sales‑tax reports, deposit reports, credit‑balance aging, cost‑of‑goods‑sold, general‑ledger summaries, and reports of declined payments and chargebacks. | HD | ||
| 8.8.3 | The system shall generate declined‑payment and chargeback reports, including card brand, decline reason, transaction amount, and associated household. | HD | ||
| 8.8.4 | The system shall allow users to export financial data in PDF, Excel, and CSV formats using customizable filters such as date ranges, workstations, transaction site, location, receipt ranges, GL code, and transaction type. | HD | ||
| 8.8.5 | The system shall support integration between payment workflows and all other system modules to ensure that fees, discounts, refunds, and adjustments flow accurately into accounting, reporting, and reconciliation tools. | HD |
9. Marketing & Communications
| 9 | Marketing & Communications | |||
| Requirement ID | Requirement Description | HD-D | Vendor Response | Vendor Notes-Comments |
| 1. Administrator‑Configured (Manual or Scheduled Communications) | ||||
| 9.1.1 | The system shall provide communication‑configuration tools that allow administrators to create, customize, and schedule email messages, SMS notifications, printable notices, reminders, and system alerts. | HD | C | |
| 9.1.2 | The system shall allow administrators to manually trigger or schedule communications for class or membership announcements, cancellations, schedule changes, facility updates, or other program‑related notices. | HD | C | |
| 9.1.3 | The system shall support configurable message templates for confirmations, reminders, cancellations, and other notices, including branding, layout, required disclosures, and language customization. | HD | C | |
| 9.1.4 | The system shall allow administrators to send targeted communications to registrants, waitlisted customers, household contacts, or program supervisors based on user‑defined criteria. | HD | C | |
| 9.1.5 | The system shall allow administrators to configure system alerts and internal notifications, including but not limited to, class registrations, class cancellations, custom questions verification, reservations, uploaded documentation, and denied access. | HD | C | |
| 2. System‑Generated Communications & Notifications (Automated) | ||||
| 9.2.1 | The system should automatically generate and deliver customer communications through email, SMS, dashboard notificationsand printable formats. | D | ||
| 9.2.2 | The system should automatically issue transaction‑based confirmations, including, but not limited to, receipts and permits. | D | ||
| 9.2.3 | The system should automatically send account‑status notifications, including past‑due notices, declined‑draft alerts, outstanding‑balance reminders, and dunning‑sequence messages, according to configured business rules. | D | ||
| 9.2.4 | The system should automatically generate permit‑related notifications, including approval updates, required actions, and changes to reservation details based on module configurations. | D | ||
| 9.2.5 | The system shall automatically notify assigned staff and program supervisors of ADA‑related enrollments, customer cancellations, past‑due balances, unsigned waivers, or other conditions requiring administrative action. | HD | ||
| 9.2.6 | The system shall automatically send class‑related communications, including upcoming‑class reminders, registration confirmations, unique class‑detail reminders, schedule and/ or changes, cancellations, closures, and waitlist‑opening notices, and shall support automated waitlist management at administratively defined intervals. | HD | ||
| 9.2.7 | The system shall automatically send post‑class surveys, evaluations, or follow‑up messages after a class session, program, or reservation concludes. | HD | ||
| 3. Surveys, Feedback & Customer Interaction Tools | ||||
| 9.3.1 | The system should support creation and management of customized surveys linked to activities or passes, including the ability to schedule survey delivery, enforce survey access windows, and collect anonymous or named responses. | D | ||
| 9.3.2 | During reservations or enrollment, the system shall present configurable questions and generate scheduled surveys to be delivered automatically after the reservation occurs. | HD | ||
| 4. Shopping Cart, Customer Workflow & Public‑Facing Portal | ||||
| 9.4.1 | The platform shall include a unified shopping cart with timed item reservation and check out review. | HD | ||
| 9.4.2 | The public web portal shall allow patrons to browse all offerings without logging in, create accounts, retrieve passwords, upload required documents, view eligibility‑filtered activities, and operate within a responsive, compliant, branded design. | HD | ||
| 5. CUI Communications | ||||
| 9.5.1 | The system should support CUI customized communications including such items as alerts, pop‑up notes, account flags, required documentation, bad‑payment indicators, upcoming class reminders, balances, etc. | HD | ||
| 6. Search Tools & AI‑Enhanced Discovery | ||||
| 9.6.1 | The system shall provide robust customer‑facing search tools that allow users to locate programs, facilities, events, and other offerings using keyword search and configurable filters. | HD |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .