35368 Exhibit J CBOS and CSC Business Rules and Requirements.pdf

Oregon Toll Program - Back Office

Requirements Commercial Back-Office System

The Commercial Back-Office System (“CBOS”) will process valid toll trips from the Roadside Toll

System (“RTS”), calculate the charges and post them to a customer account. The goal of the

CBOS is to be the central repository for financial and customer account information, which consists of transactions and balances that define the financial state of toll operations. The

CBOS will be an integrated solution (Figure 1 contains CBOS architecture) that combines customer relationship management (“CRM”), customer billing information, accounting, transponder inventory, and toll enforcement activities. The CBOS will also route transactions to

3 rd party Account Managers. The CBOS must be based upon ODOT’s business requirements for both the ODOT Toll Program and accounting rules compliant with generally accepted accounting principles (“GAAP”). In addition, the CBOS must provide robust reporting tools that allow ODOT to analyze tolling data and report on the goals of the state’s toll program.

Commercial Back-Office System Architecture

Given the pace of technological advancements in the transportation industry, it is imperative that the CBOS offer a modernized solution and flexible infrastructure to meet ODOT’s current and evolving requirements, which are listed below:

Flexibility : ODOT requires a configurable application with both system and user parameters for customizing the CBOS application behavior. The CBOS will provide a configuration management interface for the toll operations staff to easily configure the user and system parameters. The system must provide role-based security for flexible access privileges by user role. Changing configuration should not require software or code changes.

Customer Service : The CBOS will include CRM functionality to enable customer service representatives (“CSRs”) to interact with customers and provide self-service functionality for customers through channels that consists of telephony, website, chat, and mobile applications.

Scalability : The system must be scalable to meet demand from traffic volume growth and expandable to add more tolling facilities in accordance with Agency needs and time lines.

Adaptable : The system must be able to adapt with future technology and changing customer needs, such as payment types and communications channels and data sources.

Support for Multiple Data Sources : Currently, only one Roadside Toll System is anticipated to provide trip transaction data to the CBOS at Go-Live and currently planned locations However, in the future, ODOT may select different or additional providers for roadside data collection systems, which may include combination of transponders and cameras, a roadside unit, vehicle telematics, or a GPS device. The system should be capable of receiving data inputs from different data sources simultaneously.

Interoperability: The Oregon Toll System must be interoperable with partner agencies in

Oregon and Washington and third-party account managers. The ability to expand in this area is key to the future success of the planned tolling program. In the future, ODOT expects the

CBOS to be interoperable with the Western Regional Toll Operators (“WRTOs”) and the

California Toll Operators Committee (“CTOC”) as each become operational. Interoperability with EZPass is also expected in the future. Long term, the Oregon Toll System will participate in national interoperatbility. Third Party commercial account managers will also be interoperable, Bestpass, RUC account manager (see more below), and others over time.

Interfaces: The CBOS must provide interfaces to various service providers including Oregon

Driver and Motor Vehicle Services (“DMV”) and Commercial and Compliance Division (“CCD”), mail house, lockbox, payment processors, banks, and third parties as identified by ODOT.

Data Analytics : The CBOS must be capable of providing critical data, such as toll transaction data, CSC performance statistics, financial details, and any other raw data that will eventually be consumed by the ODOT data warehouse. To that end, Contractor(s) shall provide a flexible and decoupled data architecture to ensure the CBOS data can be collected immediately after the CBOS Go-Live.

Support for Road Usage Charging (“RUC”) : Oregon was the first state in the country to implement RUC. It is also one of the first states in the country that implemented RUC before implementation of a toll program. Those who enroll in the RUC program and travel on toll roads will have the option of paying for toll charges on their RUC account.

The RUC system in Oregon supports an open marketplace and the concept of multiple account managers providing customers with multiple options for data reporting and payment methods

(Figure 2- Transportation Services Architecture ). The future vision expands on this concept, expanding to include tolling into the same space. This evolution will use a phased approach where initially the RUC account managers will allow toll transactions to post to RUC accounts and then potentially distribute transponders. They will also enhance their systems to detect and calculate toll transactions, leveraging reporting options already built into their programs

(GPS devices, vehicle telematics, or vehicle-to-everything [“V2X”] solutions). When this occurs, the RUC account managers will report these transaction details to the CBOS for full financial reconciliation.

Eventually, the CBOS will evolve to become the account manager of last resort for both RUC and tolling. This includes implementing ODOT’s RUC program requirements and processes into the CBOS, adding the ability to offer mileage reporting options, calculating RUC charges, and collecting payments.

In the future, ODOT will offer an option for customers to have one combined account through the CBOS and be able to pay for their tolling and RUC charges through a single account. In this scenario, the tolling trips and RUC usage may come from different sources. Another phase will allow one device per customer for reporting both toll transactions and RUC travel data. In all scenarios, the multiple account manager concept will be supported with the CBOS serving as the system of record, processing unpaid transactions, and proving reconciliation functions.

Support for Transit and Parking Payments: ODOT anticipates that the CBOS will allow customers to pay for other transportation services such as transit and parking through their

CBOS accounts. There are several ways to achieve this integration including using readers at parking facilities to capture parking use and allowing transit customers to register their transit cards on their toll accounts. The CBOS architecture must be designed to provide this type of integration.

Mobility Marketplace: ODOT is focusing on a strategy to build a mobility marketplace where customers can pay for a variety of transportation services managed with a single account of their choice. The overarching objectives strive to provide an exceptional customer experience while streamlining process to control administrative costs. Tolls, RUC, parking, and transit are examples of the types of transportation services that will fit into this model. As the concept evolves and technology advances, additional transportation services may be incorporated.

