HomeMy WebLinkAbout26 - Questions and Answers - Bozeman Utility Billing Software Services & Implementatiion RFP
Request for Proposals (RFP)
Utility Billing (UB) Software and
Implementation Services
Addendum #1
April 17, 2026
ADDENDUM #1
This Addendum #1 is issued in response to questions and requests from vendors for the City of
Bozeman’s Request for Proposals (RFP) for Utility Billing (UB) Software and Implementation
Services. All responses reflect the City’s best information and understanding as of the date of
this Addendum. In some cases, responses describe current intentions, preferences, or
anticipated approaches that may be further refined during contract negotiation, discovery, or
implementation planning. Nothing in these responses should be construed as a guarantee,
commitment, or modification of the RFP beyond what is explicitly stated. All other terms and
conditions of the RFP remain unchanged unless expressly modified herein. Respondents are
responsible for reviewing and incorporating the information contained in this Addendum into
their proposals.
This Addendum has two (2) parts:
I. Responses to the written questions submitted by Respondents.
To improve clarity and readability, the City has organized the responses to submitted
questions into logical topic groupings. These groupings are provided solely as a navigational
aid and are not intended to redefine, limit, or otherwise characterize the substance or
importance of any individual question or response. Respondents are solely responsible for
reviewing all questions and all corresponding responses in their entirety, regardless of how
questions have been grouped, and for incorporating all relevant information into their
proposals.
II. PowerPoint from Pre-Proposal Conference
Part I: Responses to Written Questions
1. Procurement Process, Submission Rules, and Administrative
Clarifications
1.1 See below.
2. Evaluation Approach & Relationship to Other Procurements
2.1 Has the City selected an ERP vendor through the separate March 14, 2026
ERP/HCM RFP? If not, what is the expected ERP selection date, and should the
UB vendor plan for a phased ERP integration (temporary financial export at UB go-
live, full API integration once ERP is live)?
City Response: The City has not selected an ERP vendor. The City anticipates that
ERP vendor selection will occur later in the year, likely in Q4.
The City does not currently anticipate the Utility Billing system and the new ERP
system going live simultaneously, as doing so could introduce additional project
risk. Vendors should plan for the possibility of a phased integration approach, which
may include temporary or interim financial interfaces between the new Utility Billing
system and the City’s existing ERP at UB go‑live, with a transition to a full, real‑time
integration once the new ERP is implemented. The City expects to work with the
selected vendor(s) to finalize sequencing, interim integration requirements, and
long‑term integration architecture during implementation planning and discovery.
2.2 Section 1.7.1 indicates the City may award one or multiple contracts. In that
context, will the City consider proposals that address a subset of the overall
scope (e.g., specific functional areas or services), and how will such proposals
be evaluated relative to comprehensive, end-to-end solutions?
City Response: The City confirms that it may award one or multiple contracts and
will consider proposals that address a subset of the overall scope. Vendors are not
required to propose an end‑to‑end solution; however, the City's primary objective is
to ensure that the full functional scope is met effectively and efficiently, regardless
of the delivery model proposed.
Proposals that address a subset of scope, or that involve multiple vendors working
in concert (e.g., a joint proposal), will not be evaluated less favorably than a
comprehensive, end‑to‑end solution solely on the basis of delivery model.
However, the City will carefully evaluate how proposed solutions—whether single
or multi‑vendor—address the completeness of scope, reliability of integrations
between systems, and long‑term supportability, including how integrations will be
maintained through system updates, upgrades, and vendor changes.
2.3 Is the City willing to entertain proposals limited to the advisory scope of the
project - specifically billing process design, organizational readiness, and change
management - with the intent that these services support and integrate with the
billing solution selected through the RFP?
City Response: The City does not intend to award a contract limited solely to
advisory services, absent an accompanying software solution that addresses the
functional scope outlined in this RFP. The City's objective is to procure a complete
Utility Billing solution, inclusive of both software and implementation services, that
meets the requirements described herein.
However, the City will consider proposals where the software provider and the
implementing partner are separate entities, provided that the proposal clearly
identifies all parties, defines each party's roles and responsibilities, and
demonstrates how the proposed solution will meet the City's full functional and
technical requirements.
2.4 Architecture Approach (Decoupled vs. Integrated): To what extent is the City open
to an architecture where customer-facing capabilities (e.g., portal, payments,
notifications, service requests) are decoupled from the core utility billing system,
and how would such an approach be evaluated relative to a fully integrated,
single-platform solution?
City Response: The City is open to proposals where customer‑facing capabilities—
such as the self‑service portal, payment processing, notifications, and service
requests—are decoupled from the core Utility Billing platform, provided that the
proposed architecture delivers a cohesive, reliable, and maintainable solution that
meets the City's functional requirements. Please see response to 2.2 for
effectiveness and efficiency requirements of separate modules and/or systems.
Respondents should note that customer portal functionality is within the scope of
this RFP. Proposals that do not include or address portal functionality will be
evaluated accordingly.
2.5 Cross-System Experience Consistency: Given the City’s parallel ERP and
anticipated permitting system procurements, how important is maintaining a
consistent customer-facing experience across systems, and should this be
addressed within this proposal?
City Response: The City recognizes the value of intuitive, user-friendly customer-
facing experiences and will evaluate the usability and accessibility of proposed
solutions as part of its overall assessment. However, these systems serve different
functional purposes and customer interactions, so cross-system experience
consistency across the City's parallel ERP, Utility Billing, and permitting
procurements is not a distinct evaluation criterion. The City's objective is to select
solutions that best meet its functional, technical, and operational requirements,
and proposals will be evaluated on that basis.
2.6 Future Flexibility / Component Replacement: How important is the ability to
replace individual system components over time without requiring a full platform
replacement, and how will this factor into evaluation?
City Response: The City recognizes that technology needs evolve over time and
that the ability to adapt individual system components—such as payment
processing platforms, meter data management systems, or customer
communication tools—without requiring a full platform replacement has practical
long-term value. As such, the City expects that the proposed Utility Billing solution
will be built on an open, integration-friendly architecture that does not create
proprietary dependencies that would unnecessarily limit the City's future flexibility.
That said, component replaceability is not a standalone evaluation criterion for this
procurement. The City's evaluation will focus primarily on how well the proposed
solution meets its current functional, technical, and operational requirements.
Vendors are encouraged to describe their integration architecture, API capabilities,
and any relevant aspects of their platform that support long-term flexibility and
adaptability as part of their technical response. This information will be considered
as part of the City's overall assessment of the proposed solution's long-term value
and sustainability.
2.7 Evaluation Emphasis (CX vs. Operations): How does the City intend to balance
customer experience outcomes (e.g., increased self-service adoption, reduced
manual intake) with back-office operational efficiency in its evaluation of
proposed solutions?
City Response: The City does not view customer experience and back-office
operational efficiency as competing or mutually exclusive priorities, and they are
not treated as distinct, separately weighted evaluation criteria in this procurement.
The City's objective is to select a Utility Billing solution that effectively serves both
its customers and its staff, and proposals will be evaluated holistically on how well
the proposed solution meets the City's functional, technical, and operational
requirements as described in this RFP.
Vendors are encouraged to demonstrate how their proposed solution delivers value
across the full spectrum of utility billing operations — from intuitive customer-
facing capabilities such as self-service, portal access, and communications, to
efficient back-office processes such as billing accuracy, exception management,
collections, and reporting. The City does not intend to prioritize one dimension over
the other, and proposals that excel in both areas will reflect favorably in the overall
evaluation.
3. Pricing, Budgets, and Cost Structure
3.1 The City noted on page 25 of the RFP that it will allow vendors to propose an
alternative to the CityWorks integration. Can the City clarify if a budget is required
for the CityWork integration if vendors are proposing their own solution?
City Response: The City confirms that vendors proposing a native service request
and work order solution as an alternative to the Cityworks integration are not
required to include a Cityworks integration in their proposed scope or budget at this
time. As noted in the RFP, the City is open to alternative approaches and recognizes
that a robust, native SR/WO capability within the Utility Billing platform may reduce
or eliminate the need for a Cityworks integration for utility-related service and work
order functions.
However, vendors should be aware that the City already owns and utilizes
Cityworks for asset management and work order functions across other
departments, and integration use cases between the Utility Billing system and
Cityworks may be identified during implementation discovery that have not been
fully anticipated at this stage of procurement. The City will work collaboratively with
the selected vendor during discovery to make a final determination on Cityworks
integration scope and financial impacts.
3.2 For subscription pricing purposes, what does the City define as a "connection" or
billable account — water accounts only (~15,000), total unique customer
accounts, or total service connections across all utility services (~43,000+)?
City Response: The City does not prescribe a specific definition of "connection" or
"billable account" for subscription pricing purposes, as the City recognizes that
licensing models vary by vendor. To assist vendors in structuring their pricing
proposals, the City provided volume information in Appendix A. An additional note
on volumes is that:
• For the approximately 17,000 bills issued per month, water and solid waste
accounts are consolidated onto a single bill where applicable; some
accounts are solid waste only.
• The special assessment bills are sent out once per year, due in two payment
installments.
Vendors should clearly define the unit of measure used for subscription or licensing
pricing in their proposal and apply that definition consistently across all proposed
pricing. The City intends to evaluate total cost of ownership across all proposals
and encourages vendors to structure pricing in a manner that is transparent,
scalable, and reflective of the City's actual service volumes as described above.
3.3 The RFP requires all interfaces with an affirmative response to be included in the
fixed-fee price. Does this apply to custom-built integrations (such as RAMS Pro
and Cityworks) where the integration design cannot be fully specified until Phase
1 discovery? If yes, how does the City expect vendors to manage scope risk for
custom integrations in a fixed-fee structure?
City Response: The City's strong preference is for fixed-fee pricing for all interfaces
identified in the RFP. The City recognizes that final integration designs will be
refined; however, the City has provided data element descriptions for each
interface to allow vendors to develop a reasonable order-of-magnitude estimate of
integration effort. The City expects that experienced implementation vendors have
sufficient knowledge of similar integration patterns to provide a fixed-fee price that
reflects that experience, inclusive of reasonable contingency for integration
complexity.
The City's preference for fixed-fee pricing reflects a practical need for budget
certainty. Post-award changes to project cost may require additional governing
body approval, which introduces procedural and timeline risk the City seeks to
minimize.
That said, the City acknowledges that material changes to integration scope — such
as the identification during discovery of a fundamentally different technical
architecture than described in the RFP — may warrant discussion through a defined
change order process. Vendors should clearly state in their proposals any
conditions underlying their fixed-fee integration pricing and identify any scenarios
under which a change order may be warranted. The City will evaluate the
reasonableness as part of its overall cost and proposal review. Vendors are
discouraged from using conditions as a mechanism to artificially lower proposed
fees, as the City will assess the completeness and realism of all pricing during
evaluation.
3.4 Are all travel and expense costs for vendor on-site presence (discovery, UAT,
training, go-live support) required to be included in the fixed implementation fee,
or may they be priced as a separate line item with a not-to-exceed cap?
City Response: The City’s intent in requiring fixed‑fee pricing inclusive of travel is to
provide cost certainty and avoid uncontrolled or ad‑hoc travel expenses. The City is
open to a controlled travel allowance or drawdown model, provided that it is clearly
defined, appropriately justified, and subject to a not‑to‑exceed amount. Any such
travel budget must be based on the Respondent’s proposed implementation
approach and should reflect what the Respondent believes will best support project
success. Travel expenses would require City pre‑approval and must comply with
reasonable cost controls (e.g., GSA or comparable public‑sector travel rates).
Respondents may propose alternative methods for managing and controlling
variable travel costs, provided they ensure transparency, predictability, and
alignment with the City’s financial controls.
4. Contractual Terms & Commercial Exceptions
4.1 What are the City’s expectations regarding post-go-live support duration
(Hypercare)?
City Response: Please see the responses to the Final Acceptance and Warranty
sections of the Key Contract Terms in Attachment 4.6.
Additionally, The City expects post-go-live support (“hypercare”) to include, at a
minimum, timely correction of implementation-related defects or configuration
issues that prevent the system from operating as designed. However, the City does
not view hypercare as limited to break-fix support alone. The purpose of hypercare
is to support stabilization and operational transition, including elevated support
coverage, rapid triage and resolution of issues, user support for early production
questions, assistance with critical business cycles immediately following go-live
(e.g., first billing cycle), and targeted configuration refinements necessary to
achieve intended outcomes.
To clarify, hypercare is intended to address go-live stabilization and
implementation-related issues, not ongoing enhancement requests or City-directed
scope changes that arise after go-live.
4.2 Are there any specific KPIs or success metrics defined for the project?
City Response: The City has not defined specific KPIs or success metrics for this
project at this time. However, the City recognizes the value of establishing clear,
measurable indicators of project and system success and expects the selected
vendor to bring experience and recommendations for defining and tracking relevant
metrics throughout the implementation lifecycle and beyond. The City will work
collaboratively with the selected vendor during project initiation to establish a
formal set of KPIs aligned with the City's operational priorities and project
objectives.
4.3 Are there any legal or regulatory requirements specific to Montana that must be
addressed?
City Response: Not that the City is aware of aside from what is included in the
samples SaaS Agreement contract in Appendix B.
4.4 What is the expected contract structure (fixed price vs. time and materials)?
City Response: Please see Fixed Fee Pricing Based on Milestones section of
Attachment 4.6 – Key Contract Terms.
4.5 Will the City require performance bonds or insurance coverage beyond standard
requirements?
City Response: The City does not anticipate requiring performance bonds beyond
standard requirements. However, vendors should note that the City expects the
milestone payment associated with Final Acceptance to represent no less than 10%
of total implementation fees, ensuring that a meaningful portion of implementation
compensation is contingent upon the City's formal acceptance of the completed
solution. Vendors should reflect this expectation in their proposed payment
schedules.
With respect to insurance coverage, the City's requirements are outlined in the
sample SaaS Agreement included in Appendix B. Vendors should review Appendix B
carefully and confirm their ability to meet the stated insurance requirements as part
of their proposal response.
4.6 What is the City’s expectation regarding data ownership and access post-
contract?
City Response: The City’s expectation is that all City data remains the sole
property of the City, not the vendor, at all times. The vendor may access and use
City data only as necessary to perform contractually agreed services.
As reflected in the RFP and the City’s cloud and SaaS requirements, the City
requires the ability to obtain a complete copy of its data in a usable and commonly
supported format upon request, including at contract expiration or termination,
without unreasonable delay or additional cost beyond what is specified in the
contract. This includes data necessary to support transition to another system or
for archival and records‑retention purposes.
Following confirmation that the City has received its data, the vendor will be
expected to securely remove all City data from its systems, in accordance with
agreed data retention, destruction, and security provisions. Respondents should
describe their standard data ownership, export, and data deletion practices as part
of their response.
4.7 Are there any existing contracts with third-party vendors that must be
maintained?
City Response: The City interprets this question as relating primarily to existing
third-party system relationships and integrations. The City's anticipated
integrations are described in Attachment 3.2 – Interfaces, which identifies the
systems the City currently uses and the anticipated data flows between those
systems and the proposed Utility Billing solution.
Vendors are not required to preserve or maintain integrations with any specific
third-party system as a condition of their proposal. The City welcomes respondents
to propose keeping, modifying, or replacing existing integrations, or to recommend
additional integrations they believe would contribute to project success, provided
that any such recommendations are clearly described and justified in the proposal.
The City's objective is to implement the most effective and efficient solution, and
vendor recommendations regarding system relationships will be considered as part
of the overall evaluation.
4.8 If vendors are inquiring about existing contractual obligations with the City's current
Utility Billing or technology vendors that may affect implementation timing or data
access, the City does not anticipate that existing vendor contracts will present material
constraints on the implementation of the new solution.Is the $1,500,000 per
occurrence / $3,000,000 aggregate Cyber Liability insurance required at proposal
submission, at contract execution, or at implementation commencement?
City Response: Proof of insurance is preferred at contract execution but is required
before the contractor can start work.
4.9 Is SAM.gov UEI (Unique Entity Identifier) registration mandatory for the proposal
to be considered responsive? The Signature Page (Attachment V.1.1) has a field
for this number.
City Response: Respondents should provide a SAM.gov UEI if they have one, but it
is not required to be considered responsive.
4.10 For the Warranty provision (SaaS Agreement Section 23), will the City accept a
mutually agreed remediation plan with defined milestones — not to exceed 90
days total — as an alternative to the strict 30-day cure period for complex multi-
system integration defects where resolution requires coordination across
multiple vendors?
City Response: The City is open to reasonable alternatives to the cure period
outlined in the sample SaaS Agreement. The City would consider a mutually agreed
remediation plan with defined milestones as an alternative, provided that such a
plan includes clear accountability, measurable progress indicators, and a total
remediation period that is reasonable and protects the City's operational interests.
Respondents should note that the sample SaaS Agreement included in the RFP
represents the City's baseline contractual expectations. Respondents are expected
to review the sample agreement carefully and identify any provisions they wish to
negotiate as part of their proposal response. The City does not intend to wholesale
replace the sample agreement, and proposed deviations — including alternative
warranty cure language — will be evaluated on the basis of reasonableness,
fairness, and the degree to which they protect the City's interests. Final contract
terms, including any modifications to warranty cure provisions, will be determined
through post-award negotiation.
4.11 What is the City's expectation for the maximum liability cap for contract damages
— 12 months of fees paid, total fees paid, or uncapped?
City Response: The City may consider negotiating liability issues with the
selected vendor.
4.12 Will the City's written consent for contract assignment be unreasonably withheld
in cases where a successor entity assumes all obligations, maintains service
levels, and provides 60 days advance notice?
City Response: The City's requirements regarding contract assignment are outlined
in the RFP, which states that the Selected Vendor shall not assign, transfer, convey,
or otherwise dispose of the Contract — or any part thereof — without prior written
approval from the City. This provision reflects the City's need to maintain oversight
and continuity of service in the event of a vendor merger, acquisition, or corporate
restructuring.
The City acknowledges the vendor's question regarding the standard by which such
approval would be granted. While the City does not commit to a specific approval
standard at this stage, the City recognizes the obligation of good faith and fair
dealing in contracts.
The City reserves the right to withhold consent where the proposed assignment
would introduce unacceptable risk to service continuity, create a conflict of
interest, or result in a material adverse change to pricing, support, or the City's data
rights. Final assignment language, including any modifications to the existing RFP
provision, will be subject to post-award contract negotiation.
5. Implementation Strategy, Phasing, and Timeline
5.1 How many complete parallel billing cycles does the City expect vendors to run
(SMART360 and Naviline simultaneously) before authorizing go-live? Who has
authority to sign off on parallel testing completion?
City Response: The City has not prescribed a specific number of parallel billing
cycles at this stage. However, the City expects parallel billing testing to serve as a
critical quality gate prior to go-live authorization and will not authorize go-live until
parallel testing has been completed to the City's satisfaction.
As a general guideline, the City anticipates that a minimum of two full parallel billing
cycles will be required. Given the complexity of the City's billing environment —
including multiple service types (water/wastewater, solid waste, stormwater, and
potentially special assessments), tiered rate structures, Winter Quarter Average
calculations, and integrations with systems such as RAMS Pro— the City may require
up to three parallel cycles if results from initial cycles do not meet acceptable
variance thresholds.
It is recommended that Respondents describe their recommended approach to
parallel billing testing as part of their implementation methodology, including:
• The number of parallel cycles proposed and the rationale for that
recommendation
• Variance thresholds used to determine acceptable results at the account,
service, and revenue levels
• How discrepancies are identified, documented, and resolved between
cycles
• How special billing scenarios (e.g., WQA, special assessments, RAMS-
generated ad hoc charges) are validated during parallel testing
Regarding sign-off authority, the City expects that go-live authorization will require
formal written sign-off from appropriate City leadership — at minimum the Finance
Director or equivalent — following a vendor-provided parallel testing completion
report. The City and selected vendor will define the specific sign-off process and
documentation requirements during project initiation.
5.2 What is the expected duration of parallel testing the City requires?
City Response: The City interprets this question as relating to either the duration of
parallel billing testing prior to go-live, or the potential for extended parallel
operations where both the legacy and new systems are run simultaneously in a live
production environment following go-live.
Regarding parallel billing testing duration, the response to Question 5.1.
Regarding extended parallel operations — where both systems are maintained
simultaneously in a live production environment following go-live — the City does
not anticipate this approach as a standard expectation. The City's preference is for
a clean cutover to the new Utility Billing system following successful completion of
parallel billing testing, as maintaining two live production systems simultaneously
introduces significant operational burden, data integrity risk, and cost for both the
City and the vendor.
5.3 Does the City prefer a go-live date immediately following a month-end billing
close, or is mid-cycle go-live acceptable?
City Response: The City’s preference is to schedule go‑live immediately following
completion of a full monthly billing cycle close in the legacy system. This timing
helps ensure that accounts, balances, meter reads, and payments are fully
reconciled prior to cutover, supports a clean opening position in the new system,
and reduces data conversion complexity and proration/reconciliation risk that can
occur with a mid‑cycle transition.
That said, the City recognizes that other cutover approaches may be viable. In a
prior system transition, the City successfully went live by transferring meter reads
into the new system and completing the full billing process in the new application
with vendor support, which supported continuity of customer billing and payment
processing. Accordingly, the City is open to vendor recommendations on the most
practical cutover strategy (including whether a mid‑cycle or “bill in the new system”
approach is acceptable), provided the approach maintains the City’s monthly billing
cadence, minimizes customer disruption, and includes a clear plan for
reconciliation and stabilization. The final go‑live timing will be confirmed
collaboratively during project planning based on readiness, risk, and operational
considerations.
6. City Staffing, Resourcing, and Governance
6.1 Are there any union or labor constraints that may impact implementation
timelines?
City Response: There are no union constraints expected to impact implementation
timelines. The City is anticipating this project will place additional strain on existing
staff and is planning accordingly so as not to impact agreed upon implementation
timelines. Please also see response to 6.2 regarding project management support.
6.2 Is the Project Manager (Financial Management Analyst) a dedicated full-time role
for the UB implementation, or will this person simultaneously manage other
Finance Department responsibilities?
City Response: The City's designated Project Manager for the Utility Billing
implementation is expected to serve in a primary project management capacity for
both the Utility Billing and ERP implementations, which may run concurrently during
portions of the project lifecycle. While this individual's other Finance Department
responsibilities will be limited during the implementation period, the City does not
anticipate this role to be exclusively dedicated to the Utility Billing implementation
alone.
7. Change Management, Communications, and Adoption
7.1 What is the City’s preferred approach to change management and user adoption?
City Response: The City has not prescribed a specific change management
methodology for this implementation and welcomes vendors to propose an
approach that reflects industry best practice and is appropriately scaled to the size
and complexity of the City's utility billing environment, including multiple service
types (water/wastewater, solid waste, stormwater, and special assessments) and
the range of staff roles involved in billing, customer service, field operations, and
financial management.
7.2 What is the expected training approach (on-site, virtual, train-the-trainer)?
City Response: The City has not prescribed a specific training modality for this
implementation and welcomes vendors to propose an approach that reflects
industry best practice and is appropriately tailored to the size, complexity, and
operational context of the City's utility billing environment.
The City recognizes that effective training is a critical driver of system adoption and
long-term operational success and will evaluate vendor training proposals on the
basis of comprehensiveness, practicality, and demonstrated effectiveness in
comparable municipal implementations. Vendors are encouraged to propose a
blended training approach that may incorporate in-person, virtual, and self-paced
elements as appropriate for different user roles and training objectives. Vendors
should clearly describe any train-the-trainer components included in their
proposed approach, including what support and preparation internal trainers would
receive, and how training quality and consistency would be maintained across
departments.
The City notes that a proposed budget has been included in the RFP, and proposals
that maximize the effectiveness of training within the established budget will be
viewed favorably.
7.3 How many City staff will require training across departments?
City Response: The City anticipates that training will be required across several
departments, including Treasury, Water/Wastewater, Solid Waste, Finance, and IT,
as well as any other staff with system access responsibilities. Based on current
staffing, the following City estimates the approximate training population by
department for financial components of Utility Billing system (training for
operational resources (e.g., Service Requests and Work Orders would be materially
more)):
• Treasury / Utility Billing: Approximately 6 staff
• Water / Wastewater: Approximately 4 staff
• Water Conservation: 3 staff
• Solid Waste: Approximately 3–5 staff
• IT / System Administration: Approximately 1–2 staff
• Finance / Accounting: Approximately 2–3 staff
• Other Departments / Management: Approximately 3–5 staff (reporting or
read-only access)
The City estimates a total training population of approximately 20–25 staff at this
time, though the City acknowledges that the final number of staff requiring training
may vary depending on the proposed solution's role-based access model, the
scope of system functionality deployed, and staffing changes between now and
implementation.
8. User Counts, Licensing, Roles, and Mobile Access
8.1 What is the expected number of concurrent internal and external users?
City Response: Please see response to 8.2.
8.2 The City noted its openness to alternative solutions for managing customer-
centric fieldwork where service orders are generated from the CIS system.
Modern cloud-native CIS systems have a purpose-built field service order
management application to manage short cycle, meter and premise-centric
utility field work activities. In order to provide accurate pricing for the City, can the
City please identify the user counts as follows:
i) Full User (This user has the ability to create, edit, and close a service ticket.
Customer service representatives are excluded from this count as they have
automatic use of this service based on their roles.) – How many field service
technicians will need access to this service?
ii) Light User (This user has the limited ability to generate a report or access a
dashboard. They do not have the ability to create, edit or close a service ticket. A
typical example of a user is a manager or business analyst.) – How many users
will need access to this service?
City Response: The City does not intend to prescribe exact user counts based on
vendor-specific licensing classifications (e.g., “Full User” vs. “Light User”), as
definitions and licensing models vary by solution. The City has provided staffing and
organizational context (including approximately 75 FTEs across Water / Wastewater
/ Sewer and 25 FTE across Solid Waste) to support Respondents’ sizing
assumptions.
Respondents should propose a user model and estimated counts based on their
experience implementing similar utility organizations and clearly state the
conditions used. The City will evaluate the reasonableness of proposed user
assumptions as part of the overall best-value assessment. Any licensing quantities
necessary to support the proposed approach must be reflected transparently in the
pricing proposal, with optional expansions clearly identified if applicable.
8.3 Approximately how many field technicians across water, wastewater, and solid
waste operations will use the mobile work order application, and what mobile
device platforms (iOS, Android, or both) are currently deployed in the field?
City Response: The City has both IOS and Android devices for field employees. See
response to 8.2 for additional information.
8.4 What are the City’s expectations for mobile/offline capabilities for field staff?
City Response: The City expects that the proposed Utility Billing solution will
support robust mobile capabilities for field staff, consistent with modern standards
for connected field operations. The City's expectation is that field staff should be
able to seamlessly perform their assigned work in the field, with or without
continuous network connectivity.
Specifically, the City is interested in mobile capabilities to include:
• Mobile Platform: A mobile-optimized interface — whether delivered via a
native application, progressive web application, or mobile-responsive web
platform — that supports full field workflow functionality on current iOS and
Android devices.
• Offline Functionality: The ability to access assigned work orders, account
information, and service data in the field without requiring continuous
network connectivity, with automatic data synchronization upon
reconnection
• Real-Time Updates: When connectivity is available, the ability to update
work order status, record service outcomes, and post field-generated
charges or credits in real time, with immediate visibility to back-office staff,
customer service, and billing staff
• GIS and Location Awareness: Integration with the City's GIS environment to
support location-based work assignment, navigation, and premise
identification in the field
• Field Data Capture: Support for photo capture, notes, and attachments
associated with field activities, including service confirmations, exception
documentation, and equipment condition
8.5 Work Order Management: The ability to view, update, and close assigned work orders in
the field, including solid waste service events, meter exchanges, turn-on/turn-off orders,
and collections activities. Does the City require multilingual support for the
customer portal?
City Response: The City does not prescribe multilingual support as a mandatory
requirement for the customer portal at this time; however, the City serves a growing
Spanish-speaking population and currently has limited bilingual customer service
capacity. As such, the City would view favorably proposals that include or support
Spanish-language capabilities within the customer portal and customer-facing
communications, including but not limited to bill presentment, account
management, payment processing, and automated notifications.
While multilingual support is not a standalone scored evaluation criterion,
proposals that demonstrate meaningful capability to serve limited English
proficiency customers will reflect favorably in the City's overall assessment of
customer experience and community accessibility.
9. Utility Billing
9.1 What is the exact number of current utility accounts by service type (water,
wastewater, stormwater, solid waste)
City Response: The City currently has 15,177 active water meters, which correlates
to the number of water, sewer and stormwater accounts as well. There are a
handful of each that are flat rate only. We also have approximately 1,750 organics
accounts, 8,800 recycling accounts and 12,600 residential garbage accounts and
700 commercial garbage accounts.
9.2 Can you please confirm the total number of active utility billing accounts
currently being billed across all services?
City Response: See response to 9.1.
9.3 What is the expected annual growth rate in customer accounts over the next 5–
10 years?
City Response: The City does not have a formally adopted forecast of customer
account growth over the next 5–10 years. Recent development trends have included
a higher share of multi‑family (apartments/condos) relative to single‑family
residential. The City’s estimate of approximately 2% annual growth is a rough
planning assumption rather than a precise projection.
9.4 What is the expected frequency of billing cycles across different services?
City Response: The City’s utility billing is processed on a monthly cycle for
customer bills. In addition to the standard monthly billing cycle, the City generates
final bills (e.g., move-out/termination bills) approximately 2–3 times per month.
Special assessments are billed once per year, with payment typically structured as
two installment payments (two due dates/collections) associated with the annual
assessment billing.
9.5 What payment processors and gateways are currently used, and are there plans
to change them?
City Response: The City currently uses InvoiceCloud for payment processing and
customer payment channels, including credit card payments, IVR, pay-by-text, and
online bill presentment and payment. This solution has generally met the City's
payment processing needs and supports a range of customer payment options.
However, the City has identified operational challenges related to account identity
management within the current payment processing environment. Specifically, in a
rental-intensive service area with a high volume of property management
companies managing multiple accounts, the City requires that payment processing
and customer portal functionality be anchored to a unique account or premise
identifier rather than an email address. The use of email as a primary identifier has
created risk in scenarios where a single email address is associated with multiple
accounts — for example, inadvertent changes to autopay or banking information
affecting multiple accounts simultaneously. The City expects that the proposed
Utility Billing solution and any associated payment processing platform will support
account-level identity and access controls that prevent cross-account changes and
protect customers from unintended modifications to their payment settings.
9.6 The City is open to vendor recommendations regarding whether to retain InvoiceCloud or
transition to an alternative payment processing solution that better supports the City's
operational needs and provides a more consistent, enterprise-wide payment experience
across its future ERP, Utility Billing, and Permitting and Licensing environments. Vendors
should describe their recommended payment processing approach, any existing
integrations or preferred partnerships with payment processors, and how their proposed
solution addresses the account identity and access control requirements described
above. The RFP on page 2 references, “Other City billing needs.” Can the City
please identify what other types of billing a future CIS will need to support, other
than what was identified on page 25 and the functional requirements, which
identifies “property-specific attributes (such as square footage, acreage/lot size,
or linear frontage).
City Response: The other City billing needs refer to the assessment bills described
in section II.4.7.
9.7 Is the bill template managed by DataProse or does it reside in the current CIS?
City Response: The City’s bill template is currently managed by DataProse.
9.8 Modern cloud-native CIS systems have the ability to manage the bill template
natively. Would the City consider moving the management of the bill template
from DataProse to the new CIS system?
City Response: Yes.
9.9 If the City wants the new CIS system to manage the bill template, would the City
like to redesign its billing template with the transition to a modern cloud-native
CIS system?
City Response: At this time, the City does not have a predetermined preference
regarding a full redesign of its billing template as part of the transition to a new CIS.
The City is generally satisfied with the current billing template provided by
DataProse, and any future solution would be expected to deliver billing statements
that are at least comparable in clarity, usability, and customer experience.
That said, if the proposed system manages the bill template natively, the City is
open to considering refinements or modernization opportunities, provided they
meaningfully improve readability, accessibility, or communication with customers
and do not reduce functionality or introduce confusion.
9.10 Can the City provide the exact stormwater billing formula currently in use —
specifically the flat monthly charge per ERU, the variable charge calculation
method, and the credit calculation for eligible properties?
City Response: Information on the stormwater billing formula is available at
https://www.bozeman.net/departments/utilities/stormwater/learn-about-my-
utility-bill
9.11 For the ~160 metered-sewer-only accounts where water reads are provided by
another provider or City meters on well water, how are those reads currently
delivered to the City for billing — customer self-report, manual City staff reading,
or automated file from another provider?
City Response: To date, the City has installed one meter for metered‑sewer‑only
accounts, with additional meters expected to come online over the summer. These
meters are City‑owned and will be read by the City using the same methods
employed for other City meters. Specifically, meter reads will be collected either
through the City’s gateway tower network where available, or via radio‑frequency
(RF) collection by City meter staff.
9.12 Does the City bill commercial solid waste compactor service, and if so, is it billed
by pickup frequency, weight, or flat monthly rate? How are temporary roll-off
dumpsters billed — per pull, monthly rental, or both?
City Response: Regular commercial dumpsters are billed based on the dumpster
size and pickup frequency on a consistent monthly rate.
Temporary dumpsters are billed based on the contents of the dumpster (yard
waste, household, construction waste, etc.) and the size of the dumpster. If a
temporary dumpster is kept longer than a week, a daily rental rate is also charged.
Roll-off dumpsters are billed a service charge and disposal cost each time the
dumpster is emptied.
9.13 Is the Downtown Business Improvement District (BID) component unit included
or excluded from the UB implementation scope? If included, how are BID
assessments currently calculated and billed?
City Response: The City anticipates transitioning this assessment to County and
can now be considered out of scope for this project. If this functionality reverts to
City management, the City will work with Selected Vendor to update the scope
accordingly.
9.14 Modern cloud-native CIS solutions have their own native point of sale capability
within the CIS. Will the City consider deploying CIS-based POS to support
centralized cashiering enterprise wide?
City Response: Yes, the City is open to considering a point‑of‑sale (POS) capability
for utility-related receipting, particularly if it improves usability, supports a
consistent customer experience, and reduces reconciliation effort.
However, the City’s broader objective is to implement an enterprise‑wide
cashiering solution that supports payments across multiple revenue‑generating
functions (e.g., utility bills, dog licenses, permits, and miscellaneous accounts
receivable). The City has included enterprise cashiering requirements within the
ERP procurement and will evaluate solutions based on their ability to support
centralized cashiering and a unified payment experience across City services.
Respondents should therefore describe (a) whether their CIS POS can support
utility receipting, (b) how it would integrate with an enterprise cashiering model
(including real‑time or near‑real‑time posting, end‑of‑day close, and reconciliation),
and (c) whether they recommend a centralized approach using an enterprise
cashiering solution versus leveraging CIS‑native POS for utility transactions. The
City will consider Respondent recommendations and integration feasibility when
determining the final approach.
9.15 What payment gateway does the City currently use for utility payments, and what
lockbox bank and file format specification is in use? Does the City intend to retain
existing payment contracts or rebid payment services as part of this
procurement?
City Response: The City currently uses InvoiceCloud as its primary payment
platform for utility payments, supporting online bill payment, credit card
processing, IVR, pay-by-text, and additional payment channels. The City does not
have visibility into the specific underlying payment gateway utilized by InvoiceCloud
as part of its processing infrastructure.
The City does not currently utilize a bank lockbox service. Check payments received
by mail are processed in-house by City staff. In-house payment processing
represents less than one-third of total utility payment volume, with the majority of
payments processed through InvoiceCloud's platform.
Regarding the City's intent to retain or rebid payment services, the City has not
made a final determination at this time. The City is generally satisfied with its
current payment processing arrangement and is not actively seeking to replace it;
however, the City is open to vendor recommendations regarding alternative
payment processing solutions that may better support the City's operational needs,
address account-level identity and access control requirements, or provide a more
consistent enterprise-wide payment experience across the City's future Utility
Billing, ERP, and Permitting and Licensing environments. Please also refer to the
City's response to 9.5 for additional context regarding current payment processing
and the City's expectations for the new Utility Billing solution.
9.16 Is the City open to replacing its incumbent payment processing vendor, Invoice
Cloud? If yes, can the City provide the following volumes information to enable
an accurate cost estimate:
i) What is the Utility's current fee model, Absorbed (Utility Funded) or a
Convenience (Customer Paid) fee model?
ii) Is the desired plan to keep the existing model or to change?
iii) What payment cards/types do you currently accept?
iv) Please provide the payment card volume (by card type if possible) for each month
for the last 12 months (a Merchant Statement or monthly invoice from the
incumbent processor will have this information)
v) Do you have a maximum payment amount for card and/or ACH transactions? If
yes, what is the amount?
vi) How many ACH transactions are processed annually?
vii) How many e-checks transactions are processed annually?
viii) What is the APA (Average Payment Amount) per month per customer?
ix) What is the desired payout frequency (transaction date +1, or transaction date
+2)?
x) Is Interactive Voice Response (IVR) payment required? Does the Utility accept any
other forms of payment (i.e., digital wallets, PayPal, google pay, Venmo, apple pay
etc.)?
City Response:
i) Customers currently pay a $2.95% fee for credit card payments, or $.95 cents for
ACH/IVR payments. Customer on autopay with a checking or savings account do not
pay any fee. The city pays .40 cents for invoice presentment for paperless customers,
and .40 cents for ACH Auto-pay customers. This currently costs the city approximately
$7,500/month.
ii) The City is open to alternative constructs and providers.
iii) The City currently accepts Visa, Mastercard, Discover, Amex, PayPal, ApplePay,
GooglePay Pay by text, Venmo, Online Bank Direct, and IVR.
iv) Over the past 12 months, the City received 249,698 online payments. Of those, 48,036
were credit cards (22,621 were autopay credit cards). The City does not have access to
volume by card type at this time.
v) The City does not have a maximum payment amount. The largest ACH payment was
$12,845 and the largest credit card payment was $11,095.
vi) There were 201,662 ACH payments. 112,536 were Autopay ACH payments, and 89,126
were non-autopay ACH payments, including online bank direct (OBD) payments.
vii) The volume of e-checks is not provided at this time.
viii) The average bill amount for credit card payments is $117.44. The average bill for ACH
was $158.71.
ix) The City currently receives payments deposited within 2 business days.
x) The City currently leverages IVR and would like to continue to do so. Please see
response to item (iii).
9.17 Does the City currently offer any online self-service capabilities for utility
customers (bill payment portal, service request forms)? If yes, approximately how
many active registered customers are there, and what is the City's target portal
enrollment rate at go-live?
City Response: The only self-service capabilities are related to payments through
InvoiceCloud.
9.18 Does the City have interval meters, or meters capable of receiving remote
commands?
City Response: No.
10. Special Assessments
10.1 Are special assessments currently billed once or twice per year? What is the
installment payment structure — fixed monthly, semi-annual lump sum, or
customer-elected installment plan?
City Response: Special Assessments are billed once a year but are due in two
installments—November 30th & May 31st of each year. The City bills a consistent
principal amount with a declining interest payment. SA loans "SIDs" can be paid off
at any time during the life of the loan. Interest is always charged through the next
bond call date for a payoff. Other special assessments can be paid in full in
November, or at any other time during the year. Delinquent assessments are charge
a 2% penalty and 10% annual interest.
10.2 When property ownership changes, does the assessment lien currently transfer
to the new owner automatically through a system process, or does it require a
manual action by City staff?
City Response: Property ownership is currently maintained in the legacy system’s
Land Database. The SA loan automatically transfers to the new owner of the
property.
10.3 Is all special assessment data currently in Naviline, or is any of it maintained in a
separate system, spreadsheet, or county assessor database?
City Response: Special assessment data is currently maintained in Naviline.
11. Data Conversion, Historical Data, and Records Retention
11.1 It is stated that 17,000 bills go out on a monthly basis, is this accurate to the
number of active accounts that will be used within Muni-Link? (For example, there
may be active accounts where service orders are being created, but not billed at
all or monthly, only billed once a year or quarterly and not included in the 17,000
monthly count, etc.)
City Response: Yes, this is a roughly accurate number of bills that go out monthly.
Most bills include both Water / Wastewater and Solid Waste. About 2,000 bills are
Solid Waste only. Ideally, the City would like to include any charges related to
service requests or ad-hoc charges to be included on the monthly bill and not billed
separately. In addition, there are final bills that may go out outside of the usual
billing cycle, as well as accounts that may need additional review before bills are
issued. Ideally this is 20 - 40 off-cycle bills per month.
11.2 To add onto this it’s stated that there are 20,500 special assessment accounts, is
it safe to assume these are active accounts that something is being done with?
City Response: Yes, this is the approximate number of properties subject to
special assessment bills. These are billed once per year with two payment
installments due per year.
11.3 Can the City provide detailed data volumes for historical data to be migrated
(years, size, records)?
City Response: The City has provided its best available information regarding
historical data volumes, record counts, and retention periods in Attachment 4.3 –
Data Conversions, which identifies the data elements to be converted and includes
estimated record counts (where available) and expected history (e.g., active
records, prior two years, prior three years).
At this time, the City does not have more granular system-level metrics (e.g., table
sizes, file sizes, or detailed row counts by legacy database object) beyond what is
documented in the attachment. Respondents should use Attachment 4.3 as the
basis for sizing, scoping, and pricing data conversion activities, and may state any
additional conditions used in developing their conversion approach.
If Respondents believe additional historical data should be converted, or that
alternative retention periods would better support operations, those
recommendations should be clearly described in the attachment and included in
fixed-fee pricing, consistent with the RFP instructions.
11.4 Regarding the Data Conversion requirements. The City asked for “active
customers + closed customers in the last 2 years.” Can the City please clarify that
it wants all years for “active customers”, or will it allow for 3 years of data to be
converted? We find that 3 years of records are sufficient to bring over into the new
CIS. Data greater than 3 years can be brought over into CIS’s purpose-built Data
Archive which is available to staff for historical reference. This approach de-risks
the data conversion process, reduces complexity, and minimizes extraneous
costs.
City Response: Attachment 4.3 is intended to indicate that the City expects all
active customer accounts to be converted into the new system as of go‑live (i.e., the
full set of active customer master records, regardless of when an account was
established), along with closed customer accounts from the last two (2) years. With
respect to historical transactional data associated with active accounts (e.g.,
billing, payment, or usage history), the City recognizes that Respondents may
recommend a reasonable lookback period that supports day‑to‑day operations
while managing conversion complexity. The City will accept a proposed approach
that converts a limited period of transactional history (e.g., three (3) years), provided
the proposed scope meets operational needs at go‑live and is clearly described in
the Respondent’s proposal.
11.5 The City has not established a requirement for Respondents to provide a separate data
archival or legacy access solution for older historical records. However, Respondents
may describe recommended approaches for retaining access to non‑converted
historical data as optional guidance. Will the City provide direct read-only database
access to Naviline for data extraction, or will data be provided through Naviline's
built-in export utilities? What format does Naviline support for data export?
City Response: The City’s current Naviline environment includes standard H5
screen‑level export and reporting utilities, which are available for most application
screens. These exports are generated through the Naviline application layer and
typically reflect the results of report‑level joins rather than full underlying database
tables. While these utilities are available and used today, they may not capture
complete table‑level content for all data elements.
The City believes it can support a direct read only connection or a type of DB2
export, provided that such access is appropriately structured, documented, and
guided by the City’s IT staff to ensure security and data integrity.
11.6 How many years of billing history does the City require migrated into the new
system for Day One access by City staff and customers through the portal?
City Response: Attachment 4.3 identifies the historical data it expects to be part of
go-live.
11.7 Does the City want historical work order records migrated from Naviline into the
new system, or is it acceptable to maintain Naviline in read-only mode for
historical work order reference during the transition period?
City Response: At this time, the City does not anticipate migrating historical work
order records from Naviline into the new system. Work order history related to
water/sewer and solid waste is currently incomplete and has been tracked in
multiple places, including Naviline and spreadsheets, which reduces the value and
increases the risk of attempting a comprehensive historical conversion.
The City may request Respondents to support conversion of any open/in‑process
work orders (and related operational data necessary for continuity) if work order
functionality is in scope for the proposed solution.
12. Interfaces, Integrations, and Technical Architecture
12.1 RAMS Pro: Is this a one-way or two-way integration? If one-way please explain if
data will be flowing into or from Muni-Link.
City Response: Per Attachment 3.2 – Interfaces, the City has provided its current
understanding of interface needs based on existing business processes and
systems. The City anticipates that final interface requirements and data flows will
be refined during implementation discovery and design; therefore, the information
provided should not be interpreted as a final or prescriptive scope for the
integration.
At this time, the City anticipates a bi‑directional integration between the Utility
Billing system and the Solid Waste collections service system (RAMS Pro). From the
Utility Billing system to RAMS, the City anticipates transmitting relevant customer,
property, and service information, including the initiation of service requests or
work orders as needed. From RAMS to the Utility Billing system, the City anticipates
receiving tote/container information (e.g., container type, size, serial number),
confirmation of completed service requests or work orders, and ad‑hoc fees
generated as a result of field activities (e.g., excess waste or bulk pickup). The City
expects to work collaboratively with the selected vendor to validate use cases,
confirm system‑of‑record responsibilities, and finalize interface scope, data
elements, and integration methods during implementation.
12.2 RAMS Pro: Please confirm this is an API integration?
City Response: At this time, the City does not have a prescriptive requirement
regarding the specific integration method (e.g., API versus file‑based) for the RAMS
Pro integration. While the City anticipates that an API‑based integration may be a
logical and effective approach to support timely and accurate data exchange, this
assumption is not intended to mandate a specific technical solution.
Final decisions regarding integration architecture, data exchange frequency, and
technical design will be determined collaboratively during implementation
discovery to ensure the approach is both feasible and aligned with system
capabilities and business needs.
A representative from RAMS Pro noted, “We typically write programs to API into the
other provider for needed data exchanges. We have various rest APIs that we have
done, we have file share interfaces similar to what is in place at Bozeman now.
12.3 RAMS Pro: What data will be pushed to or taken from Muni-Link?
City Response: Please response to 10.1.
12.4 RAMS Pro: Does the integration need to be completed by initial Go-Live or within a
certain time frame of the system Go-Live? (This would effect the Implementation
timeline)
City Response: The City intends for the RAMS Pro integration to be implemented as
part of the initial Utility Billing go‑live, as this integration supports core solid waste
operations and billing processes. The City does not currently anticipate deferring
this integration to a post‑go‑live phase, as doing so would introduce manual
workarounds and operational inefficiencies.
12.5 RAMS Pro: What version of RAMS Pro is in use, and does it expose a REST API or
other programmatic interface for external system integration?
City Response: The City currently uses the 2026 Release of VRPE 10of RAMS Pro.
See response to 12.2 regarding system integration.
12.6 RAMS Pro: If no API is available, what file formats does RAMS Pro support for
importing and exporting work order and charge data (CSV, XML, fixed-width,
other)?
City Response: RAMS Pro supports (1) Various Flat files, such as CSV, XLS, XLSX,
DBF, MDF, TXT, Tab delimited, space delimited; (2) various forms of SON file import
and exports; and (3) xml file formats
12.7 RAMS Pro: When a solid waste ad hoc charge is recorded in RAMS Pro today, what
customer or property identifier is captured — customer account number, service
address, parcel ID, or another field — and can this identifier be used to reliably
match records to billing accounts?
City Response: Currently RAMS Pro uses the Customer ID. Naviline uses a
customer ID and a location ID. Ideally, it would be best to match both pieces which
is account #: CID-LID. This would help keep some mistakes / inconsistencies from
occurring.
12.8 Is RAMS-pro used for both regularly scheduled pickups of solid waste as well as
temporary roll-off container work orders?
City Response: RAMS Pro is used for routing of regularly scheduled service, as well
as the system to record ad hoc charges, which are then exported to be manually
added to the Customer’s bill. Roll-off work orders are generally requested via
phone call, and a work order is manually created.
12.9 CityWorks: What version of Cityworks is deployed (AMS, PLL, or both), and which
specific work order types are currently managed in Cityworks versus other
systems?
City Response: The City is currently on 15.8.9 but will be upgrading to 23.x. Most
work orders in Cityworks are manually created after the fact for documentation.
12.10 CityWorks: Is this a one-way or two-way integration? If one-way please explain if
data will be flowing into or from Muni-Link.
City Response: At this time, the City does not have a prescriptive requirement
regarding whether an integration with Cityworks would be one‑way or two‑way. The
need for, and design of, a Cityworks integration is expected to depend on the
capabilities of the proposed Utility Billing (UB) solution—particularly with respect to
service request/work order management and asset or inventory tracking.
If the proposed UB solution includes robust, native functionality for managing
utility‑related service requests and work orders (e.g., new water service, meter
installations, service investigations) as well as inventory tracking (e.g., meter types
and quantities), the City may determine that a Cityworks integration is not required
for those functions. However, if the proposer recommends Cityworks as the most
effective system of record for work orders and/or inventory, the City would expect
an integration between the UB system and Cityworks. In such a case, Vendors
should describe their recommended integration approach, including data flows,
directionality (one‑way or bi‑directional), system‑of‑record considerations, and how
service request status, asset information, and completion events would be
synchronized between systems. Final decisions regarding integration scope and
design will be made collaboratively during implementation discovery.
12.11 CityWorks: Please confirm this is an API integration?
City Response: Please see response to 10.2, and the City has confirmed that
Cityworks does have API connectors.
12.12 CityWorks: What data will be pushed to or taken from Muni-Link?
City Response: Please see response to 10.6.
12.13 CityWorks: Does the integration need to be completed by initial Go-Live or within
a certain time frame of the system Go-Live? (This would effect the
Implementation timeline)
City Response: Yes, the City would expect this to be completed by go-live. Please
see response to 10.4 for additional context.
12.14 CityWorks: Does the City have a preference for utility billing-linked work orders
(meter issues, new service, disconnects) to reside in Cityworks or in the new UB
system's native work order module, or does the City expect the selected vendor
to recommend the best approach?
City Response: Please see the Challenges to Solve section of the RFP.
12.15 ESRI ArcGIS: Does the integration need to be completed by initial Go-Live or
within a certain time frame of the system Go-Live? (This would effect the
Implementation timeline)
City Response: Yes, the City would see this as an imperative integration and expect
this to be completed by go-live. Please see response to 10.4 for additional context.
12.16 ESRI ArcGIS: Which ESRI product is deployed — ArcGIS Online, ArcGIS Enterprise
(on-premises), or ArcGIS Server? What authentication method is used for REST
API access (token-based, OAuth 2.0, API key)?
City Response: The City currently deploys a combination of ArcGIS Enterprise (on-
premises), ArcGIS Online, and ArcGIS Server as part of its enterprise GIS
environment. The City is not able to confirm the specific REST API authentication
method at this time, as the relevant technical stakeholders were unavailable during
the preparation of this addendum. If this information becomes available prior to the
proposal due date, the City will communicate it through a subsequent addendum.
12.17 ESRI ArcGIS: Are stormwater ERU values and impervious area attributes currently
stored within the ESRI GIS system, or are they maintained in Naviline or external
spreadsheets?
City Response: They are currently maintained in Naviline.
12.18 ESRI ArcGIS: Are special assessment parcel attributes (square footage, linear
frontage, district membership) currently in ESRI and linked to the active parcel
layer, or does this data require migration from another source before SMART360
can consume it?
City Response: The parcel attributes are currently maintained in a data table in
Naviline and can be consumed by ESRI.
12.19 Neptune360: What version of Neptune360 is currently deployed, and does it
expose a documented REST API for third-party CIS integration? If yes, can API
documentation or a sandbox endpoint be provided during the Q&A period?
City Response: The City currently utilizes Neptune 360 as its meter data
management and AMI platform, deployed as a cloud-based SaaS solution updated
on a regular basis by the vendor. The City can confirm that Neptune 360 exposes an
API that the City has utilized for specific data access purposes. The City is not in a
position to share API documentation through the RFP process at this time. Final AMI
integration requirements, data exchange specifications, and technical architecture
will be defined collaboratively with the selected vendor during implementation
discovery, at which point appropriate access and documentation will be facilitated.
The City expects that qualified Respondents will have prior experience integrating
Utility Billing platforms with Neptune 360 or comparable AMI and meter data
management systems, and should be capable of providing a professionally
informed, fixed-fee integration estimate based on that experience. Proposed
integration pricing should reflect a reasonable and realistic assessment of scope,
effort, and complexity — inclusive of appropriate contingency — and should not be
conditioned on the receipt of API documentation not yet available. The City expects
proposed integration fees to remain firm subject to clearly stated scope conditions,
and will scrutinize any post-award change order requests that are inconsistent with
the level of effort a qualified and experienced vendor should have reasonably
anticipated at the time of proposal.
Vendors should clearly document any conditions underlying their integration pricing
and identify scenarios that would constitute a material change in scope warranting
a contract modification. The City will evaluate the reasonableness and
completeness of stated assumptions as part of its overall cost assessment.
12.20 Neptune360: Does the City currently use Neptune360's remote
connect/disconnect capability, and if so, what percentage of the ~15,250 meters
support remote valve operation?
City Response: The City does not currently utilize that capability for its water
meters.
12.21 Neptune360: What is the current frequency and method for AMI data delivery to
the billing system — daily automated file transfer, real-time API push, or
scheduled batch upload? What file format is currently used (XML, CSV,
proprietary)?
City Response: Currently, monthly meter reads are delivered from Neptune 360 to
the City's legacy Utility Billing system via a scheduled batch upload on a monthly
billing cycle basis. The City operates a hybrid metering environment in which the
majority of meters are read via AMI, while a portion of meters are still collected via
mobile/drive-by reading methods. The specific file format used for the current batch
upload is not known at this time and will be confirmed during implementation
discovery.
For final reads and on-demand reads — such as those required for account
closures or property sales — the current process requires staff to manually look up
the read in Neptune 360 and enter it into the billing system. This manual process
represents a known operational inefficiency that the City expects the new Utility
Billing solution to address through improved integration with Neptune 360.
12.22 For the Challenges to Solve requirement (Attachment V.4.5) on work order and
service request integration: does the City expect a single recommended
approach (UB native work orders OR Cityworks integration) or will a hybrid
recommendation — UB native for billing-linked orders, Cityworks integration for
infrastructure orders — be acceptable?
City Response: The City is open to any recommended approach for integrating
service requests and work orders across Utility Billing (UB), Cityworks, and other
systems, as described in Attachment V.4.5 – Challenges to Solve. The City’s
primary objective is to provide a consistent and streamlined customer experience
for utility‑related service requests, while also supporting effective internal work
management.
12.23 Confirming the City is open to optionality in terms of approach to managing work
/ service orders specific to utilities -- I.e. Either integration with Cityworks or
proposing our integrated field service application.
City Response: Yes, the City is open to optionality.
12.24 Are there any legacy system dependencies that must remain operational post-
implementation?
City Response: At this time, the City does not anticipate requiring legacy systems
to remain operational for ongoing transactional processing following
implementation of the new solution. The City’s intent is that the selected
solution(s) become the system(s) of record for in‑scope functionality at go‑live.
That said, the City recognizes that certain legacy systems may be maintained in a
read‑only or limited‑access capacity for a defined period post‑implementation to
support historical reference, audit requirements, or records retention, where
applicable. Any such transitional use would be intended to minimize operational
disruption while the City fully transitions to the new system environment.
12.25 Are there any specific reporting tools or BI platforms currently in use that must be
integrated?
City Response: The City currently leverages Power BI to build many reports and
sees value in the ability to continue to use that tool to build reports from different
sources, including Utility Billing.
12.26 The City requested an integration with Power BI. Will the City allow CIS vendors
who have their own native business intelligence solution to propose their own
application in lieu of an integration to Power BI? De-scoping this integration will
reduce integration costs.
City Response: The City’s intent in requesting integration with Power BI is to
support a centralized, enterprise‑wide reporting and analytics environment that
allows staff to aggregate, analyze, and visualize data across multiple systems (e.g.,
CIS, ERP, Permitting and Licensing) in one consistent reporting platform. This aligns
with the City’s current reporting practices and internal expertise.
The City recognizes that solutions include native or embedded business
intelligence tools. Respondents may propose such tools as an optional alternative,
provided they clearly demonstrate how data from the system would still be made
available for consolidated, cross‑system reporting (e.g., via Power BI or an
equivalent enterprise aggregation approach). A system‑specific BI tool that
operates in isolation and does not support enterprise‑wide aggregation would not,
by itself, meet the City’s objectives.
12.27 Does the City require integration with any additional systems not listed in the
RFP?
City Response: At this time, the City is not aware of any additional system
integration requirements beyond those identified in the RFP and associated
attachments. Respondents should base their pricing and proposed scope on the
systems listed in the solicitation.
The City recognizes that additional integration needs may be identified during
implementation planning or discovery. If new integration requirements are
identified that were not reasonably inferable from the RFP materials, the City
acknowledges that such work would constitute additional scope and would be
addressed through a mutually agreed‑upon scope change and pricing adjustment,
consistent with the contract terms.
12.28 In the document "26 - Instructions - Bozeman Utility Billing Software Services
Implementation RFP 3", there are future states for the interfaces for the
applications listed. Do all of the applications listed support the BZN Envisioned
Future state? Where the future state method is API, do those applications have
documented REST APIs available. Do the applications support the authentication
and security protocols that the City requires for compliance for each envisioned
interface?
City Response: The City has documented both current and envisioned integration
methods for each listed system to the best of its current knowledge. The City's IT
team is actively working to confirm additional technical details — including API
availability and specifications — for the systems identified in Attachment 3.2. If this
information becomes available prior to the proposal due date, the City will
communicate it through a subsequent addendum.
For systems not yet selected — including the future ERP and Permitting and
Licensing platform — the City is not in a position to confirm specific integration
methods, API availability, or authentication protocols at this time, as those systems
have not yet been procured. The City's expectation is that all future enterprise
systems will be modern, cloud-based platforms that support current integration
standards. The City will work collaboratively with the selected Utility Billing vendor
and future system vendors to confirm integration compatibility and finalize
technical specifications during implementation planning.
12.29 Does the City require a specific hosting model (SaaS, on-premises, or hybrid), or
is it vendor-recommended?
City Response: The City does not require a specific hosting model (SaaS,
on‑premises, or hybrid) at this time. Respondents may recommend the hosting
model they believe is most appropriate for their proposed solution. That said, the
City’s overarching objective is to implement a solution that is scalable, resilient,
and futureproof, and that aligns with modern security, availability, and support
expectations.
12.30 Does the City have a preferred integration approach (e.g., API-first, middleware,
event-driven), or should Respondents propose their recommended architecture?
City Response: The City does not mandate a specific integration architecture (e.g.,
API‑first, middleware‑based, or event‑driven) at this time. Respondents should
propose the integration approach they recommend based on their solution
architecture and experience. That said, the City’s priority is to implement
integrations that are scalable, resilient, and futureproof, and that minimize
operational risk over time. Proposed integration approaches should support clean
system upgrades, avoid brittle point‑to‑point dependencies, and reduce the
likelihood that routine system updates or version changes would disrupt
integrations.
12.31 Does the City have a desired middleware platform for system integration, or can
the vendor propose an integration solution?
City Response: Please see response to 12.30.
12.32 The City has proposed several new integrations, which of these are required at
go-live for utility billing?
City Response: The City has provided an Interfaces Attachment outlining its
anticipated integration requirements for Utility Billing, including which integrations
are expected to remain in place and which legacy interfaces may be retired.
Respondents should assume that the integrations identified in the Interfaces
Attachment as in scope are required at go‑live and should be included in the
proposed approach and pricing.
That said, the City recognizes that Respondents may recommend alternative
integration approaches based on solution architecture, operational efficiency, or
reduced complexity. If a Respondent recommends modifying, deferring, or
replacing one or more of the anticipated integrations, the rationale, proposed
alternative, and implications (including impacts to operations, timing, and cost)
should be clearly described. The City is open to evaluating such recommendations
as part of its best‑value assessment.
12.33 For those integrations the City plans to keep, are there any planned upgrades to
these systems prior to go-live of the utility billing solution?
City Response: At this time, the City anticipates upgrading Cityworks and ESRI and
is not aware of any other currently planned upgrades.
12.34 What level of customization vs. configuration is acceptable to the City?
City Response: The City’s general preference is to leverage configuration rather
than customization wherever practical. Modern cloud‑based solutions offer
significant configurability that allows organizations to meet business needs while
preserving upgradeability, supportability, and long‑term sustainability.
The City recognizes that excessive customization can increase implementation risk,
complicate system upgrades, and elevate ongoing maintenance costs. Accordingly,
Respondents should assume that standard functionality and configuration options
are the preferred means of meeting requirements, and that business process
adjustments may be considered to align with system best practices.
That said, the City acknowledges that limited customization may be appropriate in
cases where requirements cannot be reasonably met through configuration alone
(e.g., statutory or regulatory requirements).
13. Technical and Security Requirements
13.1 What are the specific performance expectations (e.g., response time, batch
processing windows)?
City Response: At this time, the City has not established specific numeric
performance thresholds (e.g., precise response times or batch processing
windows). The City expects the proposed solution to perform in line with
industry‑standard benchmarks for modern, cloud‑based systems, supporting
timely and responsive system operation for both end users and administrative
processes.
13.2 What cybersecurity standards or compliance requirements (e.g., NIST, CJIS)
must be met?
City Response: The City does not impose a unique or City‑specific cybersecurity
framework beyond what is described in the RFP and the Sample SaaS Agreement.
The City expects the proposed solution to meet industry‑recognized cybersecurity
standards and best practices appropriate for a modern, cloud‑based municipal
ERP/CIS environment.
13.3 Are there any specific disaster recovery (RTO/RPO) requirements?
City Response: At this time, the City has not established specific numeric Recovery
Time Objective (RTO) or Recovery Point Objective (RPO) thresholds. The City
expects the proposed solution to include industry‑standard disaster recovery
capabilities appropriate for a modern, cloud‑based ERP/CIS environment.
13.4 What level of system availability (uptime SLA) is expected?
City Response: Please see response to 13.1.
13.5 What are the expectations for ongoing system upgrades and version releases?
City Response: The City has not established a prescriptive upgrade or release
cadence beyond what is typical for modern, cloud‑based solutions. The City’s
expectation is to remain on current, supported versions of the software and to
benefit from ongoing enhancements and security updates, without allowing the
system to fall significantly behind supported releases.
At the same time, the City is mindful of the operational impact that frequent
updates can place on staff resources. Approaches that balance keeping the system
current with manageable change, predictable scheduling, and minimized disruption
to City operations are preferred.
14. Reporting
14.1 Are there any specific audit or compliance reporting requirements?
City Response: To the City’s knowledge, no, there are not specific audit or
compliance reporting requirements outside of standard audit needs.
14.2 How many critical go-live reports are listed in Attachment V.3.1, and are any
expected to require custom SQL development rather than the standard no-
code/low-code report builder?
City Response: The Reporting Attachment identifies a set of reports that represent
the information and business outcomes the City expects to have access to at
go‑live. These items are not intended to imply that each entry must be delivered as a
traditional, static “report” in a one‑to‑one manner.
The City’s priority is timely and reliable access to the information reflected in the
attachment, which may be delivered through a combination of standard reports,
dashboards, queries, inquiry screens, or other native system functionality,
depending on the capabilities of the proposed solution. Respondents should not
assume that custom SQL development is required unless they believe that a
specific information need cannot be met through standard or configured tools.
15. Questions from Pre-Proposal Conference (may be paraphrased)
15.1 The City noted in the RFP p. 2 that PDF document submission must comply with
WCAG Level A and AA. Can the City please clarify the exact WCAG provisions that
vendors must comply with. Will the City consider waiving this requirement, since
it is not currently clear to vendors which provision is specifically mandatory?
City Response: The City’s intent in referencing WCAG 2.1 Level A and AA is to
ensure proposals are submitted in an accessible, usable format to the extent
practicable. The City is not requiring Respondents to map or certify compliance to
specific WCAG success criteria at the individual provision level as part of proposal
submission. Respondents should instead use reasonable best efforts to provide a
searchable, accessible PDF (e.g., tagged PDF with logical reading order, selectable
text, meaningful headings, alternative text for key figures, and accessible tables
where applicable).
The City will not waive the accessibility expectation; however, the City also
recognizes that the accessibility of complex, graphics‑heavy proposal documents
may vary by tool and content. The City does not intend to deem a proposal
non‑responsive solely due to minor accessibility formatting issues, provided the
proposal is otherwise complete and readable. If needed for evaluation or
accommodation purposes, the City may request that a Respondent provide an
accessible version of its proposal (or specific sections) within a reasonable
timeframe.
15.2 Does the WCAG 2.1 AA compliance requirement in the submission instructions
apply to (a) the proposal document PDF itself, or (b) the proposed software
solution? If it applies to the software, will the City accept a documented
remediation roadmap with a contractual go-live conformance commitment as a
responsive approach?
City Response: The City has not yet distinguished separate accessibility
requirements for internal versus customer-facing functionality. At a minimum, the
City expects reasonable conformance with accessibility standards for both, with
particular emphasis on customer-facing interfaces and content where public
interaction is required.
The City recognizes that some internal administrative functionality may require
phased remediation or accommodations depending on the solution and use case.
Accordingly, the City will evaluate accessibility responses based on material user
impact, risk, and the practicality of proposed remediation, rather than treating
accessibility as an all-or-nothing compliance threshold at proposal submission.
15.3 Which specific interfaces must achieve full WCAG 2.1 AA conformance at go-live
— the customer-facing portal, staff desktop application, mobile field app, or all
three simultaneously?
City Response: The City is committed to ensuring that the proposed Utility Billing
solution supports accessible digital experiences for both customers and staff,
consistent with applicable accessibility standards. While the City has not
prescribed specific WCAG 2.1 AA conformance requirements by interface type at
this stage of procurement, the City expects that the proposed solution will
demonstrate a meaningful commitment to accessibility across all customer-facing
and staff-facing interfaces, including the customer portal, staff desktop application,
and mobile field application where applicable.
Vendors are requested to describe their current level of WCAG 2.1 AA conformance
across all proposed interfaces, including any known gaps, remediation plans, and
expected timelines for achieving full conformance. The City will evaluate vendor
accessibility commitments as part of its overall assessment of the proposed
solution and will expect the selected vendor to work collaboratively with the City to
prioritize accessibility improvements — particularly for customer-facing interfaces
— as part of the implementation and post-go-live roadmap.
15.4 Will the City accept a VPAT (Voluntary Product Accessibility Template)
documenting current conformance status and a phased remediation schedule,
submitted alongside the proposal?
City Response: Yes. The City will accept a Voluntary Product Accessibility Template
(VPAT) documenting the solution’s current accessibility conformance status, when
submitted alongside the proposal.
If the VPAT identifies accessibility gaps, the City will consider a phased remediation
plan as a responsive approach, provided that the plan clearly includes:
• Identification of known non-conformances and affected components,
• A time-bound remediation schedule with defined milestones,
• A contractual commitment to achieve required conformance for defined
components, and
• Clarity on how remediation progress will be validated and communicated.
Respondents should not assume that submission of a VPAT alone is sufficient.
Proposals relying on phased remediation should clearly distinguish between
minimum accessibility expectations at go-live (particularly for customer-facing
functionality) and post-go-live remediation commitments. Remediation
commitments must be realistic and enforceable, rather than aspirational or
roadmap-only statements.
The City will evaluate accessibility responses—including VPATs and remediation
plans—based on transparency, practicality, and risk, consistent with a best-value
procurement approach.
15.5 Due date for responding to vendor questions may change. Will that impact the
proposal due date too?
City Response: If the volume of questions results in the City not being able to
deliver responses by April 17, it will consider updates to the proposal due date
accordingly.
15.6 Page 2 states that the proposal must be WCAG compliant. Can you explain what
that means?
City Response: Please see responses to 15.1 – 15. 4.
15.7 With the RAMS system, we would have to have a discussion with RAMS to
determine how an integration would work. How would you like vendors to handle
that? Do you want an estimate?
City Response: The City does not expect Respondents to contact RAMS-Pro (or
other third-party vendors) during the solicitation period to determine integration
specifics. Respondents should base their integration approach and pricing on the
information provided in the RFP, Interfaces materials, and addendum responses.
Respondents may state reasonable conditions regarding available integration
methods (e.g., API, file-based exchange, or other supported mechanisms).
Respondents should provide a high-level estimate and recommended approach for
integrating service requests to RAMS-Pro work orders (and any related data
exchange), including conditions about data elements, frequency, security, and error
handling. The City recognizes that detailed interface specifications and testing
plans will be refined during discovery and implementation planning after contract
award, at which time the City will coordinate discussions with RAMS-Pro and the
selected vendor(s) to confirm feasible integration methods, finalize requirements,
and align timelines. If Respondents believe integration feasibility or effort is highly
dependent on RAMS-Pro capabilities, they should clearly identify those
dependencies and propose options (e.g., baseline file exchange with an optional
API-based approach if available).
15.8 Can we contact RAMS directly to ask clarifying questions?
City Response: See response to 15.7.
15.9 Concerning Neptune MY360, do you know how many customers do we have?
City Response: The City does not use Neptune’s customer portal.
15.10 For email submission, are there size limitations?
City Response: The email size limitation is 25MB. If your files exceed that amount in
a single email, please coordinate with the Clerk’s office per the instructions in to
arrange a drop box folder.
15.11 Can you share more about how the City is thinking about the three systems, ERP,
UB and PLCE in terms of an architecture approach?
City Response: We are open to what gives us the best solution overall. We are open
to one solution that can address all areas, and we are open to a best-of-breed
approach.
Proposals submitted in response to each RFP will be evaluated independently,
using the evaluation criteria and committee defined for that specific solicitation.
Each evaluation committee will score proposals based solely on the merits of the
solution proposed for that functional area.
Separately, the City’s Steering Committee may facilitate discussions regarding
system interoperability, integration opportunities, and long‑term strategic
alignment across functional areas. These discussions will not alter evaluation
scores or rankings for any individual RFP. The City has no requirement or preference
for a single vendor across the ERP, Utility Billing, and Permitting and Licensing
systems.
Final award decisions will be based on each proposal’s ability to meet functional
and technical requirements, and may also consider overall operational value,
integration feasibility, and implementation risk, consistent with applicable
procurement rules.
15.12 What level of IT support is available for multi-solution integration management?
City Response: We are open to what gives us the best solution overall. We are open
to one solution that can address all areas, and we are open to a best-of-breed
approach.
15.13 Can you identify the vendor used for billing file exports?
City Response: We are currently using Data Prose.
15.14 The City noted that is open to vendors proposing their own solution for billing
export. Do we still need to price the integration with CityWorks if we are proposing
our own solution?
City Response: No.
15.15 What is the main push for the UB RFP?
City Response: The primary goal of the Utility Billing RFP is to procure a modern,
scalable, and long‑term sustainable utility billing solution that improves operational
efficiency, system reliability, and the overall customer experience. The City is
seeking to replace its existing utility billing environment with a solution that better
supports current business needs while positioning the City for future growth and
evolving service delivery models.
15.16 Does the City have any policies on the use of AI?
City Response: The City has a very basic AI policy that is mostly tied to
generative AI. We realize AI is coming pre-built inside systems, so we are still
working on how to deal with that. If you have AI in your proposed system, we
would like to know how it is used, and whether or not we have to use it or can
it be turned off.
15.17 How is the City managing special assessments now? Is there an integration with
another system? Is it a two-way system?
City Response: Please see responses in section 10.
Part II: PowerPoint from Pre-Proposal Conference
C I T Y O F B O Z E M A N , M O N T A N A
Utility Billing (UB) Software and
Implementation Services
Pre-Proposal Conference
April 7, 2026
T O D A Y ' S A G E N D A
1 Welcome & Purpose
2 City Overview & Context
3 Why We're Replacing the UB System
4 Implementation Goals
5 Key Challenges to Solve
6 Procurement Logistics
7 · Q&A & Next Steps The majority of our time together
01 · WELCOME & PURPOSE
Setting the Stage
Clarify Context
Help vendors understand the City's
environment, scale, and procurement
process so proposals are informed and
competitive.
Answer Questions
This is your opportunity to ask questions that
will sharpen your proposal. The majority of
this meeting is reserved for Q&A.
Scope is Set
This conference does not modify the RFP.
The scope, timeline, and requirements are
established —not up for negotiation today.
Material questions will be included in the question response addendum.
02 · CITY OVERVIEW & OPERATING CONTEXT
Scale & Complexity at a Glance
95 FTEs
70 for Water / Wastewater / Sewer
and 25 FTEs for Solid Waste
$57m
$47m for Water / Wastewater / Sewer
Enterprise Funds and $10m for the
Solid Waste Enterprise Fund
~17,000
Monthly Bills
~15,000
Water and Sewer Customers
~12,400
Residential Solid Waste Customers,
plus ~700 Commercial Customers
~20,500
Special Assessment Properties
03 · WHY THE CITY IS REPLACING ITS UB SYSTEM
Strategic Drivers for Change
The City's decision to replace its Utility Billing system is driven by a forward-looking
vision to modernize operations, improve transparency, and position Bozeman for
continued growth.
Modernization of aging legacy platform
Improve operational efficiency
Improve customer experience and self-service
Enable integration & “system of record” alignment
S U C C ES S I N 5 –1 0 Y EAR S
Real-time financial visibility
Transparent customer experience & self-service
Flexibility for policy, rate, and program changes
Audit-ready, secure data environment
Platform that scales with Bozeman's growth
04 · IMPLEMENTATION GOALS & GUIDING PRINCIPLES
How the City Will Approach This Project
Process Improvement First
This is not a lift-and-shift. The City is using this opportunity to
redesign and standardize business processes —not just
recreate the old ones.
Configuration Over Customization
The City will adopt best-practice configurations wherever
possible and looks for vendor support in advising on efficient
industry standard practices that meet City needs. Custom
development is a last resort.
Change Management Partnership
The City owns adoption and organizational change, but it will
look for vendor support with tools and training to drive buy-in
and adoption.
Clean Data Conversion
Data conversion will prioritize balances and clean master
records. Historical transaction migration will be scoped
carefully to control risk and cost.
Governance and standardization are core to the City's long-term UB success.
05 · KEY CHALLENGES THE CITY IS ASKING VENDORS TO SOLVE
Partnering to Solve Key Challenges
Understanding the City’s key challenges and providing clear, actionable guidance will be viewed favorably.
✓Integration with Existing Systems
Developing efficient integrations to reduce manual intervention,
duplicate work, and data misalignment, specifically with GIS and RAMS.
✓Data Access & Reporting
Self-service reporting without dependence on IT staff for ad hoc queries,
including integration with existing reporting tools.
✓
Service Requests & Work Order Management
Implementing best-practice service request workflows with native and/or
integrated systems to effectively manage work.
✓
Trusted Customer Portal
A modern, reliable customer portal to enable self-service, improve
transparency, reduce call volume, and meet rising customer expectations.
✓
Special Assessments
Supporting complex special assessment calculations, billing, payoff rules.✓
Exception Management
Reducing the time to analyze and assess exceptions.
06 · PROCUREMENT & EVALUATION LOGISTICS
Timeline and Key Terms
RFP Released
March 28
Pre-Proposal Conf
Today
Questions Due
April 10
Responses Issued
April 17
Proposals Due
May 4
Elevation
June 16
Demos
August 4 –6, 11 –12
Award
Early October
"Yes" Is Binding
A "Yes" response to a requirement commits your firm to delivering it. Do
not mark Yes unless you can fully comply.
Fixed Fee Contract
Fixed fees shall include all labor, hours, effort, and resources necessary to
complete the agreed-upon scope
Deliverables, Milestones, & Acceptance
Key work products (Deliverables) will require Bozeman review and approval
with defined acceptance criteria. Milestones drive payments and consist of
one or many Deliverables, work products, and/or events.
Questions
Ask! Do not assume! If you are unclear on a request or need more
information to accurately price this project, please ask!
Discovery
September 21 –22
0 7 · Q & A & N E X T S T E P S
Your Questions.
Written Questions
Submit all follow-up questions in writing to by April 10.
Addenda Posted
All Q&A responses will be documented and posted as an
addendum in the RFP portal on April 17 .
Today’s Questions
Material questions will be included in the question
response addendum.
Thank you for your interest in partnering with the City of Bozeman.