HomeMy WebLinkAbout26 - Instructions - Bozeman Utility Billing Software Services & Implementatiion RFP (9)
/
Request for Proposals (RFP)
Utility Billing (UB) Software and Implementation Services
***Section V. Word Attachments***
City of Bozeman
Bozeman, MT
City of Bozeman
PO Box 1230
Bozeman, MT 59771-1230
CLOSING DATE: May 4th, 2026 at 3:00 PM MT
ATTACHMENTS
RESPONDENT INFORMATION
Attachment 1.1 – Signature Page
Each Firm shall complete the Signature Page.
I acknowledge that I have read and understand the RFP documents.
I hereby certify that the information submitted by the Firm in response to this RFP, including pricing and other information, is true and accurate.
I hereby certify that the Firm is independent of the City of Bozeman and is unaware of any potential conflicts of interest if it were selected to perform the requested work.
I hereby certify that I am authorized to bind the Firm in a contract.
The undersigned Firm having examined this RFP and having full knowledge of the condition under which the work described herein must be performed, hereby proposes that the Respondent
will fulfill the obligations contained herein in accordance with all instructions, terms, conditions, and scope of requested services set forth; and that the Respondent will furnish
all required products/services and pay all incidental costs in strict conformity with these documents, for the stated prices as proposed.
Submitting Firm:
Click to enter text.Primary Firm☐
Address:Click to enter text.City:
Click to enter text.State:
Click to enter text.Zip:Click to enter text.SAM.gov UEI Number:Click to enter text.Authorized Representative:Click to enter text.Title:Click to enter text.Click to enter
date.SignatureDate
Primary Contact for Firm
Name:Click to enter text.Title:Click to enter text.
Email:Click to enter text.Phone:Click to enter text.
Attachment 1.2 – Nondiscrimination and Equal Pay Affirmation
Each Firm hereby affirms it will not discriminate on the basis of race, color, religion, creed, sex, age, marital status, national origin, or because of actual or perceived sexual orientation,
gender identity or disability and acknowledges and understands the eventual contract will contain a provision prohibiting discrimination as described above and this prohibition on discrimination
shall apply to the hiring and treatments or proposer’s employees and to all subcontracts.
The Respondent hereby affirms it will abide by the Equal Pay Act of 1963 and Section 39-3-104, MCA (the Montana Equal Pay Act).
Click to enter date.Signature of Respondent’s Authorized OfficialDate
Click to enter text.Click to enter text.Name of Person Signing (Print)Title of Person Signing (Print)
Attachment 1.3 – Respondent Statement
By submitting a response, the Respondent acknowledges that all Firms associated with the Respondent have acquainted themselves with the terms, scope, and requirements of the project
based on the information contained in this RFP and any addendums. Any failure by the Respondent to acquaint themselves with available information will not relieve them from the responsibility
for estimating properly the difficulty or cost of successfully performing the work available. The City is not responsible for any conclusions or interpretations made by the Respondent
on the basis of the information made available by the City.
Proposals that do not acknowledge addendums may be rejected.
The following addendums are acknowledged by the Respondent and reflected in our response.
Addendum
Initials
Click or tap here to enter text.Click or tap here to enter text.Authorized Agent NameTitle
Click to enter a date.Authorized Agent SignatureDate
Attachment 1.4 – Software Background
Complete one form for each software provider included in the proposal.
Product Information
Software product name (commercial name):
Legal owner/licensor of software (if different):
Software History
Date of first commercial release:
Current major version number:
Year current core architecture was introduced:
Frequency of major releases: (e.g., annual, quarterly)
Identify any predecessor products or re‑platforming events:
Current Version
Top five (5) functional enhancements introduced in the current version:
1
2
3
4
5
Key functional, architectural, or platform changes over the last three (3) years that materially impact customers:
1
2
3
4
5
Identify the most significant functional or technical limitation of the current software relevant to this RFP or experienced by similar clients:
Third-Party Products
List any third-party products embedded in the software: (Product name, purpose, can be removed or substituted?)
Third-party products recommended but not embedded: (Product name, purpose, required/optional, additional costs)
Attachment 1.5 – Professional Services Background
Complete one form for each Firm responsible for implementation delivery included in the proposal.
Respondent Background
☐ Primary FirmLegal company name:
Corporate headquarters location:
Offices supporting Utility Billing delivery (by region):
Estimated percent of Utility Billing delivery resources located in North America / offshore:
Firm HistoryYear Firm established (under current legal structure):
Previous Firm names, mergers, or acquisitions in last 10 years:
Previous names and successor Firms:
Current and Recent Projects
List up to five (5) current or recent projects that provided relevant experience:
1
2
3
4
5
Firm’s primary target market for Utility Billing implementation services (e.g., industry, organization size, complexity):
Describe how this project aligns with that target market:
Identify three (3) key lessons learned from recent Utility Billing implementations and describe how each will be specifically applied to this project:
1
2
3
Size
Number of Utility Billing implementation projects completed in the past five (5) years:
Number of Utility Billing implementations currently in progress:
Consulting Team
Total size of Utility Billing consulting practice: (exclude non-Utility Billing consultants)
Average annual attrition rate (# of leaves / average # of employees) of Utility Billing consultants:
Proposed project team size:
Average Utility Billing implementation experience of proposed team members:
Average tenure with Firm for proposed consulting team:
Attachment 1.6 – Reference Form
Please provide at least three (3) references for past projects that include products and services similar to those proposed for this RFP and of comparable organizations. Each firm should
provide one set of references. Please provide at least one reference based in Montana if possible.
NOTE: Responses stating that references will be provided at a later time shall be deemed non-responsive.
Firm Name: Click or tap here to enter text.
References ☐ Primary FirmName of product:
Name of client:
Client’s employee count:
Client’s annual operating budget:
Contact name:
Contact title:
Contact email:
Contact phone:
Project Scope (check boxes for which implementation was conducted)
☐Customer Account Management☐
Property/Service Location Management☐GIS/Parcel Integration☐AMI/AMR Integration☐Read Exception Management☐Mid‑Cycle Meter Replacements☐Rate Engine Configuration☐Tiered/Seasonal
Rates☐Wastewater Formulas / Caps☐Stormwater ERU Billing☐Solid Waste Service Billing
☐Cycle / Off‑Cycle / Finals☐
Consolidated Multi‑Service Bill☐Customer Portal☐Customer Service Request Intake☐Work Order Creation/Dispatch☐Meter Inventory☐Special AssessmentsDeployment☐
On-premise
☐Private Cloud
☐SaaSImplementation duration:Planned Go-Live Date:Actual Go-Live Date:Describe Roll on Project:Project Challenges:
Major Accomplishments:
FUNCTIONAL REQUIREMENTS
Attachment 2.1 – Functional Requirements
(See Excel Attachment V.2.1– Functional Requirements)
The Functional Requirements describe the software scope of the overall project and the requirements for each functional area. Responses to the Functional Requirements shall identify
the scope of system configuration that will be accepted by the City as part of the project.
The Functional Requirements are a material component of the proposal evaluation and will allow the City to determine if a Respondent can adequately support the City in meeting its project
goals identified in II.4.0. Respondents should accurately reflect the ability of the proposed solution to meet a specific requirement. The inability to provide some requirements or
excluding some requirements from scope may affect scoring but will NOT eliminate the Respondent from contention. However, failure to accurately portray a software’s capability may result
in disqualification. If Respondents are unsure or unclear on the description of a specific requirement, please send a question or request for clarification by the deadline noted in
I.4.0. The requirements responses submitted will become part of the agreement.
For the avoidance of doubt, all affirmative responses to the Functional Requirements shall be designed, configured, and implemented unless a satisfactory workaround or other mutually
agreed solution is determined, or if any requirements are descoped by mutual consent. Failure to do so may result in the City seeking remedial action.
Respondents should indicate their responses to the City’s functional requirements. The Instructions tab on the spreadsheet provides guidance on completing the attachment.
TECHNOLOGY AND SYSTEM CAPABILITIES
Attachment 3.1 – Reporting
(See Excel Attachment V.3.1 - Reporting)
The City has identified critical reports important to the organization. This represents the reports currently run by the City, and the City acknowledges that not all these reports may
be needed, required, or available in a new system. For each report identified in Attachment 3.1, Respondents shall indicate whether the report or information provided in the report
can be provided and describe the method by which it would be delivered. All reports for which a Respondent indicates an affirmative response are expected to be available, tested, and
accessible to City users at go‑live and included in the fixed fee price proposal. Instructions for completing the responses to the functional requirements are included in the attachment.
Attachment 3.2 – Interfaces
(See Excel Attachment V.3.2 - Interfaces)
For each interface identified in Attachment V.3.2, Respondents shall indicate whether the interface can be supported and describe the proposed integration approach. Any interface for
which a Respondent provides an affirmative (“Yes”) response shall be considered in scope and included in the fixed fee price proposal.
If additional interfaces are proposed, please add them and indicate how they will be implemented. The interface plan proposed by the Respondent shall be included in the fixed fee price
proposal. The City acknowledges that additional interfaces not included in the attachment may require a change order and an additional fee.
The Instructions tab on the spreadsheet provides guidance on completing the attachment.
Attachment 3.3 – Solution Information
Please respond to the questions and statements below regarding general solution information. Responses should describe capabilities available in the current generally available version
of the proposed system. Please provide responses as concisely as possible.
General
Proposed solution type.
Choose an item.
Authentication
Does the solution support Single Sign‑On (SSO)? If yes, identify supported standards (e.g., SAML 2.0, OpenID Connect, OAuth 2.0):
Does the solution support LDAP or Active Directory integration?
Does the solution support Multi‑Factor Authentication (MFA)? If yes, describe supported MFA methods (e.g., SMS, authenticator app, etc.):
Can MFA be enforced by role or user group?
Data Center & Hosting
Describe the hosting model:
Identify the primary responsibility for infrastructure management: (Vendor / Third party / Customer)
List primary and secondary data center locations (region/country):
Will the data for this project be located within the continental United States?
Identify any third‑party providers used for PaaS or IaaS (e.g., AWS, Azure, GCP) and describe the Respondent’s contractual relationship with these providers:
List each proposed environment (e.g., Production, Test, UAT, Training) and its purpose. Are environments logically or physically segregated?
Describe how the system scales to support growth in users, transactions, and data volume:
List data center audit certifications held (e.g., SOC 1/2 Type II, ISO 27001):
Data & Privacy
Describe the Information Security Management System (ISMS) governing the solution:
Is the solution ISO 27001 certified?
Identify ownership of all customer‑ provided and customer‑generated data:
Describe how the software provider may use customer data (if at all):
Describe supported mechanisms for exporting customer data upon request or contract termination, including exportable formats:
Specify any fees, timelines, or limitations associated with data extraction:
Describe incident response processes for data breaches:
Customer responsibilities during a breach event (if any):
What is your process when someone subpoenas or requests Bozeman data from you as a vendor?
Security
Describe how user roles and access permissions are defined and maintained:
Describe support for the Principle of Least Privilege (PoLP):
Describe login and session management across system modules:
Describe encryption standards used for data at rest and data in transit:
How is City data kept separate and secure from other customers, including any PII (Personally Identifiable Information) that may be gathered?
Describe the system’s PCI compliance for credit card transactions:
How is application‑level encryption supported for sensitive fields?
Describe how user security changes are requested, approved, and audited:
Describe system health and availability monitoring mechanisms:
Describe alerting and escalation processes for security and availability events:
System Support & Maintenance
Describe procedures for handling system outages and user‑reported issues:
Describe escalation paths for unresolved critical incidents:
Describe how customers are notified of incidents and outages:
Frequency of status updates during incidents:
Updates & Roadmap
Describe the frequency of software releases (major and minor):
Advance notice period provided before production updates:
Are updates mandatory or optional?
Are customers able to defer updates? If so, for how long?
Customer testing window prior to mandatory updates:
Describe the process for submitting, prioritizing, and tracking customer‑requested enhancements:
Integrations
Describe supported integrations with AMI/AMR platforms, and ingestion method and frequency:
Identify supported payment gateways and describe PCI DSS compliance posture and responsibilities between Respondent and City:
Identify supported payment gateways and describe PCI DSS compliance posture and responsibilities between Respondent and City:
Describe how GIS data is consumed (parcel ID, address, impervious area, frontage, service eligibility) and frequency and method of GIS synchronization:
Attachment 3.4 – System-Wide Software Capabilities
Please respond to the questions and statements below regarding general system capabilities. Responses should describe capabilities available in the current generally available version
of the proposed system. Please provide responses as concisely as possible.
Accessibility
Describe the system’s compatibility with desktop browsers, tablets, and mobile devices:
Are all core system functions accessible via mobile devices, or are some functions limited to desktop? If not, which ones?
Describe compliance with accessibility standards (e.g., WCAG 2.1 Level AA, Section 508):
Attachments & Document Management
Describe the system’s ability to attach documents to business transactions:
Describe the system’s ability to search for attachments within the application:
Describe any OCR capabilities regarding attachments, including invoices:
Describe the system’s ability to integrate with a third-party document management system to support attachments to business transactions:
Describe retention, archival, and purge capabilities for attached documents:
Audit
Describe transaction‑level auditing capabilities, including which events can be tracked:
Describe the ability to configure audit logging by transaction type, user role, or data element:
Describe how audit logs are secured, retained, and protected from alteration:
Describe how the system tracks security changes (e.g., role changes, permission updates):
Describe reporting and alerting capabilities based on audit activity:
Customer Portal
Describe customer self‑service features (start/stop service, billing history, usage, documents, payment plans):
Describe multi-account and multi-property login support:
Describe supported customer notification channels (e.g., SMS, email, push, etc.):
Data
Describe the system’s flexibility to add data fields to records and transactions, including any impacts on reporting and updates:
Describe how the system supports future-dated and back-dated changes:
Describe data validation rules and controls to ensure data quality:
Describe data retention, archival, and purging capabilities:
Transactions
Describe how the system supports exporting, importing, and inputting templates to enter routine, recurring, or frequent transactions:
Describe the system’s ability to support the uploading of transactions / data from third-party systems, including supported formats and validation rules:
Describe the ability to save transactions in draft status for later editing and posting.
Describe the system’s ability to add notes / comments to transactions (e.g., vendor file, POs):
Describe how corrections or reversals of posted transactions are handled:
Workflow
Describe how workflow rules are defined and configured:
Describe how users are notified of required actions:
Describe the system’s ability to support communications within the system to reduce emails:
Describe the user’s ability to view workflow status, history, and pending actions:
Describe the system’s ability to support alternate / temporary designated approvers:
Describe escalation rules and notifications when an approver does not respond:
Attachment 3.5 – Proposed Service Level Agreement
Please complete the following table identifying proposed service level guarantees. For each service, please indicate the metric used to measure the service quality, the proposed requirement
(target for service), and the proposed remedy/penalty if guarantee is not met.
Proposed Service Level Guarantees
Service
Metric
Requirement/ Guarantee
Remedy if Not Met
System Availability (Unscheduled Downtime)
System Response (Performance)
Issue Response Time
Issue Resolution Time
Recovery Point Objective (RPO)
Recovery Time Objective (RTO)
System Data Restore
Implementation of System Patches
Notification of Security Breach
Please list other proposed service levels
Proposed Service Level Guarantees
Define the metric used to calculate availability contained within the contract SLA:
How is performance against service levels reported to the City?
Please describe how the City will be able to monitor system performance through system performance reports, including:
System Availability/Uptime
Response Time/Performance
Throughput/Transaction Rate
System Logs (Startup time, error logs, users access)
Cyber Liability
In the event of a cyber-incident, please define liability for the City and vendor including any proposed mitigation services provided by vendor
IMPLEMENTATION
Attachment 4.1 – Work Effort
(See Excel Attachment 4.1 – Work Effort)
Respondents should complete the attachment regarding the level of effort for both the Respondent and the City for the project. The Instructions tab on the spreadsheet provides guidance
on completing the attachment.
Attachment 4.2 – Deliverables Expectations
(See Excel Attachment V.4.2– Deliverables Expectations)
Respondents should complete the attachment regarding deliverables expectations for the project. Please note there are two tabs to complete. The Instructions tab on the spreadsheet provides
guidance on completing the attachment.
The deliverables noted in the Deliverable Summary tab will be included in the SOW and will inform the milestones that trigger payments.
Attachment 4.3 – Data Conversions
(See Excel Attachment V.4.3 – Data Conversions)
Respondents should complete the attachment regarding data conversions for the project. If additional interfaces are proposed, please add them. The Instructions tab on the spreadsheet
provides guidance on completing the attachment.
Attachment 4.4 – Project Management Expectations
(See Excel Attachment V.4.4- Project Management Expectations)
Respondents should complete the attachment regarding project management for the project. The Instructions tab on the spreadsheet provides guidance on completing the attachment.
Attachment 4.5 – Challenges to Solve
The City has identified a set of key challenges related to its current environment. Respondents are requested to review each identified challenge and describe how their proposed solution
and implementation approach would address the challenge. Responses should be specific to the City’s stated challenges and should reflect the Respondent’s understanding of municipal
Utility Billing environments and best practices.
Customer / Property File
Challenge
GIS Integration: The City maintains a centralized geospatial database that will serve as the system of record for all geospatial data across the organization. Multiple business processes
rely on this data, and it is critical that information remains accurate, consistent, and aligned across systems.
The City seeks Respondents’ recommendations on how their Utility Billing solution can successfully integrate with the City’s GIS system to support shared data elements and business workflows
while minimizing duplicative data entry and reducing the risk of data becoming misaligned across systems. Respondents should describe how their solution would support effective data
synchronization, clearly defined system‑of‑record responsibilities, and ongoing data integrity between the Utility Billing and GIS environments.
Response
Solid Waste
Challenge
Ad Hoc Solid Waste Charges: When Solid Waste customers utilize additional services (e.g., excess garbage, bulk items, etc.), the City needs to charge an additional fee for those pickups.
Currently, those additional services are recorded in RAMS Pro, then it is a very manual process to get that information into the billing system and one that frequently results in billing
errors. As such, and knowing that the City will continue to RAMS Pro for field work, the City seeks recommendations on the most efficient way to ensure accurate billing in the Utility
Billing system.
Response
Service Requests
Challenge
Service Request and Work Order Integration: The City currently uses multiple modes (e.g., online forms, phone, etc.) for citizen service requests (e.g., new service request, missed
solid waste pickups, issue with water, etc.). To provide consistent and streamlined customer experience, the City seeks recommendations on the best approach for customer interactions
for utility‑related requests.
In addition, the City uses Cityworks for certain work order types and is actively expanding Cityworks functionality across additional departments. The City requests vendor recommendations
on the most effective approach for managing utility work orders—specifically, whether to (a) integrate utility work orders with Cityworks as a centralized work management platform,
or (b) utilize the Utility Billing solution’s native work order capabilities. Respondents must discuss the advantages, limitations, and long‑term implications of each approach based
on the City’s operational goals, staffing model, and technology environment.
Further, RAMS-Pro is used by City staff to manage work orders related to Solid Waste, with a manual intake process that then gets input into RAMS-Pro for staff to complete the work order,
and another manual process to add charges to customer accounts, if necessary. The City intends to keep RAMS-Pro to manage Solid Waste work orders and seeks recommendations to integrate
service requests to RAMS-Pro work orders
Response
Special Assessments
Challenge
Special Assessments: The City recognizes that management of special assessment billing may fall within either a Utility Billing or an ERP solution, depending on system capabilities
and configuration. The City is seeking Respondents’ recommendations on how their proposed solution would support the calculation, billing, payment tracking, and payoff of special assessments,
including how these processes would integrate with other City financial and customer billing functions, if applicable.
Response
Attachment 4.6 – Key Contract Terms
The City anticipates negotiating a final contract with the Selected Vendor following award. To support an efficient contracting process, Respondents shall respond to each of the following
key contract terms and identify Respondent’s ability to comply with them as the City will require materially similar language in the final contract. If the Respondent cannot comply
with the following terms, the Respondent must indicate why. Failure to disclose exceptions may be grounds for disqualification.
The City understands it may have to negotiate contracts with multiple Firms the comprise the Selected Vendor. Each Firm should complete the respective table below.
To be completed by each Firm providing implementation services:
Contract / Proposal Requirement
Response
Key Personnel – The City requires assurances as to the continuity, qualifications, and performance of vendor staffing assigned to the project. Respondents shall make Key Personnel available
(Project Manager & Functional Leads) during the Discovery process to interview all proposed Key Personnel.
Except in the event of resignation, termination of employment, illness, or other circumstances beyond the Vendor’s reasonable control, Key Personnel may not be removed or replaced without
the City’s prior written approval. In the event that a Key Person is no longer available due to such circumstances, the Vendor shall promptly notify the City and propose a replacement
resource with qualifications and experience equal to or greater than those of the individual being replaced, subject to the City’s approval and at no additional cost to the City.
In addition, the City reserves the right to request the replacement of any Key Personnel whose performance, conduct, or qualifications are determined by the City, acting in good faith,
to be inappropriate or not well suited for the successful completion of the project. Upon such request, the Vendor shall propose a suitable replacement resource with qualifications
and experience equal to or greater than those of the individual being replaced, subject to the City’s approval and at no additional cost to the City.
System Configuration Limits – The Selected Vendor shall deliver the project in accordance with the City’s defined business process objectives and Functional Requirements. The Vendor
may not limit project scope due to configuration constraints except as described in the Fixed Fee Pricing Based on Milestones below. Any identified system limitations must be disclosed
during proposal evaluation or discovery and resolved within the agreed‑upon scope.
Use of Deliverables and Milestones – The City will require use of Deliverables and Milestones during implementation. A Deliverable is a tangible work product, documentation, configuration,
or other artifact produced that the City can use, rely upon, or reference after completion. Deliverables are subject to formal review and require written acceptance by the City in accordance
with the acceptance process to be defined in the SOW, and in no event shall Deliverables be deemed accepted. A Milestone represents a defined phase or sub-phase of the project and is
composed of one or more Deliverables and/or required project activities. A Milestone shall be considered achieved only upon completion and City acceptance of all required Deliverables
and completion of any associated required activities identified for that Milestone.
Fixed Fee Pricing Based on Milestones –
Implementation services shall be provided on a fixed-fee, milestone-based basis. Fixed fees shall include all labor, hours, effort, and resources necessary to complete the agreed-upon
scope and acceptance criteria. The Selected Vendor assumes responsibility for delivering agreed-upon outcomes within the fixed fee, except for limited categories of services, which
may be performed within a bounded cap (included in the fixed fee) or pre-approved not-to-exceed limits.
The following activities may be subject to a bounded cap, strictly subject to City approval and not-to-exceed limits: a) Report formatting, layout, or cosmetic changes requested by the
City after functional acceptance of report content; b) Additional training sessions, delayed training, or re-training requested by the City beyond the agreed training plan and schedule;
c) Configuration of additional workflow permutations or approval paths not identified in the agreed design documents or baseline scenarios; d) Other City-directed changes where scope
variability is outside the Vendor’s reasonable control.
All services performed under approved bounded exceptions shall be tracked separately from fixed-fee activities. The Selected Vendor shall maintain detailed records of hours expended
by resource, role, activity, and date, and shall update and share exception service burn-down reports with the City no less frequently than bi-weekly, or more frequently upon request.
The City shall have visibility into the remaining balance of approved exception effort. Further, the Selected Vendor shall notify the City in writing when consumption of any approved
bounded exception reaches seventy-five percent (75%) of the approved not-to-exceed limit. No services in excess of the approved limit may be performed without additional written authorization
from the City.
Respondents shall identify any implementation activities they anticipate may be proposed as bounded exceptions. For each anticipated exception, Respondents shall provide the following:
a) Description of the activity or service;
b) Rationale for why the activity is not appropriate for fixed-fee pricing;
c) Recommended controls or acceptance criteria to minimize variability.
Fixed Fee Pricing Based on Milestones –
Implementation services shall be provided on a fixed-fee, milestone-based basis. Fixed fees shall include all labor, hours, effort, and resources necessary to complete the agreed-upon
scope and acceptance criteria. The Selected Vendor assumes responsibility for delivering agreed-upon outcomes within the fixed fee, except for limited categories of services, which
may be performed within a bounded cap (included in the fixed fee) or pre-approved not-to-exceed limits.
The following activities may be subject to a bounded cap, strictly subject to City approval and not-to-exceed limits: a) Report formatting, layout, or cosmetic changes requested by the
City after functional acceptance of report content; b) Additional training sessions, delayed training, or re-training requested by the City beyond the agreed training plan and schedule;
c) Configuration of additional workflow permutations or approval paths not identified in the agreed design documents or baseline scenarios; d) Other City-directed changes where scope
variability is outside the Vendor’s reasonable control.
All services performed under approved bounded exceptions shall be tracked separately from fixed-fee activities. The Selected Vendor shall maintain detailed records of hours expended
by resource, role, activity, and date, and shall update and share exception service burn-down reports with the City no less frequently than bi-weekly, or more frequently upon request.
The City shall have visibility into the remaining balance of approved exception effort. Further, the Selected Vendor shall notify the City in writing when consumption of any approved
bounded exception reaches seventy-five percent (75%) of the approved not-to-exceed limit. No services in excess of the approved limit may be performed without additional written authorization
from the City.
Respondents shall identify any implementation activities they anticipate may be proposed as bounded exceptions. For each anticipated exception, Respondents shall provide the following:
a) Description of the activity or service;
b) Rationale for why the activity is not appropriate for fixed-fee pricing;
c) Recommended controls or acceptance criteria to minimize variability.
Final Acceptance – Final acceptance shall occur following go‑live and completion of a post‑implementation validation period of not less than ninety (90) days, during which the City will
verify that all SOW requirements and project criteria have been met. Final milestone payment shall be contingent upon written Final Acceptance by the City and shall represent no less
than ten percent (10%) of total implementation fees for the applicable phase.
If the City determines that there is an outstanding project requirement or configuration defect, the City will notify the Selected Vendor in writing. The Selected Vendor will resolve
all outstanding issues or provide a mutually agreeable plan for future resolution at no additional cost. Upon resolution, the City may repeat testing for provided resolution with a
period not to exceed fifteen (15) days.
Warranty – The Selected Vendor shall warrant that all services will be performed in a professional and workmanlike manner by qualified personnel and that all deliverables, including
configurations and work products, will conform to the agreed‑upon scope, specifications, and vendor responses to Functional Requirements set forth in the Statement of Work. The warranty
period shall extend for no less than forty-five (45) days following Final Acceptance. Warranty remedies shall include, at no additional cost to the City, correction of defects and reperformance
of non‑conforming services.
Hold Harmless – Selected Vendor shall hold harmless, defend, and indemnify City and its officers, employees, agents, and volunteers, from and against any and all liability, loss, damage,
expense, and costs (including without limitation costs and fees of litigation) of every nature arising out of or in connection with Selected Vendor’s performance, including but not
limited to claims related to intellectual property infringement, data security breaches, or violations of applicable laws, except to the extent caused by the sole negligence or willful
misconduct of the City.
To be completed by each Firm providing software services:
Contract / Proposal Requirement
Response
Service Level Agreements – The Selected Vendor shall meet or exceed the availability, performance, and support service levels set forth in Attachment V.3.5. Service levels shall be
contractually binding and applicable to all production environments.
Service Level Agreement Remedy – The Selected Vendor shall provide remedies for failure to meet agreed service levels, which may include service credits, fee refunds, or other remedies.
Repeated failures to meet service levels may constitute a material breach of the Agreement.
Hold Harmless – Selected Vendor shall hold harmless, defend, and indemnify City and its officers, employees, agents, and volunteers, from and against any and all liability, loss, damage,
expense, and costs (including without limitation costs and fees of litigation) of every nature arising out of or in connection with Selected Vendor’s performance, including but not
limited to claims related to intellectual property infringement, data security breaches, or violations of applicable laws, except to the extent caused by the sole negligence or willful
misconduct of the City.
To be completed by each Firm:
The City has included its standard SaaS Agreement (Appendix B) for review. Respondents are asked to review this draft agreement and identify any key exceptions, concerns, or provisions
that would require modification in order to sign a contract with the City. A full redline is not required at this stage; however, Respondents should clearly outline (including section
number references) the material terms they would be unable to accept or would propose to revise. Add additional rows as necessary.
Firm:
Section #:
Agreement Exception or Concern:
PRICING
Attachment 5.1 – Price Proposal
(See Separate Excel Spreadsheet)