CBOS RELEASE SEQUENCE

The following sections detail the CBOS requirements. The requirements reflect the CBOS

Business Rules (Attachment XX).

The requirements are prioritized regarding when requirements must be delivered in relation to when revenue toll operations start (Go-Live ).

a. Release 1: These System Requirements are required to be delivered at system Go-Live date.

b. Release 2: These System Requirements can be delivered after Go-Live date. These Business

Rules may be delivered in one or more releases at a schedule to be defined and agreed upon with ODOT.

c. Future: These are future System Requirements, which are not required to be delivered at

Go-Live and need not be priced as part of this solicitation. However, ODOT requires that the proposed CBOS solution can support these Business Rules at a future date to be determined by

ODOT.

The content of each release and the approach to the sequence of implementation will be negotiated during the planning phase with ODOT and the Contractor.

Throughout this requirements document, the phrase “manage/provide/perform the full lifecycle” or simply “full lifecycle” is used. These requirements should be understood to mean that the CBOS must provide the capabilities including, but not be limited to, initiating, creating, storing, advancing applicable status, logging, providing notifications, providing triggers for automated actions, archiving, and closing out actions for all instances of the function or product for which full lifecycle support is required in accordance with performance of current tolling industry standards.

1 Account Management

1.1 Accounting Principles

Contractor provides an integrated, configurable, self-balancing GAAP-compliant accounting functionality with double-entry recording of all financial and toll transactions.

The ODOT general ledger (“GL”) chart of accounts contains asset, contra-asset, liability, and revenue accounts for the Oregon Toll Program. ODOT uses the accrual method of accounting and prepares their financial statements in accordance with GAAP using a June 30 Fiscal Year end.

1.1.1 General Financial Requirements

AP.1

The CBOS must manage the full lifecycle of toll and financial transactions in accordance with the ODOT GL chart of accounts.

Release 1

AP.2

The CBOS must create automatic entries to provide an audit trail for all financial and transaction activity.

Release 1

1.1.2 Generally Accepted Accounting Principals

AP.3

The CBOS must provide a GAAP-compliant solution with double-entry recording of all financial and toll transactions by payment instrument to the ODOT GL accounts.

Release 1

AP.4

The CBOS must provide summary and detail financial activity data to ODOT’s Financial System, including summary activity in the GL accounts at a configurable frequency.

Release 1

AP.5 The CBOS must meet Oregon State internal controls requirements. Release 1 https://www.oregon.gov/das/Financial/Acctng/pages/OAM.aspx#internal-control

1.2 Managing Accounts

MA.1 The CBOS must manage the full lifecycle of toll accounts. Release 1

MA.2 The CBOS must manage, at a minimum, the following account types: Release 1

MA.3 a. Registered Release 1

MA.4 b. Unregistered Release 1

MA.5

The CBOS must provide various toll account enrollment and account management channels, aided, and self-service, in accordance with the business rules.

Release 1 https://www.oregon.gov/das/Financial/Acctng/pages/OAM.aspx#internal-control

MA.6

The CBOS must provide the capability to re-open a closed account when transactions for the same person and vehicle are received, maintaining the same account id, in accordance with the Account Management Business Rules and the State of Oregon data governance and retention requirements.

Release 1

MA.7

The CBOS must provide the capability to configure account data, and allow for configurable validations on each, for all account aspects.

Release 1

a. Account Information Release 1

i. Acknowledgment and acceptance of the terms and conditions of the Oregon Toll Program

(required)

Release 1

ii. Enrollment channel Release 1

b. Authorized User(s) Release 1

i. Authorized Individuals who have access to account information and functions Release 1

c. Customer Information Release 1

d. Vehicle Information Release 1

i. Vehicle year, make, and model for all vehicle(s) assigned to an account (required) Release 1

ii. Exemption flag and exemption reason (not required) Release 1

d. Payment Information Release 1

i. Authorization to charge the payment instrument for one-time or recurring billings

(required)

Release 1

e. Transponder Information Release 1

f. Communication Preferences Release 1

g. Discount information Release 1

MA.8

The CBOS must have the capability to manage discounts associated with the account or vehicles with configurable attributes associated with the account

Release 1

MA.9

The CBOS must have the capability to manage system-wide and facility-specific customer discounts/credits.

Release 1

1.2.1 Account Attributes

Additional activities occur at account opening in accordance with the Account Opening

Business Rules.

MA.10 The CBOS must create accounts that are uniquely identifiable. Release 1

MA.11

The CBOS must have configurable payment methods in accordance the Business Rules. Release 1

Payment details for each of these concepts are specified in the Payment Methods Business

Rules.

MA.12 The CBOS must maintain a history of all account actions and activities. Release 1

1.2.2 Customer Preferences

MA.13 The CBOS must manage configurable Customer Preferences. Release 1

MA.14 The CBOS must use selected Customer Preference in workflow activities. Release 1

MA.15 The CBOS must manage customer preference for language. Release 1

1.2.3 Vehicles

MA.16

The CBOS must manage vehicles with configurable attributes associated with the account. Release 1

1.2.3.1 Vehicle Transponders

MA.17

The CBOS must manage the full lifecycle of assigning transponders to a vehicle on an account. Release 1

MA.18

The CBOS must allow an unlimited number of vehicles and transponders on an account. Release 1

