4-Attachment C - Functional Requirements.xlsx
XLSX spreadsheet 29 KB Posted
- Solicitation number
- HERR03272026
- Issued by
- Salt Lake County, Hildale City, Utah
About this file
This is a Functional Requirements attachment to a Request for Proposal (RFP) issued by the City of Herriman, Utah for utility billing software and professional implementation services. The document outlines comprehensive functional requirements organized into nine categories: General Functionality, Customer Account and Location Management, User Interface, Meters and Meter Reading, Billing Management, Financial Management/Cash Receipting, Delinquency Management, Service Order Management, and Reporting and Integration. The software must support approximately 30,000 unique customer accounts and 40,000 active meters, with capabilities including a user-friendly browser-based interface, online customer service portal, rate and fee management, meter reading integration with Neptune 360, multi-cycle billing, automated delinquency processing with shut-off notices, service order management with mobile dispatch functionality, and comprehensive reporting tools. The system must integrate seamlessly with SAP Business ByDesign (ERP), Neptune 360 (meter reading software), and ESRI GIS applications. Proposers must maintain four years of transaction and consumption history, support PCI-DSS compliance and personally identifiable information protection, provide technical support between 8:00 AM and 5:00 PM Mountain Time Monday through Friday, and maintain CASS certification for postal accuracy. The RFP submission deadline is April 30, 2026 at 5:00 PM MDT, with vendor demonstrations and interviews scheduled for the week of June 22, 2026, preferred vendor notification by the week of July 13, 2026, contract negotiations beginning July 20, 2026, and City Council contract award by September 9, 2026.
The RFP evaluation criteria allocate 40 points to functional and technical capabilities, 20 points to approach and methodology, 15 points to customer support, 15 points to vendor experience, and 10 points to cost. Proposers must provide detailed references from at least three utilities of similar size that have operated the proposed software for a minimum of two years and must complete a Conflict of Interest Disclosure Form. The City processed approximately 101,104 utility bills and 151,829 online payments in the most recent fiscal year. The current system operates Pelorus Methods platform with 15,529 active customer accounts (14,634 residential and 364 commercial) and 18,114 meters projected to grow to the specified thresholds. No specific set-aside designations or restrictions on organization types are indicated. Final contract value, pricing terms, implementation costs, and ongoing support pricing structures will be negotiated following vendor selection. The City reserves the right to reject any or all proposals and terminate negotiations if mutually acceptable terms cannot be achieved.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 3-City of Herriman Utility Billing Software 4-3-2026 Revised.pdf | ||
| 2-Exhibit B - Conflict of Interest Disclosure.docx | DOCX document | |
| 2-Exhibit A - Reference Form.docx | DOCX document | |
| 1-RFP - Utility Billing Software.pdf | ||
| 3-Exhibit A - Reference Form.docx | DOCX document | |
| 1-Exhibit B - Conflict of Interest Disclosure.docx | DOCX document |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Functional Requirements
| Response Indicators: When providing responses to the requirements in Attachment C , proposers shall use the following response indicators: | |
| S: Feature/Function is included in the current software release. | T: Feature/Function is not included in the current software release, and is not planned to be a part of a future software release. However, this feature could be provided with integration with a third-party system. |
| F: Feature/Function will be available in a future software release. | |
| C: Feature/Function is not included in the current software release, and is not planned to be a part of a future software release. However, this feature could be provided with custom modifications. | N: Feature/Function cannot be provided. |
| Attachment C - Functional Requirements | |||
| Req | Description of Requirement | Response | Comments |
| General Functionality | |||
| GT.1 | User-friendly, browser-based interface. | ||
| GT.2 | User defined fields and parameters. | ||
| GT.3 | Expedited (as few steps as possible) processes such as setting up new accounts, meter changes, creating service orders, delinquencies and penalties, and billing. | ||
| GT.4 | User defined security (ex: Full access, read only access, limited access) and administration of user access and password administration. | ||
| GT.5 | System administration including the ability to change or update field values within the system. | ||
| GT.6 | Technical support for hardware and software between 8:00AM and 5:00PM Mountain Time Monday through Friday. | ||
| GT.7 | Ability to interface with external cash receipting systems, ERP systems (general ledger), meter reading software, and GIS applications. The City uses SAP Business ByDesign (SaaS) for its ERP system, Neptune 360 for meter reading/read collection, and ESRI for GIS software. | ||
| GT.8 | Product should be able to link addresses and parcels, including stacked parcels. | ||
| GT.9 | Vendor should describe how PCI-DSS compliance is maintained. Vendor should describe how personally identifiable information (PII) is protected. | ||
| GT.10 | Online customer service portal with the following capabilities: | ||
| GT.11 | 1. Ability to view consumption (both numerical and graphical) | ||
| GT.12 | 2. Ability to view current and historical billings. | ||
| GT.13 | 3. Ability to view all payments made. | ||
| GT.14 | 4. Ability to make a payment | ||
| GT.15 | 5. Ability to setup autopay. | ||
| GT.16 | 6. Ability to request equal pay (levelized billing). | ||
| GT.17 | 7. Configure communication preferences (email, mobile, etc.). | ||
| GT.18 | 8. Ability to change mailing address and reset passwords. | ||
| GT.19 | 9. Provide an area to communicate messages. | ||
| GT.20 | Register for service, discontinue service, or transfer service. | ||
| Customer Account and Location Management | |||
| GT.21 | Ability to enforce business rules on all system transactions so user errors may be minimized. | ||
| GT.22 | Allow for documents (photos, letters, scanned documents, etc.) to be attached to an account and viewable by authorized system users. | ||
| GT.23 | Support at least 30,000 unique customer accounts. | ||
| GT.24 | Product should track customer classification and type of services provided. | ||
| GT.25 | Ability to view all customer account activity in one location, including, but not limited to: Read history, billing history, payment history, notes, etc. | ||
| GT.26 | Ability to make changes to customer accounts from customer account information screen. | ||
| GT.27 | Ability to define, add, change, and delete account types. | ||
| GT.28 | Ability to query an account based on various search criteria such as customer name, account number, parcel number, or service address. | ||
| GT.29 | Provide summary and detail level inquiry of customer accounts, consumption, and amount paid per year. | ||
| GT.30 | Provide user defined fields to be maintained for each record. | ||
| GT.31 | Ability for notes on accounts with ability to assign alert flags were needed. | ||
| GT.32 | Ability to provide an audit trail for changes to an account. | ||
| GT.33 | Support 4 years’ worth of transaction and consumption history. | ||
| GT.34 | Ability to track property owner as well as tenant. | ||
| GT.35 | Ability to transfer customer balances and other related information to a new account when a customer transfers to a new service address. | ||
| GT.36 | Ability to mark an account as an “internal” account. | ||
| GT.37 | Provide a CASSTM certification process to insure and maintain accurate postal information. | ||
| GT.38 | Ability to track information through the system by customer; ability to view all accounts a customer has had and current status of accounts. | ||
| GT.39 | Ability to track user defined events on an account (i.e., late notices, shut offs, and sent to collections). | ||
| GT.40 | Ability to track information through the system by property; ability to see all accounts at a given property. | ||
| User Interface | |||
| GT.41 | Ability to define, add, change, and delete rate code types and amounts. | ||
| GT.42 | Ability to define an effective date for rate tables and prorate charges based on the effective date. | ||
| GT.43 | Ability to define water and secondary water service rates that are consumption based, fixed, or tiered. | ||
| GT.44 | Ability to define storm drain fees that are fixed or based on square footage of impervious area of the parcel. | ||
| GT.45 | Ability to define solid waste rates and park fee rates that are fixed. | ||
| GT.46 | Ability to define distribution of fees to multiple general ledger accounts based on fee category or service type. | ||
| GT.47 | Ability to prorate customer charges for service to date of occupancy. | ||
| GT.48 | Ability to back date the date of occupancy. | ||
| GT.49 | Ability to define, add, change, and delete service types. | ||
| GT.50 | Ability to stop and start dates for individual fees on an account. | ||
| Meters and Meter Reading | |||
| GT.51 | Ability to define and add, change, and delete meter types. | ||
| GT.52 | Ability to maintain at least 40,000 active meters. | ||
| GT.53 | Ability to identify a meter by type size, serial number, manufacturer, location, installation date, and test date. | ||
| GT.54 | Ability to enter meter reading data through data entry screens from handheld devices or automated meter reading system. Preference will be given to systems that have existing interfaces with Neptune 360. | ||
| GT.55 | Automatic calculation of service consumption upon entry of meter reading with ability to edit readings. | ||
| GT.56 | Allow concurrent meter reading data entry of one route while processing billing for another. | ||
| GT.57 | Ability to maintain a list of vacant water accounts. | ||
| GT.58 | Ability to maintain meter readings and dates independent of customer or account changes. | ||
| GT.59 | Ability to enter a meter changeout without interruption of the billing cycle and final billing. | ||
| GT.60 | Ability to generate work orders based on meter reading exception messages and actions entered along with meter reading. | ||
| GT.61 | Ability to describe the location of the meter at the service location. | ||
| GT.62 | Ability to view the history of all meters that have been installed at a service location. | ||
| GT.63 | Ability to record unlimited notes for a meter. | ||
| GT.64 | Ability to define meter read types. | ||
| GT.65 | Ability to estimate meter reads based on user defined history preferences. | ||
| GT.66 | Ability to estimate reads by route or by cycle (mass estimates). | ||
| GT.67 | Ability to identify reads that were estimated versus actual. | ||
| GT.68 | Ability for system to automatically identify roll over readings based on meter setup. | ||
| GT.69 | Ability to change out meters at any time; ability to show separate individual meter readings (new and old meter) and consumption on billing. | ||
| GT.70 | Ability to change meter reading sequence without changing customer account number. | ||
| GT.71 | Allow user to flag individual accounts for which zero consumption is not considered to be an exception. | ||
| GT.72 | Print meter route pages in customer number or route sequence number order. | ||
| Billing Management | |||
| GT.73 | Ability to list one time or turn off fees separately on invoice. | ||
| GT.74 | Ability to graphically display consumption history for an account. | ||
| GT.75 | Ability to display average consumption by month and day for an account. | ||
| GT.76 | Supports single or multi cycle billing system. | ||
| GT.77 | Provides a complete or exception only billing pre-list for review prior to bill generation. | ||
| GT.78 | Allows printing of multiple cycles in one billing run. | ||
| GT.79 | Generates one utility bill covering all services and charges and itemizes charges separately. | ||
| GT.80 | Maintains a file of comments for inclusion on utility bills, reminder notices, or shut off notices. | ||
| GT.81 | Ability to send automated email or text communications to customers based on city-defined parameters (delinquent accounts, late payment notices, readings out of bounds, etc.). | ||
| GT.82 | Provides user defined free form messages on bills. | ||
| GT.83 | Ability to send bills or messages to mobile devices. | ||
| GT.84 | Capable of including, but not limited to, the following information on the bill: Billing date, account number, service period, current meter reading, prior meter reading, actual or estimated read, consumption billed, itemized charges, balance forward, amount due, due date, numerical and graphical prior same period usage and average gallons used per day. | ||
| GT.85 | Ability to calculate garbage utility based on number of cans, and residential versus commercial. | ||
| GT.86 | Ability to charge add on fees (dumpsters, roll offs, large items, etc.). | ||
| GT.87 | Generates a return stub so that cash receipts may be read with an optical character reader, scanning the account and amount. | ||
| GT.88 | Ability to view and reprint a past bill at any time. | ||
| GT.89 | Ability to produce final notices. | ||
| GT.90 | Ability to produce statements for customers with multiple utility accounts. | ||
| GT.91 | Ability to export bills to a file for third-party printing. | ||
| GT.92 | Calculates final bills during any cycle based on the internal issuance of a turn off service order or closing of a customer account. | ||
| GT.93 | Supports billing adjustments such as read errors, with an automatic adjustment of billing/read history and amount. | ||
| GT.94 | Ability to not print a paper bill and email the bill to a customer, or an option to both print and email. | ||
| GT.95 | Ability to maintain multiple email accounts. | ||
| GT.96 | Supports budget (equalized) billing, which must also be identified as the amount due when accessing payment amount due. | ||
| Financial Management/Cash Receipting | |||
| GT.97 | Ability for system to prepare transaction batches for posting to SAP Business ByDesign including: Billing, cash receipts, NSFs, adjustments, etc. | ||
| GT.98 | Provides automatic allocation of payments to billed service with ability to adjust or override the default distribution. | ||
| GT.99 | Accepts overpayment or credit adjustment with amount maintained as unapplied credit balance. | ||
| GT.100 | Provides complete audit trail of payments processed for reconciliation prior to posting. | ||
| GT.101 | Ability to import payment records from e-payment or lockbox services vendors. | ||
| GT.102 | Ability to accept full, over, partial, and prepayments. | ||
| GT.103 | Ability to distribute partial payments based on user defined preference (due date, service type, or percentage). | ||
| GT.104 | Provision for data entry correction of any distribution errors. | ||
| GT.105 | Provide autopay option for customers to pay from customer’s bank account or credit card. | ||
| GT.106 | Ability to scan payment information directly into system using bar code or OCR scanner. | ||
| GT.107 | Ability to support payment arrangements for customers to schedule payments for outstanding balances. | ||
| GT.108 | Ability to display transaction history including bills, receipt adjustments, credits, and refunds for an account. | ||
| GT.109 | Ability to display details of transactions and ability to drill down into transaction details. | ||
| GT.110 | Ability to accept deposits and ability to apply deposits and refund deposits (both onto the account or via accounts payable) for a final bill or an account that has been in good standing for a user defined period of time. | ||
| GT.111 | Ability to automate the credit/refund process by batch. | ||
| GT.112 | Ability to display account transaction history via web application (portal). | ||
| GT.113 | Ability to pay outstanding balances or set up automatic payment from credit card or checking account via web application. | ||
| GT.114 | Ability to track deposits. | ||
| GT.115 | Ability to initiate bankruptcy on an account, marking previous balance(s) as uncollectible and to maintain history/provide audit trail for uncollectible balance. | ||
| GT.116 | Provide API/web services for posting real-time payments from payment processing vendor(s) or outside cashiering systems (City is currently investigating use of a centralized cashiering system). | ||
| Delinquency Management | |||
| GT.117 | Ability to age accounts in 30-, 60-, 90-, and 120-day increments. | ||
| GT.118 | Ability to automatically add late penalties or interest to delinquent accounts according to a flexible rate structure determined by the user. | ||
| GT.119 | Automatic printing of shut off notices and service orders. | ||
| GT.120 | Ability to produce delinquent bills for customers that have already received a final bill but continue to maintain an unpaid balance. | ||
| GT.121 | Automated special payment arrangements allowing customers to pay an amount due over time, exempting the account from the shutoff process. | ||
| GT.122 | Ability to automatically assess a charge to an account if a shutoff is processed. | ||
| GT.123 | Ability to flag accounts as exempt from past due notices if an active payment arrangement is on the account. | ||
| GT.124 | Ability to notate when an account has been turned over to an external collection agency. | ||
| GT.125 | Ability to write off aged balances. | ||
| GT.126 | Ability to maintain a dynamic shutoff list that can be automatically or manually updated. | ||
| GT.127 | Ability to populate a third-party notification system with account information so customers can be notified prior to termination of service. | ||
| Service Order Management | |||
| GT.128 | Ability to define, add, change, and delete service order types. Please list the maximum number of service order types allowed. | ||
| GT.129 | Service order system provides automated updates to the utility billing system upon completion of the service order. | ||
| GT.130 | A history of all service orders related to a service address should remain with the service address record. Service orders should provide drill down functionality for detail of actual service order. | ||
| GT.131 | Ability to automatically update customer, location, meter, and account information upon completion of service order action. | ||
| GT.132 | Ability to print or email service orders based upon a user defined selection criteria or defined workflow. | ||
| GT.133 | Ability to dispatch or receive completed service orders via email. | ||
| GT.134 | Ability to track work orders and provide reports for active and completed work orders. | ||
| GT.135 | Ability to automatically generate service orders for certain situations, included, but not limited to, meter turn-on for start service requests, meter turn-off for stop service requests, and meter turn-on for after non-payment service request. | ||
| GT.136 | Ability to create service orders within the utility billing software and then send to a mobile dispatch solution that provides the following functionality: | ||
| GT.137 | 1. User interface with a dashboard showing status of open/pending service orders which includes a list of available resources for assignment, list of service orders to be assigned, and a map view of the open service orders. | ||
| GT.138 | 2. A user interface that enables Public Works users to easily dispatch/assign service orders to field staff, as well as provide exception management capabilities. | ||
| GT.139 | 3. Ability to have some service orders directly assigned to field staff (i.e., auto dispatching). | ||
| GT.140 | 4. Ability to optimize resource schedules via routing capabilities and provide centralized management of all work and resources. | ||
| GT.141 | 5. Robust mobile capabilities that can be used on most common mobile devices (i.e., Apple and Android). | ||
| GT.142 | 6. Rule-based and have the ability to be configured according to Public Works’ rules. | ||
| Reporting | |||
| GT.143 | Standard financial, operational, service work order reports and audit trails. | ||
| GT.144 | End user reporting tool to create reports based on any field combination or partial field within the utility billing system. | ||
| GT.145 | Ability to export reports to Microsoft Excel and Word, PDF, TXT, and CSV | ||
| GT.146 | Ability to generate a list of accounts, customers, or meters based on user defined selection criteria. | ||
| GT.147 | Ability to generate analysis reports with user defined parameters with flexible selection criteria and grouping options. | ||
| GT.148 | Ability to generate ad hoc financial reports, including top 10 consumption report and other information required. | ||
| GT.149 | Manager configurable dashboard for key operational statistics. | ||
| Integration | |||
| GT.150 | Describe in detail the system’s ability to integrate with third-party systems, have open-ended backend API’s with other systems and how it integrates with ESRI GIS. | ||
| GT.151 | 1. Be currently seamlessly integrated with several third-party systems to demonstrate integration capability. | ||
| GT.152 | 2. Have fully open backend API’s to tie into two-way communication with Public Works systems, including but not limited to: | ||
| GT.153 | 3. SAP Business ByDesign | ||
| GT.154 | 4. Neptune 360 | ||
| GT.155 | 5. Be a fully integrated GIS solution. |
&"Aptos,Italic"City of Herriman Utility Billing Software RFP
&"Aptos,Italic"&10Attachment C - Functional and Technical Requirements &"Aptos,Italic"&10Page &P of &N
File details come from the government source that posted it. Updated .