9-RFP-9457 Parks Recreation Vendor Response 2026 01 21 Final.xlsx
XLSX spreadsheet 68 KB Posted
- Attached to
- RFP 9457 - Parks & Recreation Application System Evaluation State and local contract opportunity
- Solicitation number
- RFP 9457
- Issued by
- Allegheny County, Pennsylvania
About this file
This is a vendor response form for RFP 9457, a Parks & Recreation Application System evaluation issued by the Allegheny County Parks department in Pennsylvania. The RFP seeks a comprehensive software solution to support parks and recreation operations, including user management, program registration, event management, membership administration, golf course reservations, inventory and point-of-sale (POS) operations, facility reservations, and reporting analytics. The system must accommodate both internal staff and external customers, with requirements spanning mobile accessibility, QR code integration, real-time inventory updates, dynamic pricing capabilities, and multi-facility entitlements. The response form requests detailed vendor information including company establishment year, legal status, annual revenue, customer base, and specific software package details. Technical requirements encompass ADA compliance, security controls, HIPAA compliance, data encryption, multi-factor authentication, workflow management, and integration capabilities with Office 365, JD Edwards, and Microsoft BI or Tableau.
The RFP includes separate pricing worksheets for both Software-as-a-Service (SaaS) and on-premise solutions, requiring vendors to provide costs across five-year terms with breakdowns by user type, modules, support levels, and additional charges such as data storage, transaction fees, and setup costs. Vendors must respond to all tabs within the spreadsheet and provide detailed vendor comments explaining any deviations from stated requirements. Support requirements include service-level agreements, technical specifications, system performance metrics, helpdesk ticketing response times, 24/7 availability options, disaster recovery capabilities, and data restoration procedures. The form mandates that vendors supply three reference examples from similar clients, provide sample contracts and maintenance agreements, and disclose all third-party products or service providers used in the proposed solution.
View the file
Other files for this state and local contract opportunity
| File | Type | Posted |
|---|---|---|
| 7-EEO Requirements Form for IFB and RFP 10-14.docx | DOCX document | |
| 8-Updated DEI Instructions.pdf | ||
| 3-MWDBE Form for IFB and RFP.pdf | ||
| 4-Required Vendor Documentation Form for IFB, RFP and RFQ.pdf | ||
| 6-General Conditions and Instructions Form for IFB and RFP.pdf | ||
| 2-VOSB Form for IFB and RFP.pdf | ||
| 10-RFP-9457 Parks Recreation Application System Evaluation.pdf | ||
| 5-Vendor Internal Sustainability Profile.xlsx | XLSX spreadsheet | |
| 1-MWDBE Utilization Requirements Form for IFB and RFP.pdf |
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Example Business Requirements
| Requirement ID | Category | Core Functional Requirements for <Insert System or Application Name> | |||
| (All of the items also apply to any subcontractors that work on the solution. ) | Priority Level (Determined by the County) | County Notes | Vendor Response | Vendor Comments | |
| Key Contract Criteria | |||||
| Instructions: Criteria listed as "Must have" are expected to be satisfied by the Proposed Vendor Application. If a specific criterion cannot be satisfied as stated, the Vendor is expected to state this in the "Vendor Response" field. The Vendor is invited to explain its response and if it believes it has an alternative that would satisfy the criterion this should be explained in the "Vendor Response" and/or the "Vendor Comment" field. Criteria listed as anything other than "Must have" are not required to be satisfied by the Proposed Vendor Application. The Proposal shall be scored according to overal satisfacion of criteria. The failure to satisfy "Must have" criteria will not in itself eliminate a Proposal from consideration. Rather, the Proposal shall be scored by overall satisfaction of "Must have" and all other criteria. The Vendor is expected to provide the entirety of its Response and/or Comment within this spreadsheet. | |||||
| PL 1 | Plan Review | ||||
| Document Submission | Submit residential plans online | Must have | |||
| Document Submission | Submit commercial plans online | Must have | |||
| Document Submission | Digitally upload commercial plans | Must have | Internal users | ||
| Document Capabilities | PDF fillable version of abstract (only need first page) | Nice to have | Need a custom section for remarks and job specific fixtures | ||
| Document Capabilities | PDF editable version of abstract (only need first page) | Must have | Need a custom section for remarks and job specific fixtures. Limited by user role | ||
| Document Capabilities | Can insert comments and notes on documents | Must have | Ex. Plan drawings, abstract, etc. | ||
| Document Capabilities | Various users can view comments and notes left on documents | Must have | Ex. Plan drawings, abstract, etc. | ||
| Document Capabilities | Ability to view and save changes made to documents | Must have | Ex. Plan drawings, abstract, etc. | ||
| Document Capabilities | Ability for Inspector to review Plan Review documentation during an inspection | Must have | |||
| Document Formatting | Ability to generate letter templates on county letterheads | Nice to have | |||
| Document Manangement | Ability to see previous versions of submitted plan drawings | Must have | Allows examiner to compare documents to see if suggested changes have been made | ||
| Document Management | Ability to track plan reviews that are scheduled | Must have | |||
| Document Management | Ability to upload documents along with plan drawings | Must have | Ex. Provisional letters and other supporting documentation | ||
| Roles & Permissions | Role based permissions for Plan Reviewers | Must have | Ability to review and approve commercial plans | ||
| Roles & Permissions | Role based permissions for supervisiors | Must have | Ability to approve blue card, transmittal permits, and residential plans | ||
| Must have | |||||
| PL 2 | Scheduling | ||||
| Login | External users log in with username and password | Must have | |||
| Profile | Profile section for users | Must have | |||
| Inspection Booking | Ability to create customized inspection booking page for external users | Nice to have | |||
| Inspection Booking | Ability for internal users to schedule an inspection | Must have | |||
| Inspection Booking | Ability for software to automatically assign booked inspections by geographical zone | Must have | |||
| Inspection Booking | Ability for scheduler to indicate that the plumbers are requesting a virtual inspection | Must have | |||
| Internal Dashboard (Admin) | Ability to see what inspectors are in for the day | Must have | |||
| Internal Dashboard (Admin) | Ability for admin to see all inspectors schedules for the day | Must have | |||
| Internal Dashboard (Admin) | Ability to see each inspectors itinerary | Must have | |||
| Internal Dashboard | Ability for inspectors to view their itenerary | Must have | |||
| Internal Dashboard | Ability to see status of inspections | Must have | |||
| Customer | Ability to view the booked inspection confirmation | Must have | |||
| Customer | Ability to view current and previously booked inspections | Nice to have | |||
| Notifications | Ability to send confirmations to the customers to let them know their inspection has been booked and scheduled | Must have | Email, SMS, RoboCalling | ||
| Notificaitons | Ability for inspectors to contact plumbers to let them know they are on their way | Must have | Email, SMS, RoboCalling | ||
| Notifications | Status changes to signify an inspection has been completed | Must have | |||
| Schedule Mangement | Ability to set inspection request cut off time window | Nice to have | |||
| Schedule Mangement | Ability to set a restricted number of available scheduling slots | Must have | |||
| Data | Predictive text addresses from database | Must have | Data/Database refers to Allegheny County Addressing Database, GIS data, possibly Health Department Data | ||
| Route | Ability for software to optimize scheduled inspection route and stops based on efficiency | Must have | Uses County Addressing Database and GIS data | ||
| Route | Ability for software to reroute when inconveniences occur | Nice to have | Uses County Addressing Database and GIS data | ||
| Customer Support | Provide customer support information on Customer Portal for After-Hours issues with the portal. | Must have | |||
| Customer Support | Provide an online link to the platform portal on the ACHD Plumbing site | Nice to have | |||
| Role Based Permissions | Ability to schedule emergency inspections | Must have | |||
| Role Based Permissions | Ability for admin to delegate emergency inspections | Must have | |||
| Role Based Permissions | Ability to prioritize schedule requests | Must have | |||
| Role Based Permissions | Ability to assign various user permissions to certain users | Must have | |||
| Role Based Permissions | Ability to assign premium inspections to inspectors | Must have | |||
| Role Based Permissions | Ability to reassign inspections between inspectors | Must have | |||
| Role Based Permissions | Ability to reschedule inspections when necessary | Nice to have | |||
| Reporting | Ability for software to keep record of all booked and scheduled inspections | Nice to have | |||
| Reporting | Ability for software to keep record of all completed inspections | Must have | |||
| Must have | |||||
| PL 3 | Inspections | ||||
| Ability to search plans | Must have | ||||
| Ability to search county database for the list of municipalities | Must have | ||||
| Ability to search county database for addresses | Must have | ||||
| Ability to search and access stored data from point in the system | Must have | Universal search | |||
| Ability to load inspection types into the system | Must have | ||||
| Ability to load building types into the system | Must have | ||||
| List of current Allegheny county inspectors automatically updates in inspectors dropdown list | Must have | Recognize when a user is marked as deactivated | |||
| Ability to upload the pictures to inspection report | Must have | ||||
| Ability to take notes during an inspection | Must have | ||||
| Ability to edit an address during an inspection | Must have | For Complaints/Emergencies | |||
| Create a complaint that generates a complaint number | Must have | Will integrate with GovQA | |||
| Ability to create an inspection that does not have a plan number | Must have | For Complaints/Emergencies | |||
| Ability to enter violations into an active inspection | Must have | Can record violations details within an active inspection- result of Complaint | |||
| Ability to set reminder intervals to send out response letters | Must have | ||||
| Ability to Direct Unresponded Violations to Legal | Must have | ||||
| Ability to Assess the fee in accordance with penalty matrix | Must have | ||||
| Ability to upload back up documentation for the Penalty Assessed | Must have | ||||
| Penalty Matrix Calculations in systems | Must have | Overide functionality should be limited by role to Chief, Asst, Deputy, Director | |||
| Ability to select an inspector during an inspection | Must have | Person actually performing, not just defaulting to area | |||
| Ability to update plan numbers | Must have | Doing an inspection prior to the plan being file (ie: utility company that needs emergency service) | |||
| Ability search for plans | Nice to have | ||||
| Ability to search a plan number during an inspection | Nice to have | ||||
| Ability to search an inspection by inspector | Nice to have | ||||
| Ability to search inspection by company | Nice to have | ||||
| Ability to search for plans under companies they were filed for | Nice to have | ||||
| Ability to search for plans under master plumber | Nice to have | ||||
| Ability to search for plans using filterable criteria | Nice to have | ||||
| Ability to process payments for premium inspections | Nice to have | Check, MO, credit/debit, cash | |||
| Ability to get signatures at the end of an inspection | Nice to have | ||||
| Ability to email/text an inspection report upon completion of an inspection | Nice to have | Should be auto generated | |||
| Auto population of plan information fields where data is available | Must have | ||||
| Predictive text with addresses | Nice to have | ||||
| Ability to timestamp inspections | Nice to have | Backend timestamp of when inspections where initiated and submitted | |||
| Ability to search HPIDs | Must have | ||||
| Offline application functionality | Must have | In app saving when the user is offline, when user gets online then app will submit | |||
| Abiltiy to Attach Approved or Denied Variance Requests to specific plans | Must have | ||||
| Must have | |||||
| PL 4 | Permits | ||||
| Ability for internal users (Health Department) to enter new plans into the system | Must have | Residential Plans, Commercial Plans, Transmital Permits, and Blue Card Permit details | |||
| Ability for external users (Non-Health Department) to submit new plans into the system | Must have | Residential Plans, Commercial Plans, Transmital Permits, and Blue Card Permit details | |||
| Ability to search existing plans in the system | Must have | Residential Plans, Commercial Plans, Transmital Permits, and Blue Card Permit details | |||
| Ability for external users to purchase (submit payments for) plans online | Must have | Residential Plans and Commercial Plans | |||
| Ability for external users to submit plans online | Must have | Residential Plans and Commercial Plans | |||
| Predictive text for address fields | Nice to have | ||||
| Address verification | Must have | This will be verified against the county real estate data | |||
| Must have | |||||
| Must have | |||||
| PL 5 | |||||
| Must have | |||||
| Must have | |||||
| Must have | |||||
| Must have | |||||
| Must have | |||||
| Must have | |||||
| Must have | |||||
| Must have | |||||
| Must have |
| Must have |
| Must have |
| Must have |
| Must have |
| Must have |
| Must have |
| Must have |
| Nice to have |
| Nice to have |
| Must have |
| Must have |
| Must have |
| Must have |
| Must have |
| Must have |
| Must have |
| Nice to have |
| Must have |
| Must have |
| Must have |
| Nice to have |
| Must have |
| Must have |
| Nice to have |
Vendor Information
| Vendor(s) Information | Vendor (Software) Comments/Response | |
| # | Requirement Description | |
| V1 | Enter full legal name of company(ies) responding to this RFP. | |
| V2 | Enter the year company was established. | |
| V3 | Enter the head office location and applicable contact address(es). | |
| V4 | Indicate the company's legal status and ownership (corporation, private owners, publicly traded, etc.). | |
| V5 | Enter number of people currently employed by the responding company(ies). | |
| V6 | Enter number of employees dedicated to customer support. | |
| V7 | Enter number of employees dedicated to product development. | |
| V8 | Enter the responding companies' annual revenue ($M) for 2020, 2021, 2022 and estimated revenues for 2023. | |
| V9 | Enter total number of customers supported with the proposed solution by the responding company(ies). How many county/municipal clients does your organization support? | |
| V10 | Identify the specific software package(s) being proposed and which version is being proposed. | |
| V11 | List the % of revenue the application(s) represent to your organization and how long the company has been selling and supporting this software package. | |
| V12 | How many installations of the proposed version of the Application have been implemented in the USA? How long has this product/version been available? | |
| V13 | List all software, support and services to be provided by the responding company. Disclose all vendors, partners and third party products or service providers, whenever applicable. | |
| V14 | Describe your Warranty policies, including the term of coverage and any rules or restrictions on standard package components and/or customized components. | |
| V15 | Describe your Warranty Period. | |
| V16 | Please forward a copy of your license agreement. | |
| V17 | Provide three examples of clients with similar needs where you have implemented this software. Include their industry, a brief description of products and services provided, and estimated product mix (standard vs. customization/add-on). | |
| V18 | Provide contact information for the three reference examples listed above. | |
| V19 | Provide any market certifications your product has been awarded in the last three years. | |
| V20 | Provide up to three examples of clients with similar needs where you have implemented this software in local government. Include their industry, a brief description of the modules purchased and implemented. Attach any relevant case studies. | |
| V21 | Provide contact information for the three reference examples listed above. | |
| V22 | Provide a sample contract/maintenance agreement. | |
| *Please fill out all the tabs* |
Support
| Non-Functional: Support | ||||
| # | Requirement Description | Priority | Vendor Response | Vendor Response / Comments |
| Support | ||||
| S1 | Attach a sample standard service-level agreement (SLA) to this proposal. | |||
| S2 | Attach technical specifications (browser, network, and operating system requirements) to this proposal. | |||
| S3 | Attach information regarding system performance metrics, including uptime, capacity, and response time. | |||
| S4 | Attach any supplementary information and service levels provided by relevant partners (hosting, customer service, support, etc.). | |||
| S5 | Do you provide on-site support services and remote support services? Disclose standard rates for this service, if any. | |||
| S6 | Detail your helpdesk ticketing response times and methods of communication e.g. telephone, email, web-based console, and remote desktop? Specify types and days/hours each is available. | |||
| S7 | How do you classify the priority or severity level of an incident? | |||
| S8 | Do you provide 24/7 support? If not, what are the support hours EST? | |||
| S9 | Describe standard issue resolution response times, methods of communication, and escalation and severity levels. | |||
| S10 | What is the frequency of your product enhancements, patches, and releases? Please describe your (version-upgrade) release schedule. | |||
| S11 | Please describe your internal regression testing methodology, data pool and scenarios update and maintenance based on various client business cases prior to release of new product enhancement, patches and releases. | |||
| S12 | Do you provide ability to test enhancement, patches, and releases before the upgrade release? | |||
| S13 | How do you notify your clients of upcoming enhancements or maintenance activities? | |||
| S14 | How will enhancements, patches, releases, etc. be tested? Is the customer expected to test for impact on customizations? | |||
| S15 | Do you provide onsite support for application of patches/upgrades? If not included in SLA, disclose the standard rates for these services. | |||
| S16 | Do you provide phone support for application of patches/upgrades? If not included in SLA, disclose the standard rates. | |||
| S17 | Do you provide access to a knowledgebase of information and best practices; access to user groups, forums, or communities? | |||
| S18 | Do you have the ability to create knowledgebase of information and practices, specific to customer needs and practices? | |||
| S19 | Do you provide ongoing product training and tutorials? Describe the various offerings. | |||
| S20 | Do you provide disaster recovery capabilities and regular data replication? Attach relevant recovery time objectives and recovery point objectives. | |||
| S21 | Do you provide SLA terms for data restoration services? | |||
| S22 | Do you provide the business continuity strategy for the software and hosting provider? | |||
| S23 | If on premise solution, describe the process for pushing patches/upgrades to the software. | |||
| S24 | Describe how users can self-serve to get the most out of your solution (e.g. tutorials, tests, built-in guides, help documentation)? | |||
| S25 | Describe how minor errors can be troubleshot by an Administrative user. | |||
| S26 | Describe how an error will be resolved if it cannot be addressed by the Administrative user. | |||
| S27 | Describe how you would provide support to non-County users. | |||
| S28 | Do you provide any type of user training for your system? Online, Hard Copy etc. | |||
| *Please fill out all the tabs* |
Business Requirements
| Requirement ID | Core Functional Requirements for <Insert System or Application Name> | |||
| (All of the items apply to any subcontractors that work on the solution. ) | Priority Level (determined by the County) | County Notes | Vendor Response | Vendor Comments |
| Key Contract Criteria | ||||
| Instructions: Criteria listed as "Must have" are expected to be satisfied by the Proposed Vendor Application. If a specific criterion cannot be satisfied as stated, the Vendor is expected to state this in the "Vendor Response" field. The Vendor is invited to explain its response and if it believes it has an alternative that would satisfy the criterion this should be explained in the "Vendor Response" and/or the "Vendor Comment" field. Criteria listed as anything other than "Must have" are not required to be satisfied by the Proposed Vendor Application. The Proposal shall be scored according to overall satisfaction of criteria. The failure to satisfy "Must have" criteria will not in itself eliminate a Proposal from consideration. Rather, the Proposal shall be scored by overall satisfaction of "Must have" and all other criteria. The Vendor is expected to provide the entirety of its Response and/or Comment within this spreadsheet. | ||||
| 1 | User Management | |||
| 1.1 | Users must be able to create accounts with personal details, including name, address, phone number, email, and date of birth. | Must have | ||
| 1.2 | The system must support the creation of main user accounts with the ability to subsidiary user accounts | Must have | ||
| 1,3 | The system must provide a user dashboard showing reservations, memberships, enrollments, and payments; support household/family linking. | Must Have | ||
| 1.4 | The system must support traditional login methods (username and password) | Must have | ||
| 1.5 | The system must support social authentication, including logins using familiar credentials (e.g., Google, Apple, Facebook, LinkedIn). | Must Have | ||
| 2 | Program Management | |||
| 2.1 | The system must allow users to register for various programs online, including filtering by type, location, date, and age group. | Must have | ||
| 2.2 | The system must seamlessly integrate with third-party vendors for program registration. | Must have | ||
| 2.3 | The system must allow the copying of existing programs for new sessions or seasons. | Must have | ||
| 2.4 | The system must provide detailed descriptions and links to third-party sites for programs managed externally. | Must have | ||
| 2.5 | The system must have an intuitive and user-friendly interface for program registration, both for internal staff and external users. | Must have | ||
| 2.6 | The system must support configurable email notifications and QR code generation for admission/registration | Must have | ||
| 3 | Event Management | |||
| 3.1 | The system must allow for the creation/copying of events with details (location, dates/times, fees, waivers), enrollment limits, QR code issuance, and email notifications. | Must Have | ||
| 3.2 | The system must allow users to register for various events online, including filtering by type, location, date, and age group. | Must have | ||
| 3.3 | The system must flag scheduling conflicts with existing reservations. | Must Have | ||
| 3.4 | The system must support mobile check-in with QR code scanning on both smartphones and tablets, and update attendance in real time | Must Have | ||
| 4 | Membership Management | |||
| 4.1 | The system must allow users to purchase memberships online for various activities (e.g., pool passes, golf, ice skating). | Must have | ||
| 4.2 | The system must support different membership types and categories. | Must have | ||
| 4.3 | The system must support configurable pass rules, including: |
- Facility/amenity access control (e.g., pool vs. ice rink).
- Time‑of‑day/day‑of‑week restrictions (e.g., senior/bulk passes valid weekdays only).
| - Multi‑facility entitlements (e.g., Volunteer Fire Department pass valid at ski, ice rink, and pool). | Must Have | ||
| 5 | Golf Course Management | ||
| 5.1 | The system must support online/in-person tee time reservations with course/date/time/players and payment. | Must Have | |
| 5.2 | The system must provide options dynamic pricing rules based on demand/time; show real-time pricing. | Must Have | |
| 5.3 | The system must allow for course blocking for maintenance/events. | Must Have | |
| 6 | Inventory and POS Management | ||
| 6.1 | The system provide Real-time inventory updates. | Must have | |
| 6.2 | The system must allow for POS menu item management. | Must have | |
| 6.3 | The system must provide simple, easy‑to‑use POS menu layout editing for staff (e.g., add/move items and categories without technical assistance). | Must have | |
| 6.4 | The system must allow for the configuration automatic reorder points and alerting. | Must Have | |
| 6.5 | The system must support physical inventory reconciliation (e.g., scanning cases) with real‑time sync to POS. | Must Have | |
| 7 | Facility Resevations | ||
| 7.1 | The system must provide centralized reservation booking for shelters/buildings/venues, including availability search, date/time selection, fees, waivers, and cancellation rules. | Must Have | |
| 7.2 | The system must display photos and facility details to public users during booking. | Must Have | |
| 8 | Facility Media | ||
| 8.1 | The vendor shall provide, upload, and maintain multiple photos for each facility (e.g., shelters, buildings, and other park amenities) within the application. | Must Have | |
| 9 | Reporting & Analytics | ||
| 9.1 | The systems must allow for the creation of custom and automated admin reports with data visualization. | Must have | |
| 9.2 | The system must support integration with reporting applications and tools (e.g., JD Edwards). | Must have | |
| 10 | Vendor Support | ||
| 10.1 | The vendor must provide reliable vendor support and timely updates. | Must have | |
| 10.2 | The vendor must provide clear Service Level Agreements (SLAs). | Must have | |
| 11 | Payment Methods | ||
| 11.1 | The system must support Apple Pay, Google Pay, debit/credit across programs, events, reservations, POS/retail, and golf transactions. | Must Have | |
| 12 | Event Check-in | ||
| 12.1 | The system must support mobile check-in with QR code scanning on smartphones and tablets, and update attendance in real time for events, programs, and memberships | Must Have | |
| 13 | Hardware | ||
| 13.1 | The vendor must supply, and support required devices (card readers, mobile POS) to enable mobile operations and onsite sales. | Should Have |
Technical Requirements
| Additional | |||||||
| # | Requirement Description | County's Priority | Vendor Response | Vendor Detailed Response | Detailed Instructions | ||
| General Technical | |||||||
| TR1 | Ability to integrate with the following (including but not limited to): | - All Vendors are required to respond to the following tabs. Use the drop-down menus provided and enter free form comments to either respond to requirements or elaborate on drop-down responses. | |||||
| TR2 | - Office 365 (Word, Excel, and Outlook/Exchange) | Could Have | |||||
| TR3 | - JD Edwards | Could Have | - Answer all questions in these sections using the following scale: | ||||
| TR4 | - Microsoft BI or Tableau (BI Tool integration) | Could Have | |||||
| TR5 | Describe in detail how Single Sign On (SSO) process works and is configured (Allegheny County Preferrence is Entra ID) | Must Have | Vendor Responses | Definition | |||
| TR6 | Ability to monitor the Identity Provider (customer) metadata URL for automated certificate rollover and other changes | Must Have | |||||
| TR7 | Ability to support API, Web-service and file-based integrations | Must Have | Yes with Significant Configuration | - Requirement will be delivered through significant configuration of the solution. | |||
| TR8 | a | Must Have | - The County recognizes that the solution will have to be configured. We anticipate that the configuration needs will be reflected in the implementation pricing. That is considered 'Yes out of the box' | ||||
| TR9 | Ability to support cross platform functionality (mobile and desktop access) | Must Have | - Configuration is considered significant if the out of the box functionality is impacted or other functions/featured are rendered unusable and adds significant time/cost to the implementation. | ||||
| TR10 | Describe the architecture used for mobile access | Must Have | Yes with add on | - Requirement will be supported by a 3rd party application. | |||
| TR11 | On-Premise Solutions: | - Identify vendor and name of add on, and if it is utilized by existing clients. | |||||
| TR12 | - ability to support VM Ware | Should Have | - If the add-on is not included in the pricing, then the response should be 'Not Supported' | ||||
| TR13 | - Ability to run on Microsoft-based servers / databases | Must Have | Yes with customization | - Requirement is available but requires a customization of the software. | |||
| TR14 | - Provide solution architecture design including governance, application modules, database, integration and security layers | Not supported | - Requirement is not met by proposed solution. | ||||
| TR15 | - Provide system requirements and options for on premise solutions (i.e. client, servers, network, database…etc) | ||||||
| TR16 | Is your proposed solution a fully hosted Software as a Service (SaaS) offering | Notes: | |||||
| TR17 | Identify the options for hosting - private government cloud, public cloud, hybrid cloud etc. | 1. Requirements requesting Vendor to describe, explain or identify capabilities do not require the above responses; completion of the comments field is sufficient. If answer provided under separate cover, be sure to reference the doucment in the comments field. | |||||
| Does the system have a mechanism for promoting changes from the test environment to production? | 2. The support tab vendor response is entirely describes/explains etc. Vendor is to provide response in comments column, or reference to separate cover information. | ||||||
| User Interface | |||||||
| TR18 | Ability to support ADA/ compliance rules (e.g. accessibility, speech to text, screen reader etc.) | Must Have | |||||
| TR19 | Easy-to-use user interface (GUI) (i.e. support multiple standard browsers on multiple OS (explorer, edge, chrome...etc)) | Must Have | |||||
| TR20 | If solution is browser based, identify supported browsers. Also indicate any that are NOT supported. | Should Have | |||||
| TR21 | Consistent look & feel throughout the application | Must Have | |||||
| TR22 | Command keys consistent from module to module | Must Have | |||||
| TR23 | Uses standard MS Windows conventions (toolbars, menus, pick-lists, etc) | Should Have | |||||
| TR24 | Context sensitive menus (e.g. right click mouse) | Should Have | |||||
| TR25 | Conforms to standard Windows navigation conventions (e.g. Tab, Shift Tab) | Must Have | |||||
| TR26 | Copy and paste / drag and drop within application or from application to other Windows based programs | Should Have | |||||
| TR27 | Ability to apply data field masking on some pages or all pages a field is displayed | Should Have | |||||
| TR28 | User can navigate through entire screens that are data entry intensive without the aid of a mouse | Should Have | |||||
| TR29 | In addition to the standard data fields, system provides user-defined fields for the capture of unique data. (configurable?) | Must Have | |||||
| TR30 | - identify any limitation in terms of supported data types (alpha, numeric, character, etc.) | ||||||
| TR31 | Customizable / personalizable fields and screens set by user type, hierarchy, etc. | Should Have | |||||
| TR32 | Support of mobile devices / Responsive Design | Must Have | |||||
| TR33 | Does the mobile device use a browser, or is the solution actually available as an 'app' | ||||||
| TR34 | If mobile provides an app, what OS are supported? | ||||||
| TR35 | Available built-in training/help documentation and user tools | Should Have | |||||
| Security & Access Control | |||||||
| TR36 | Ability to support HIPAA compliance | Must Have | |||||
| TR37 | Ability to meet US data residency requirements | Must Have | |||||
| TR38 | Ability of the system to provide security controls (insert, update, delete, view) at the: | ||||||
| TR39 | - Application level | Must Have | |||||
| TR40 | - Function level | Must Have | |||||
| TR41 | - Form/Page level | Should Have | |||||
| TR42 | - Field level | Should Have | |||||
| TR43 | - Subsets of data in database | Should Have | |||||
| TR44 | Ability to encrypt data at rest (in the database) | Must Have | |||||
| TR45 | Ability to encrypt data in transit | Must Have | |||||
| TR46 | Ability to use Multi- factor authentication | Must Have | |||||
| TR47 | Ability to provide an audit trail of all transactions addition/deletion/change, including date, time, and user ID | Must Have | |||||
| TR48 | Ability to provision, change, delete, or deactivate user profiles based on predefined scripts or effective date | Should Have | |||||
| TR49 | - Describe the process | ||||||
| TR50 | Ability to configure and manage regular system maintenance (Security Patching) | Must Have | |||||
| TR51 | Ability to enforce strong password requirements (alpha, number, special characters, length etc.) | Must Have | |||||
| TR52 | Ability to support Security Reporting - summary and detail at the: | ||||||
| TR53 | - Roles level | Should Have | |||||
| TR54 | - Individual profile level | Should Have | |||||
| TR55 | - Security control level | Should Have | |||||
| TR56 | Ability to support Audit Reporting - summary and detail at the: | ||||||
| TR57 | - all object transaction levels | Should Have | |||||
| TR58 | - all data transaction levels | Should Have | |||||
| TR59 | provide the documented security standards for the solution | ||||||
| TR60 | for cloud solutions, provide details of any certifications held by the cloud being proposed to run the application. | ||||||
| Data | |||||||
| TR61 | Describe how data is restored | ||||||
| TR62 | Describe the data archiving capabilities | ||||||
| TR63 | Are there any limitations to number of years data can be retained in archive? | ||||||
| TR64 | Is system data stored in systems other than databases (files, LDAP, etc.)? if yes list other. | ||||||
| TR65 | Describe the process for deleting data on request or termination of service | ||||||
| TR66 | Describe the process and format for delivering data if services are terminated (including reports & custom code) | ||||||
| TR67 | Is data returned in a machine readable format? | ||||||
| TR68 | Describe how the system is validated by external auditors for compliance | ||||||
| TR69 | Describe how historical data will be stored and accessed | ||||||
| TR70 | Test Environments | ||||||
| TR71 | - Ability to have a Test/Development environment available for user testing and development | Must Have | |||||
| TR72 | - Describe the process delivered for data deidentifying or anonymization while creating test data | ||||||
| TR73 | - Describe the process for updating/refreshing the Test/Development environments. | ||||||
| TR74 | What language(s) is used to code all applications being proposed? What tools are available to users in your development workbench (e.g. user sandbox)? | ||||||
| Test system data must be able to be refreshed from production periodically. | |||||||
| a. | Describe the process for accomplishing this. | ||||||
| b. | Are there any limitations on how frequently this can be accomplished? | Should Have | |||||
| Workflow | |||||||
| TR75 | Ability to manage workflow, including electronic approval, integrated throughout the application. | Should Have | |||||
| TR76 | Ability for users to define electronic workflow processes. | Must Have | |||||
| TR77 | Ability to easily set up business rules in workflow facility. | Must Have | |||||
| TR78 | Ability to route document approvals through workflow functionality. | Must Have | |||||
| TR79 | Ability to route transactions through a workflow process. | Must Have | |||||
| TR80 | Ability for users to select and define the flow of transactions based upon rules, roles and routings of documents. | Must Have | |||||
| TR81 | Ability of workflow routing to recognize role versus individuals. | Must Have | |||||
| TR82 | Ability to support multiple-path routing in workflow. | Must Have | |||||
| TR83 | Ability to track workflow step execution history. | Should Have | |||||
| TR84 | Ability to notify users via email if they have new workflow steps pending. | Must Have | |||||
| TR85 | Ability to Define workflow with multiple optional approvers (i.e. any team member approval) based on a defined security role. | Should Have | |||||
| TR86 | Ability to have workflow queues for multiple distinct approval transactions | Should Have | |||||
| TR87 | Ability to attach documents to workflow steps for on-line review and approval. | Must Have | |||||
| TR88 | Ability for users to assign delegates | Should Have | |||||
| TR89 | Ability to view workflow history (audit history) | Must Have | |||||
| TR90 | Ability for the workflow to integrate with MS Office Calendars | Could Have | |||||
| TR91 | Ability to set reminder/notifications | Should Have | |||||
| TR92 | Ability to modify in-flight workflows (e.g. change from urgent to normal) | Should Have | |||||
| TR93 | Ability to capture comments/notes on workflow steps | Should Have | |||||
| TR94 | Ability to set effective date on workflow (both, from and to) | Should Have | |||||
| Reporting | |||||||
| TR95 | Ability to select from pre-defined, scheduled, automatically compiled and distributed reports (PDF, Excel, Word, etc.) | Must Have | |||||
| TR96 | Ability to modify 'canned' reports provided with system | Must Have | |||||
| TR97 | Ability to save reports and reprint at later date | Must Have | |||||
| TR98 | Ability of user creating report/query to make public for other users to use | Should Have | |||||
| TR99 | Ability to support customizable user reporting dashboards | Must Have | |||||
| TR100 | Ability for configurable, user-friendly ad hoc report building tools (e.g. users can create queries and multiple views of data) | Should Have | |||||
| TR101 | Ability to support customizable reporting templates | Must Have | |||||
| TR102 | Ability to schedule reports for distribution to pre-defined groups/users on a periodic basis | Should Have | |||||
| TR103 | Ability to drill-down functionality within reports generated by the system | Must Have | |||||
| TR104 | Ability to provide Real time and point-in-time access to data | Must Have | |||||
| TR105 | Ability to search reports generated in the system | Should Have | |||||
| TR106 | Ability to generate system usage reporting by module or Functional group, role, etc. | Should Have | |||||
| Artificial Intelligence | |||||||
| TR107 | Are you using GenAI in your solution? | Should Have | |||||
| TR108 | Is it a closed environment, where the customer data is not used to train the model that then | ||||||
| becomes available to other customers? | Should Have | ||||||
| TR109 | Where do you get the data that your model is trained on? | Should Have | |||||
| TR110 | How long do you retain the data and does your model consume new client provided data to further | ||||||
| train the model? | Should Have | ||||||
| TR111 | Have you done a security assessment of your model and run any GenAI solution through a code | ||||||
| review? | Should Have | ||||||
| TR112 | Do you have ongoing security monitoring in place to detect viruses or anomalies? | Should Have | |||||
| TR113 | How often do you reassess the model for data accuracy and model methodology? | Should Have | |||||
| TR114 | What is the computing cost as well as other underlying costs, including access and egress, and is it | ||||||
| monthly, yearly or transactional? | Should Have |
*Please fill out all the tabs*
SaaS Costing
| \ | |
| SaaS Pricing Worksheet |
Instructions: Vendors are to provide estimated costs using this pricing worksheet. The estimated user counts are included in RFP Section ## Users have been identified by function to differentiate pricing (rows 12-18) if different from a full access user (row 10). Please include additional comments to further qualify the response (column L). Include all one time costss in the Year 1 column (Column 'J'). Support Charges and Other Charges should be listed in the year they would be incurred (Column J, K etc.). Vendors must include all costs associated with their proposed solution.
| Cost Line item | Qty | Monthly Per User License/Subscription Fees | Annual License/Subscription Fees | Total 5 year | ||||||||||
| (calculation) | Vendor Comments | |||||||||||||
| 1 year term | 2 year term | 3 year term | 4 year term | 5 year term | 1 year term | 2 year term | 3 year term | 4 year term | 5 year term |
| License / Subscription Charges | Users | Indicate pricing by user type where applicable, and any volume discounts or bundles. | ||||||||||||
| Software Licenses / Subscription | - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | ||
| User license/subscription by Module (if different pricing): | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Module 1 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Module 2 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Module 3 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Module 4 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Module 5 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Module 6 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Module 7 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Administrator License | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Contractor License | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Self Service License | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Other Licenses (please specify) | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Other Licenses (please specify) | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Other Licenses (please specify) | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Total Licenses Cost | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 |
| Vendor Support Charges | Unit | |||||||||||
| Support Fees | - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 |
| Support Level (please specify) | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |
| Support Level (please specify) | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |
| Support Level (please specify) | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |
| Total Support | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 |
| Other Charges | Unit | ||||||||||||
| Data and File Storage Costs | - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | indicate storage maximum and cost for additional storage if any |
| Transaction Processing Fees | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | indicate transaction charge if any | |
| Test/Dev Environment(s), if extra | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | indicate additional costs for sandbox environment | |
| Activation/Setup Fees | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | activation only, not requesting implementation estimates | |
| Other (please specify) | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | ||
| Other (please specify) | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | ||
| Total Other Charges | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 |
| Total Costs | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |
| *Please fill out all the tabs* |
On Premise Costing On Premise Pricing Worksheet
Instructions: Vendors are to provide estimated costs using this pricing worksheet. The estimated user counts are included in RFP Section ##. Users have been identified by functional area to differentiate pricing (rows 12-18) if different from a full access user (row 10). Please include additional comments to further qualify the response (column L). Any one time costs to be placed in the Year 1 Licensing column . Please include Hardware charges only if providing is part of the proposal. For support, other related charges, please use the Year column in which they will be incurred. Vendors must include all costs associated with their proposed solution.
| Cost Line item | Qty | Year 1 Costs | Annual License AND/OR Maintenance Fee | Total 5 year | |||||||
| (calculation) | Vendor Comments | ||||||||||
| Licensing | Maintenance | year 1 | year 2 | year 3 | year 4 | year 5 |
| License Charges | Users | Indicate pricing by user type where applicable, and any volume discounts or bundles. | |||||||||
| Software Licenses | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| User license by Module (if different pricing): | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||||
| Module 1 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Module 2 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Module 3 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Module 4 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Module 5 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Module 6 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Module 7 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Administrator License | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Contractor License | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Self Service License | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Database License | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Other Licenses (please specify) | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Other Licenses (please specify) | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| One time costs (pleaes specify) | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| One time costs (pleaes specify) | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | |||
| Total Licenses Cost | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 |
| Cost Line item | Qty | Support & Other Charges | Total 5 year | ||||||
| (calculation) | Vendor Comments | ||||||||
| year 1 | year 2 | year 3 | year 4 | year 5 |
| Support Charges | Unit | |||||||||
| Support Fees | - 0 | Do not use | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | indicate support service level and service (attach documentation) | |
| Support Level (please specify) | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | ||||
| Support Level (please specify) | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | ||||
| Support Level (please specify) | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | ||||
| Total Support | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 |
| Other Charges | Unit | |||||||||
| Data and File Storage Costs | - 0 | Do not use | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | indicate storage maximum and cost for additional storage if any | |
| Transaction Processing Fees | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | indicate transaction charge if any | |||
| Test/Dev Environment(s), if extra | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | indicate additional costs for sandbox environment | |||
| Interface/Integration Tools | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | indicate any additional costs for integration tools | |||
| Activation/Setup Fees | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | activation only, not requesting implementation estimates | |||
| Other (please specify) | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | ||||
| Other (please specify) | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | ||||
| Total Other Charges | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | ||||
| Total Costs | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | $ - 0 | ||||
| *Please fill out all the tabs* |
Index
| Core Capability | Yes out of the box |
| Configurable by Vendor | Yes with Significant Configuration |
| Requires Customization | Yes with add on |
| Provided in Conjunction with a 3rd Party | Yes with customization |
| Not Applicable | Not supported |
Data Validation
| Core Capability | |
| Configurable by Vendor | |
| Configurable by City Staff | |
| Requires Customization | |
| Not Applicable | |
| Must Have | |
| Should Have | |
| Could Have |
File details come from the government source that posted it. Updated .