MA.19

The CBOS must provide the capability to manage configurable transponder attributes associated with the account.

Release 1

MA.20

The CBOS must allow a transponder to be listed as active on only one vehicle at any time. Release 1

MA.21

The CBOS must manage transponder status in accordance with the Account Management

Business Rules.

Release 1

1.2.3.2 Vehicle License Plates

MA.22

The CBOS must be capable of configuring a license plate attribute for the vehicle on an account.

Release 1

MA.23

The CBOS must allow vehicle license plates to have a backdated start date not to exceed a configurable number of days when first being added to an account, in accordance with the

Account Management Business Rules (Adding Transponders/Vehicles – For Active Accounts).

Release 1

MA.24 The CBOS must allow a vehicle license plate to be only on one vehicle at any time. Release 1

MA.25

The CBOS must allow bulk upload updates (add, delete) of vehicle license plates vehicles on an account(s).

Release 1

1.2.4 Payment Information

MA.26

The CBOS must manage account payment instruments with configurable attributes associated with the account.

Release 1

MA.27

The CBOS must manage a configurable number of payment instruments and payment methods, in accordance with Payment Processing Business Rules.

Release 1

MA.28

The CBOS must manage a configurable number of stored payment instruments (primary, secondary) in accordance with the Payment Processing Business Rules.

Release 1

MA.29

The CBOS must provide configurable replenishment threshold and replenishment amount parameters for registered accounts.

Release 1

1.2.5 Merging Accounts

MA.30

The CBOS must provide the capability to merge one or more accounts and associated balances, in accordance with Account Management Business Rules.

Release 2

1.2.6 Transferring Transponder/Vehicle Between Accounts

MA.31

The CBOS must provide the capability to transfer vehicles and all their attributes between accounts.

Release 2

1.2.7 Converting Accounts from Unregistered to Registered Account

MA.32

The CBOS must provide the capability to convert unregistered accounts to registered accounts while maintaining the same account id, in accordance with the Account Management Business

Rules.

Release 1

1.3 Customer Notification of Charges

1.3.1 Invoicing

MA.33 The CBOS must manage the full life cycle of invoice processing. Release 1

MA.34

The CBOS must have the capability to invoice registered and unregistered accounts on a configurable billing cycle in accordance with the Processing Unpaid Transactions Business

Rules.

Release 1

MA.35

The CBOS must generate an invoice for unpaid transactions using the ROV lookup name and address in accordance with the Processing Unpaid Transactions Business Rules.

Release 1

MA.36

The CBOS must generate invoices with configurable data elements at a configurable frequency. Release 1

MA.37 The CBOS must send invoices using the method according to customer preference. Release 1

MA.38 The CBOS must store an exact pdf copy of each invoice associated to the account. Release 1

MA.39 The CBOS must have the ability to pause invoice aging. Release 1

An invoice including all unpaid transactions is sent to the ROV after a defined time period and may include a fee. An invoice not paid within a defined period of time will begin the escalation process where subsequent invoices, sent at regular intervals, may include reminder language, unpaid amounts, additional fee(s), and any new transactions. Invoices that remain unpaid for a defined period of time will be subject to all penalties and fees allowed by Oregon statutes.

These debts may be sent to the Oregon Department of Revenue or an external collection agency, or both, and additional collection agency fees may be applied.

An ROV who has unpaid invoices remaining after the escalation and collection periods will receive an NOCP and may be subject to a registration hold. The registration hold will be removed when all outstanding balances are paid.

1.3.2 Statements

MA.40

The CBOS must generate customer account statements according to the Customer Statement

Business Rules.

Release 1

MA.41

The CBOS must allow transactions with configurable attributes (for example, transactions associated with temporary vehicles) to not display configurable parameters (such as date and time and location) on the statements.

Release 1

MA.42 The CBOS must generate statements at a configurable frequency. Release 1

MA.43

The CBOS must send statements using the method according to customer preference. Release 1

MA.44

The CBOS must store an exact pdf copy of each statement associated to the account. Release 1

1.3.3 Notification of Low or Negative Balance

MA.45

The CBOS must generate notifications to inform customers of low account balance based on a configurable threshold amount.

Release 1

MA.46

The CBOS must send notifications of low balance using the method according to customer preference.

Release 1

MA.47

The CBOS must generate notifications to inform customers ofnegative account balance. Release 1

MA.48

The CBOS must send notifications of negative balance using the method according to customer preference.

Release 1

1.4 Payment Processing

1.4.1 Payment Processing

MA.49

The CBOS must have the capability to provide payment processing data (detail and summary) based on ODOT, Department of Revenue, and Oregon State Treasurer’s bank for various accounting activities.

Release 1

MA.50

The CBOS must allow configurable payment cycles, in accordance with Payment Processing business rules.

Release 1

MA.51 The CBOS must accept configurable payment instruments (in U.S. currency only). Release 1

Minimum support of payment instruments varies by payment channel as specified in the

Payment Instruments Business Rules.

MA.52 The CBOS must allow one or more items be paid in a single transaction. Release 1

MA.53 The CBOS must allow a configurable application for order of payments. Release 1

MA.54 The CBOS must allow for configurable payment types. Release 1

MA.55 The CBOS must have the capability to post partial payments and overpayments. Release 1

MA.56

The CBOS must provide the ability to hold payment processing until configurable necessary authorizations are received.

Release 1

MA.57

The CBOS must use data from the MSPs to automatically update expiration information for stored credit and debit card payment instruments.

Release 1

MA.58

The CBOS must provide data to reconcile payments received from and paid to interoperable agencies and third-party account managers.

Release 1

MA.59

The CBOS must be capable of allowing authorized users to make a financial adjustment(s)

(including reversals) to any transaction without impacting the original transaction.

Release 1

MA.60

The CBOS must update a transaction from "paid" to "unpaid" when the payment is reversed. Release 1

1.4.2 Adding Funds to Pre-Paid Account Balance

MA.61 The CBOS must allow for adding funds to a pre-paid account balance. Release 1

1.4.3 Returned Checks, ACH Rejections, Chargebacks

MA.62

The CBOS must allow for the processing of payment reversals and returned payments. Release 1

MA.63

The CBOS must allow for the processing of returned payments, such as returned check and credit card chargebacks and apply applicable fees, in accordance with Account Management

Business Rules.

Release 1

MA.64

The CBOS must provide an automated process to manage identifying and rectifying duplicate charges for the same item(s) in real time.

Release 1

MA.65 The CBOS must allow for refund of duplicate charges. Release 1

The CBOS must allow customers to dispute invoices and NOCPs at any stage. Business Rules developed by ODOT must be used to resolve customer disputes that may escalate to an administrative hearing to be conducted by Oregon Office of Administrative Hearings. The CBOS must be used for case material compilation.

MA.66

The CBOS must allow customers to dispute a paid or unpaid invoice or NOCP at any stage of escalation in accordance with Processing Unpaid Transactions Business Rules.

Release 1

MA.67

The CBOS must provide the ability to review and approve or reject invoice and NOCP disputes. Release 1

MA.68 The CBOS must manage invoice and NOCP dispute status, actions, and resolution. Release 1

MA.69

The CBOS must pause invoice aging on disputed transaction during an active dispute, recalculate time periods upon resolution, and update invoice status.

Release 1

MA.70

The CBOS must have the capability to schedule Administrative Hearings as part of the dispute process, adhering to all ORS section 183 laws.

Release 2

MA.71 The CBOS must have the capability to process results of Administrative Hearings. Release 2

1.4.4 Waiving Fees

MA.72

The CBOS must provide the ability to waive fees (invoice fees, admin fees, NOCP fees) if the waived amount does not exceed a configurable threshold.

Release 2

MA.73

The CBOS must provide the ability to waive fees (invoice fees, admin fees, NOCP fees) if number of times waived for that type of fee does not exceed a configurable number of times in a 12 month period.

Release 2

1.5 Lockbox Processing

1.5.1 Processing Checks and Money Orders

Checks or money orders remitted for payment on customer accounts and invoices will be mailed to a lockbox facility at U.S. Bank, an existing ODOT and Oregon state government partner.

MA.74

The CBOS must be capable of managing the full lifecycle of lockbox payment processes. Release 1

MA.75

The CBOS must be capable of receiving payment data from the lockbox and posting payments to the appropriate customer accounts.

Release 1

MA.76

The CBOS must be capable of receiving and attaching lockbox images of checks, money orders, payment coupons, and envelopes to the appropriate account.

Release 1

MA.77

The CBOS must be capable creating and assigning cases with lockbox incoming correspondence attached.

Release 1

2 Financial Accounting

FA.1 The CBOS must manage the entire lifecycle of transactions posted to accounts. Release 1

2.1 Write-Off

ODOT writes off uncollectable receivables/debts as part of its regular business process.

FA.2

The CBOS must manage the full lifecycle of write-offs, including reviews and approvals. Release 2

FA.3 The CBOS must have the capability to configure write-off criteria. Release 2

FA.4

The CBOS must execute configurable write-off processes by scheduled batch process and on an ad hoc (manual) basis.

Release 2

FA.5

The CBOS must send a confirmation notification that customer accounts have been updated when the write-off process is complete and generate a notification to designated ODOT staff.

Release 2

2.2 Bankruptcy Management

ODOT requires the CBOS to support actions that must be taken on a customer account when a bankruptcy notification is received.

FA.6

The CBOS must manage the entire lifecycle of bankruptcy handling, in accordance with the

Bankruptcy business rules, including filing, holding periods, and dismissals.

Release 1

FA.7 The CBOS must comply with bankruptcy law and collection standards. Release 1

FA.8

The CBOS must provide a mechanism for identifying which transactions/invoices have entered bankruptcy.

Release 1

2.3 Refund Issuance

Customers can request a partial or full refund from their prepaid account balances. The refund can also be issued automatically in accordance with Payment Processing Business Rules.

FA.9 The CBOS must interface with ODOT for the printing of refund checks. Release 1

FA.10

The CBOS must manage refund processing, allowing for full and partial payment refunds in accordance with Payment Processing Business Rules.

Release 1

2.3.1 Unclaimed Property (Escheatment)

FA.11

The CBOS must manage configurable escheatment processes for unclaimed toll balances and unclaimed refunds in accordance with Payment Processing Business Rules.

Release 2

FA.12 The CBOS must comply with Oregon Unclaimed Property Laws Release 2 https://oregon.public.law/statutes/ors_chapter_98.

2.4 Account Closing

FA.13

The CBOS must allow the closing of an account in accordance with the Account Management

Business Rules.

Release 1

FA.14

Upon account closure, the CBOS must process refunds for accounts that have a positive balance in accordance with the Payment Processing Business Rules.

Release 1

FA.15

The CBOS must provide the capability to automatically close a toll account after a configurable period of complete inactivity.

Release 1

3 Account Communication

3.1 General

AC.1

The CBOS must generate and send notifications and correspondence to customers through communication channels by customer preference.

Release 1

AC.2

The CBOS must store copies of all notifications and correspondence sent to and received from the customers with their associated accounts.

Release 1

AC.3

The CBOS must generate and send correspondence based on configurable account triggers. Release 1

AC.4

The CBOS must generate correspondence in English or Spanish according to customer preference.

Release 1

AC.5 The CBOS must ensure all correspondence adheres to ODOT approved branding. Release 1

3.2 Autogenerated Account Notifications

AC.6

The CBOS must autogenerate and set for delivery mail notifications triggered by configurable account actions.

Release 1

AC.7

The CBOS must use Oregon indicia marks for outbound correspondence sent through the mail. Release 1

AC.8

The CBOS mail house provider must incorporate an USPS Intelligent Mail barcode on outbound correspondence.

Release 1

AC.9

The CBOS must provide an electronic interface with USPS for National Change of Address, return mail, and address forwarding.

Release 1

AC.10

The CBOS must provide functionality to process change of addresses, forwarded addresses and returned mail addresses.

Release 1

AC.11 The CBOS must provide functionality to scan and categorize incoming mail. Release 1 https://oregon.public.law/statutes/ors_chapter_98.

AC.12

The CBOS must provide functionality to route all scanned incoming mail to workflow queues for processing.

Release 1

3.3 Email Notifications

AC.13

The CBOS must autogenerate and deliver email notifications triggered by configurable account actions.

Release 1

AC.14

The CBOS must provide the capability to manage the full lifecycle of email notifications. Release 1

AC.15 The CBOS must be capable of handling returned/undeliverable email notifications. Release 1

3.4 Text Messages

AC.16

The CBOS must provide the capability to autogenerate and deliver text notifications triggered by configurable account actions.

Release 1

AC.17 The CBOS must provide functionality to track text message delivery. Release 1

3.5 Telephony and Interactive Voice Response

AC.18

The CBOS must fully integrate with a telephony and Interactive Voice Response ("IVR") solution.

Release 1

AC.19

The telephony and IVR solution must be capable of Automatic Call Distribution ("ACD"). Release 1

AC.20

The IVR and telephony solution must record and maintain voice recordings for all CSR-customer calls and provide for easy retrieval.

Release 1

3.6 Chat

AC.21 The CBOS must manage the full lifecycle of customer service chat conversations. Release 1

AC.22

The CBOS must allow customers who are logged onto their account to access live agent chat during normal business hours.

Release 1

AC.23 The CBOS must allow customers to upload attachments through the chat session. Release 1

AC.24

The CBOS must offer the customer the option to receive a full transcript of their web chat session with a live agent shortly after the session concludes.

Release 1

AC.25

The CBOS must provide chatbot functionality, which will include answers to Oregon Toll

Program’s frequently asked questions.

Release 1

3.7 Survey Tool

AC.26

The CBOS must provide the capability to perform customer surveys through different channels and report on survey results.

Release 1

4 Additional Back Office System Functions

4.1 Case Workflow Management

BO.1

The CBOS must manage the full lifecycle of case workflow. Cases track manual work that is triggered by events including but not limited to these types of functions: account management, payment collection, customer correspondance, or overall system administration.

Release 1

a. Account Management

b. Payment Collection

c. Customer Correspondence

d. Overall System Administration

BO.2

The CBOS must provide the capability to create cases triggered by configurable system activities.

Release 1

BO.3

The CBOS must provide the capability to create cases triggered by any type of customer correspondence.

Release 1

BO.4

The CBOS must provide configurable case workflow queues to route cases based on CSRs skill sets, staffing level, and priorities for processing.

Release 1

BO.5

The CBOS must provide the capability to assign CSRs to one or more case workflow queues. Release 1

BO.6 The CBOS must provide the capability for a CSR to put a case on hold.

BO.7 The CBOS must pause case aging when it's been put on hold.

BO.8 The CBOS must provide configurable workflow dashboards. Release 1

BO.9

The CBOS must enable an unlimited number of cases to be attached to customer accounts. Release 1

BO.10 The CBOS must provide the capability to attach images and documents to cases. Release 1

BO.11 The CBOS must provide access to view all case information for an account. Release 1

BO.12

The CBOS must maintain a complete case history, including all document attachments for the case.

Release 1

BO.13

The CBOS must retain all cases and attached documentation with the associated account until account is deleted.

Release 1

BO.14

The CBOS must provide data from the managed workflows for auditing and reporting purposes.

Release 1

4.2 CBOS Application and Graphical User Interface

BO.15 The CBOS must be the system of record. Release 1

BO.16 The CBOS must be a web browser-based application. Release 1

BO.17

The CBOS must maintain cross-browser compatibility with the current most utilized browsers. Release 1

BO.18

The CBOS must adhere to, and stay current with, industry accepted web development standards and specifications, including but not limited to World Wide Web Consortium (W3C) and Hypertext Markup Language (HTML) Version 5.

Release 1

BO.19

The CBOS must incorporate current usability engineering standards and be optimized for speed.

Release 1

BO.20 The CBOS must incorporate field validation standards to all data entry fields. Release 1

5 Customer Self-Service Tools

See the Customer Self-Service section for the customer facing functions that are required on the website, the mobile application, and IVR.

5.1 General

SST.1

The CBOS must have the capability of providing a variety of self-service tools so that customers can execute the self-service functions.

Release 1

(mobile app

Release 2)

SST.2

All self-service tools must be available to customers 24 hours a day, seven days a week. Release 1

(mobile app

Release 2)

SST.3

All self-service tools must require registered customers to log in with a username and password, or otherwise confirm their identity before granting access to account specific information.

Release 1

(mobile app

Release 2)

SST.4

All self-service tools must integrate with the credit card payment processor for processing payments or replenishments.

Release 1

(mobile app

Release 2)

SST.5

All self-service tools must send a payment confirmation notification to the customer when payments or replenishments are made.

Release 1

(mobile app

Release 2)

SST.6

The self-service customer website and mobile application must provide the capability to configure account attributes for display based on specific attributes. (for example, transactions associated with temporary vehicles won't display toll location, date or time.)

Release 1

(mobile app

Release 2)

SST.7

The self-service customer website and mobile application must require users to accept ODOT's approved account terms and conditions before creating an account.

Release 1

(mobile app

Release 2)

SST.8

The self-service customer website must provide the capability for customers to contact customer service through email or chat functions.

Release 1

(mobile app

Release 2)

SST.9

The CBOS must create a case based on website or mobile application inquiry(s) that includes all information provided, including attachments.

Release 1

(mobile app

Release 2)

5.2 Customer Self Service Website

SST.10 The CBOS must provide a website for customers to perform self-service functions. Release 1

SST.11 The CBOS must provide the platform for hosting the self-service customer website. Release 1

SST.12 The self-service customer website must contain both static and dynamic content. Release 1

SST.13

The self-service customer website must be mobile friendly, using responsive design and adapt to different screen sizes and resolutions commonly found on mobile devices.

Release 1

(mobile app

Release 2)

SST.14

The self-service customer website must maintain cross-browser compatibility with the current top 5 must utilized browsers.

Release 1

SST.15

The CBOS customer website must maintain web accessibility according to the Americans with

Disabilities Act, the World Wide Web Consortium’s (“W3C’s”) web content accessibility guidelines, and Oregon accessibility laws and standards within 12 months of the most recent updates.

Release 1

5.3 Customer Self-Service Mobile Application

SST.16

The CBOS must provide a mobile application for customers to perform self-service functions. Release 2

SST.17

The mobile application must provide the capability to manage push notifications to the customer.

Release 2

SST.18

The mobile application must be compatible with the latest stable versions of Android and iOS operating systems.

Release 2

SST.19

The mobile application must be designed to adapt to different screen sizes and resolutions commonly found on mobile devices.

Release 2

5.4 Customer Self-Service Interactive Voice Response

SST.20

The self-service IVR system must provide the capability for customers to select a preferred language from a configurable language list.

Release 1

SST.21 The self-service IVR system must have configurable menu options and navigation. Release 1

SST.22

The self-service IVR system must recognize natural language speech for customer navigation. Release 1

5.5 Customer Self-Service Kiosks

SST.23

The CBOS must provide kiosks in public places (i.e. DMV field offices) for customers to perform self-service functions.

Future

6 Compliance

C.1 The CBOS must manage the full lifecycle of toll compliance, including Escalation, Collections, Notice of Civil Penalty, and Registration Hold

Release 1

ODOT will deploy an enforcement process to encourage customers to pay tolls, fines, and fees.

The enforcement process will consist of escalated sanctions. This process is described in the

Processing Unpaid Transactions Business Rules and is subject to change as Oregon

Administrative Rules are updated. The requirements below are consistent with the escalation process described in the Processing Unpaid Transactions Business Rules.

6.1 Escalate Invoice

C.2

The CBOS must automatically track and update outstanding unpaid transactions as they age, update payment status throughout the escalation period, add administrative fees, and recalculate amounts due.

Release 1

6.2 Send to Collections

C.3 The CBOS must provide the capability to assign debt to one or more collection agencies. Release 1

C.4 The CBOS must provide the capability to keep debt assignments for a single account to the same collection agency.

Release 1

C.5 The CBOS must automatically track and update all debt assignments and recalls to the account. Release 1

6.3 Issue Notice of Civil Penalty

C.6 The CBOS must generate an NOCP for unpaid invoices that have been assigned to a collection agency for a configurable period of time.

Release 1

C.7 The CBOS must assign a configurable penalty amount for invoices that have a NOCP. Release 1

C.8 The CBOS must comply with all NOCP statutes, policies, and laws for payment or nonpayment. Release 1

6.4 Hold Vehicle Registration

C.9 The CBOS must have the ability to send registration holds and registration hold release requests to the ODOT DMV and CCD on a configurable schedule.

Release 2

C.10 The CBOS must provide the capability to remove a registration hold on a vehicle when notification of a change of vehicle ownership is received.

Release 2

C.11 The CBOS must provide the capability to remove a registration hold on a vehicle when notification of a change in registration hold status is received.

Release 2

C.12 The CBOS must automatically track and update all registration holds and releases by vehicle plate transaction and invoice level as part of the account record.

Release 2

C.13 The CBOS must send account balance due to ODOT DMV and CCD in real-time, upon request. Release 2

6.5 Transfer debt to the Department of Revenue

C.14 The CBOS must have the ability to send the debt to the Oregon Department of Revenue for collection.

Release 2

C.15 The CBOS must automatically track and update all debt sent to the Oregon Department of

Revenue to the account.

Release 2

6.6 Handling Disputes/NOCP

C.16 The CBOS must manage the full lifecycle of customer disputes of charges, fees, and fines individually or as part of an invoice.

Release 2

7 Transaction Processing

The CBOS must include the ability to store toll rate tables, edit the toll rates, and send toll rate tables to the RTS.

7.1 Store and Maintain Toll Rate Tables

TP.1 The CBOS must store the toll rate tables. Release 1

TP.2

The CBOS must have a user interface to allow authorized users to edit toll rate tables. Release 2

TP.3 The CBOS must send toll rate tables to the RTS. Release 1

7.2 Store Customer Information From Interoperable Partners

TP.4

The CBOS must store the account information (account numbers, transponders and license plates) received from interoperable partners and third-party account managers.

Release 1

The CBOS receives transaction data and images from the RTS Operational Back-Office System host and posts the transaction and associated toll charge to the appropriate customer account.

7.3 Receive Transactions from the RTS

TP.5

The CBOS must provide the capability to receive and store transactions and images from the

RTS.

Release 1

TP.6

The CBOS must provide the capability to receive and store transactions and images from interoperable agencies.

Release 1

7.4 Initial checks and calculations

TP.7

The CBOS must be configured to apply Initial Transaction Processing Check Business Rules. Release 1

TP.8

The CBOS must calculate the amount owed for each transaction using the data received from the RTS (transaction type, location, time of day, day of week, vehicle classification), toll segment, account and vehicle attributes (discounts, exceptions).

Release 1

TP.9

The CBOS must be configured to apply different toll rates based on type of transaction, according to the rate table.

Release 1

7.5 Post Transaction

TP.10

The CBOS must have the capability to post transactions received by either the RTS or an interoperable agency using Transponder Number, License Plate or Account Number.

Release 1

TP.11

The CBOS must post transactions to the correct customer accounts, interoperable partners, and third-party account managers in accordance with Tolls and Transaction Processing

Business Rules.

Release 1

TP.12

The CBOS transaction processing logic must be configurable as the Tolls and Transaction

Processing Business Rules are subject to change.

Release 1

7.6 Get Registered Owner of Vehicle Information

License plate-based trips that cannot be posted to a valid Oregon, interoperable, or third-party account are invoiced. Registered owner of vehicle (“ROV”) information may be obtained directly from ODOT-specified service partners, ROV lookup services, or through direct lookup agreements with state offices, or both. ROV information is used to invoice unpaid toll transactions. Future functionality may include invoicing ROV with license plates registered to other states and countries.

TP.13

The CBOS must have the capability to interface with and process ROV information from multiple ROV lookup service entities.

Release 1

TP.14

The CBOS must match ROV information results to all transactions matching a license plate, and bundle all matching transactions for posting to an unregistered account, in accordance with the Processing Unpaid Transactions Business Rules.

Release 1

TP.15

The CBOS must have matching logic to minimize creating unnecessary unregistered accounts, in accordance with the Processing Unpaid Transactions Business Rules.

Release 1

TP.16

The CBOS must categorize and log a configurable number of error codes for unsuccessful lookup results.

Release 1

TP.17

The CBOS must trigger a case creation for a workflow to process unsuccessful ROV lookup results though additional image review or secondary ROV lookup sources, or both.

Release 1

TP.18

The CBOS must maintain an account address history in the system for unregistered accounts. Release 1

7.7 Discounts/Credits/Exemptions

TP.19

The CBOS must apply discounts, exemptions, and toll credits based on configurable vehicle, account, and transaction parameters.

Release 1

TP.20

The CBOS must provide the capability to apply configurable beginning and ending dates to discount/exemption/credit program.

Release 1

7.8 Account Fees

TP.21

The CBOS must manage a configurable number of administrative account fees in accordance with the Account Management Business Rules.

Release 1

7.9 ODOT Finance

TP.22

The CBOS must provide the capability to summarize financial transactions processed and send to ODOT's financial system.

Release 1

8 Customer Service Representative Functions

The ODOT tolling customers will be able to contact live CSRs either virtually (through phone calls or chat) or in person at staffed service centers during defined business hours. In addition, customers will be able to send their inquiries and disputes either through USPS mail or the website. The CSRs will use the CBOS to perform all account management functions for the customers as well as respond to inquiries. The CBOS will support role-based access whereby the CSRs will be able to access functionality based on their authorization level.

8.1 Role-Based Access with Secure Log-Ons

CSR.1

The CBOS must manage the full lifecycle of login management according to ODOT security policies.

Release 1

CSR.2 The CBOS must provide configurable role-based system access for users. Release 1

CSR.3

The CBOS must provide configurable role-based permissions for system actions for users. Release 1

8.2 Managing Customer Requests

8.2.1 Route and Manage Interactive Voice Recognition calls

CSR.4 The IVR System must allow CSRs to accept phone calls. Release 1

CSR.5

The IVR System must provide functionality to assign CSRs to IVR queues based on configurable skill sets and priority levels.

Release 1

CSR.6

The CBOS must provide the capability for CSRs to monitor and barge-in on active conversations.

Release 1

CSR.7

The CBOS must provide access to view and listen to IVR customer interaction recordings for evaluation.

Release 1

8.2.2 Route and Manage Chats

CSR.8

The CBOS must provide the capability for customers and CSRs to communicate via chat. Release 1

CSR.9

The CBOS must provide functionality to assign CSRs to chat queues based on configurable skill sets and priority levels.

Release 1

CSR.10

The CBOS must provide on-demand and customizable chat statistics dashboards for oversight and staff management.

Release 1

8.2.3 Route and Manage Emails

CSR.11

The CBOS must provide the capability for CSRs to receive and reply to emails from the customer.

Release 1

CSR.12

The CBOS must provide the capability for CSRs to view the history of all email correspondence related to the account.

Release 1

8.3 Cashiering

CSR.13

The CBOS must provide information for CSRs to reconcile their till balance for each shift. Release 1

CSR.14

The CBOS must provide the capability to enter items and their amounts, either manually or through scanning hardware, into a transaction record.

Release 1

CSR.15

The CBOS must provide the capability to total all items for a transaction total balance. Release 1

CSR.16

The CBOS must provide the capability to enter the tendered amount, and reconcile that amount with the total pending balance.

Release 1

8.4 Enrollment and Account Management

CSR.17 The CBOS must allow CSRs to establish customers’ accounts. Release 1

CSR.18

The CBOS must allow CSRs to input, edit, and view history of account management data for customers.

Release 1

CSR.19 The CBOS must allow CSRs to add notes to customer accounts. Release 1

CSR.20

The CBOS must allow CSRs to access to all correspondence sent to and received from the customer.

Release 1

8.5 Payments

CSR.21

The CBOS must allow CSRs to take payments from customers for account balances and invoices.

Release 1

CSR.22

The CBOS must allow CSRs to take payment from customers to add funds to pre-paid accounts Release 1

CSR.23

The CBOS must allow authorized personnel to post payments from customers to accounts. Release 1

CSR.24

The CBOS must allow access to all historical payments through the CSC user interface. Release 1

CSR.25

The CBOS must indicate the status of a registration hold for a vehicle through the CSC user interface.

Release 2

8.6 Toll/Invoice/Notice of Civil Penalty Disputes

CSR.26 The CBOS must allow CSRs to initiate a dispute for the customer. Release 1

CSR.27

The CBOS must allow a CSR to resolve a dispute in accordance with Disputes Business Rules. Release 1

CSR.28

The CBOS must provide the capability to transfer liability for an invoice when documentation is provided in accordance with the Processing Unpaid Transactions Business Rules.

Release 1

CSR.29

The CBOS must provide the capability for CSRs to view all transaction details and associated images listed on an invoice.

Release 1

CSR.30

The CBOS must allow CSRs to view all dispute actions taken as part of the account record. Release 1

8.7 Workforce Management

CSR.31

The CBOS must provide the capability to manage the full lifecycle of workforce management. Release 1

CSR.32 The CBOS must provide the capability to manage work schedules. Release 1

CSR.33

The CBOS must manage configurable skill set identification for workforce members. Release 1

CSR.34

The CBOS must manage configurable roles and responsibilities for workforce members. Release 1

8.8 Case Workflow

CSR.35

The CBOS must provide the capability for CSRs to view cases with all attached documents and/or images.

Release 1

CSR.36

The CBOS must allow the capability for CSRs to create and assign cases to other CSRs or to case queues.

Release 1

CSR.37

The CBOS must allow the capability for CSRs to manage case lifecycle, including attaching documents or images.

Release 1

8.9 Manage Toll Rate Table

CSR.38

The CBOS must be capable of allowing authorized users to manage the toll rate table. Release 1

8.1 Search Capability

CSR.39

The CBOS must provide robust search and filter capabilities to CSRs on all account information and transactions.

Release 1

9 Customer Self-Service

The CBOS must include self-service tools that allow toll customers to open and maintain their accounts. This will consist of a mobile-friendly responsive website, a mobile application, and an IVR system.

The entire list of functions below are not required on all the self-service tools. See the Self-

Service Tools table that defines the functions required by tool.

9.1 Oregon Toll Program Information

CSS.1

The CBOS must have the capability for to display Oregon Toll Program information and frequently asked questions customers and to the general public.

Release 1

CSS.2

The CBOS must provide the capability for customers obtain information regarding the Oregon

Toll Program while on a telephone call within the IVR system.

Release 1

CSS.3

The CBOS must have the capability for self-service customers to calculate the estimated toll for a specific route for a determined date and time of day.

Release 1

9.2 Enrollment and Account Management

CSS.4

The CBOS must have the capability for self-service customers to perform the full lifecycle of account management.

Release 1

CSS.5

The CBOS must have the capability for self-service customers to enroll in the Oregon Toll

Program by opening an account.

Release 1

CSS.6

The CBOS must provide the capability for self-service customers to convert their account from unregistered to registered.

CSS.7

The CBOS must have the capability for self-service customers to do a bulk upload of license plate information during account opening and account maintenance.

Release 1

CSS.8

The CBOS must provide the capability for self-service customers to review and download enrollment documents.

Release 1

9.3 Payments

CSS.9

The CBOS must have the capability for self-service customers to update payment information. Release 1

CSS.10

The CBOS must have the capability for self-service customers to review account balances. Release 1

CSS.11

The CBOS must have the capability for self-service customers to add funds to their account. Release 1

CSS.12 The CBOS must have the capability for self-service customers to make payments. Release 1

CSS.13

The CBOS must have the capability for self-service customers without an account to search for, view, and pay for un-invoiced or unpaid toll charges/fess.

Release 1

CSS.14

The CBOS must have the capability for self-service customers to request the closing of their account.

Release 1

CSS.15

The CBOS must provide the capability for self-service customers to review and download a subset (configurable parameters by type and age) of all outgoing customer correspondence.

Release 1

CSS.16

The CBOS must have the…