35368 Attc N Requirements Tracability Matrix~2.xlsx
XLSX spreadsheet 391 KB Posted
- Solicitation number
- S-73000-00007613
- Issued by
- Multnomah County, Portland City, Oregon
About this file
This document is a set of business rules for the Commercial Back-Office Toll System Integrator and Customer Services Center for the Oregon Toll Program, which is a comprehensive program for revenue collection and congestion management. The rules cover key aspects of the toll system, including account management, payment processing, financial accounting, customer communication, and additional back-office functions. The system must be able to handle both registered and unregistered toll accounts, provide various enrollment and account management channels, manage discounts and credits, generate invoices and statements, and support interoperability with other toll systems. The system must also comply with generally accepted accounting principles and Oregon state data retention requirements.
The document provides detailed requirements for the toll system's features and capabilities, including payment processing, write-offs, bankruptcy handling, refunds, and account closure. It also outlines requirements for customer communication channels such as email, text messages, interactive voice response, and online chat. The system must be able to integrate with telephony, interactive voice response, and case workflow management solutions to provide comprehensive customer service.
View the file
Other files
Show all 38
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
Business Rules Section BR # Description Release Instructions: Populate the "Compliant", "Compliant After Modificaton", "Not Compliant" columns to indicate which is true for the Proposers solution.
COMPLIANT - Proposers solution does not require modification to meet business rule or requirement COMPLIANT AFTER MODIFICATION - Proposers solution requires modifications to meet business rule or requirement NOT COMPLIANT - Proposers solution does not and will not meet business rule or requirement
| Introduction | |||
| 1 | Account Establishment | ||
| 1.1 | Account Enrollment Channels | ||
| BR.1 | The following rules apply to account enrollments through the various channels: | Release 1 | |
| a. Customer Service Center (CSC)/In-Person Center or any place where ODOT provides in-person tolling customer service – The customer completes an application or provides account information to the customer service representative (CSR), and the CSR opens the account in real time. | Release 1 | ||
| b. Telephone – The customer provides account information to a CSR over the telephone and the CSR opens the account in real time. | Release 1 | ||
| c. Mail – The customer completes a paper application and sends the application via mail to a CSC location, and a CSR opens the account. | Release 1 | ||
| d. Website – The customer opens an account in real time using the ODOT tolling website. | Release 1 | ||
| e. Mobile Application – The customer opens the account in real time using the ODOT tolling mobile application. | Release 2 | ||
| f. Triggered by Transaction- The customer drives on a toll road without an account so the system automatically opens one (unregistered). | Release 1 | ||
| 1.2 | Account Enrollment | ||
| BR.2 | When a customer opens an account, based on account options selected by the customer, the following will occur: | Release 1 | |
| a. A transponder fulfillment process is triggered if the customer requested one. Transponders are dispensed (if not dispensed at the In-Person Center) as part of an enrollment package when account enrollment is complete. Enrollment packages include transponder(s), simple installation instructions, and account information. | Release 1 | ||
| b. Prompts are sent to the customer to enter credit/debit card or ACH banking information for prepaid with auto replenishment and autopay payment methods options. | Release 1 | ||
| c. In cases where the transponder is acquired through a retailer, the customer registers the transponder number in the CBOS. | Future | ||
| BR.3 | Customers can re-open a closed toll account, provided the request falls within the configured State of Oregon data governance and records retention rules and the account meets all other Business Rules. | Release 1 | |
| 2 | Account Management | ||
| 2.1 | Transponders and Vehicles – General | ||
| BR.4 | Transponder inventory will be managed, indicating how many transponders of each type are available at each CSC location, either by manual or bulk upload. | Release 1 | |
| BR.5 | Customers can add transponders and vehicle license plates to their accounts. | Release 1 | |
| BR.6 | Customers are not required to return transponders at account closure. | Release 1 | |
| BR.7 | Customers may return defective hard case transponders to a CSC location for replacement. | Release 1 | |
| BR.8 | Defective hard case transponders that are under warranty will be returned to the manufacturer to receive replacement transponders. | Release 1 | |
| BR.9 | Customers can request a transponder from a CSC location or, if the transponder was procured by the customer from a third party, provide a transponder number. | Release 1 | |
| BR.10 | If CSC assists with transponders, location/status/account assignment will be updated accordingly. | Release 1 | |
| BR.11 | If the toll system does not capture the transponder number and captures the license plate image, the transaction is mapped to the account based on the license plate. | Release 1 | |
| BR.12 | If a transponder account is found to have excessive license plate-based tolls a communication will be sent to the customer to check their transponder for proper usage. | Release 1 | |
| 2.2 | Transponders | ||
| BR.13 | The Oregon Toll Program issues ISO 18000-6C transponders. | Release 1 | |
| BR.14 | The transponders are available to customers, retailers, and third-party account managers at a configurable cost (default to zero). | Release 1 |
(Retailers Future)
| BR.15 | Sticker transponders are issued at zero cost. ODOT may also issue multiple form factors, to include hard case transponders. There may be a configurable fee associated with these transponders. | Release 1 | |
| BR.16 | Defective, damaged, stolen, and lost sticker transponders may be replaced at zero cost to the customer. Customers do not need to return these transponders to a CSC location. | Release 1 | |
| BR.17 | Damaged, stolen, and lost hard case transponders may be replaced after paying a fee (configurable parameter). | Release 1 | |
| BR.18 | Defective hard case transponders may be replaced at zero cost to the customer. The customer must return these transponders to a CSC location. | Release 1 | |
| BR.19 | Exterior 6C transponders, are available at a configurable cost (default to zero) for vehicles with interfering windshields, such as metallized windshields that do not provide a cutout for transponder placement. | Release 1 | |
| BR.20 | Transponders are available for purchase at retail outlets that have specified agreements with ODOT. | Future | |
| 2.3 | Transponder Status | ||
| BR.21 | The following transponder statuses are supported: | Release 1 | |
| a. Unassigned – not assigned to an account | |||
| b. Assigned – assigned to an account and not reported lost, stolen, or defective and used when reporting transactions | Release 1 | ||
| c. Lost or stolen – the account holder has reported the transponder as lost or stolen | Release 1 | ||
| d. Defective – the account holder has reported the transponder to be defective or damaged | Release 1 | ||
| e. Interoperable - assigned to an interoperable agency account | Release 1 | ||
| 2.4 | Transponder Location | ||
| BR.22 | The following transponder locations are supported: | Release 1 | |
| a. Inventory – multiple locations such as MPC, In-Person Service Center location(s), and Mobile Van. | Release 1 | ||
| b. Inventory Assigned to Third Party – multiple locations such as Costco, American Automobile Association (AAA), and Verra Mobility. | Future | ||
| c. Customer – Assigned to customer account. Once assigned to this location, the location cannot change. | Release 1 | ||
| 2.5 | Adding Transponders and Vehicles | ||
| BR.23 | The vehicle(s) start date/time reflects the date and time when the vehicle was activated on the account. The end date/time is not mandatory and remains blank unless a temporary vehicle (for example, a rental vehicle) is added or a vehicle is removed. | Release 1 | |
| BR.24 | A customer will not be able to add a vehicle license plate number to an account if it is associated with an unregistered account with unpaid tolls, fees, and/or fines. The customer will not be able to add the vehicle/license plate number until the outstanding balance is resolved. Resolution criteria is below: | Release 1 | |
| a. Transactions less than 90 days old (configurable parameter) – the customer will have an option to pay tolls only and have their fees and/or fines waived. | Release 1 | ||
| b. Transactions greater than 90 days old (configurable parameter) – the customer will be required to pay the outstanding balance (tolls, fees, and/or fines) in full. | Release 1 | ||
| BR.25 | A customer will not be able to add a vehicle/license plate number if it is associated with another active registered account except for the conditions listed below: | Release 1 | |
| a. Transfer of ownership | Release 2 | ||
| b. Temporary vehicle | Release 1 | ||
| BR.26 | For transfer of ownership processing, the following actions are performed: | Release 2 | |
| a. The vehicle license plate is removed from the original account. | Release 2 | ||
| b. The original account holder is notified that the vehicle license plate has been added to the new account and transactions occurring after the vehicle license plate add date will be associated with the new account. | Release 2 | ||
| i. If the original account holder does not have any remaining vehicle license plate or transponder listed on the account after the transfer of ownership, the account is placed in suspension and a notification is sent advising the customer that the account will be closed unless a vehicle license plate or transponder is added within 30 days. | Release 2 | ||
| ii. If no action is taken within 30 days, the account is flagged for closure. | Release 2 | ||
| BR.27 | For temporary vehicles, the following actions are performed: | Release 1 | |
| a. The vehicle license plate is added as a temporary vehicle with a mandatory end date. | Release 1 | ||
| b. The toll transactions incurred between the add date and the end date are associated with the customer’s account where the temporary vehicle is added. | Release 1 | ||
| 2.6 | Adding Transponders/Vehicles – for Active Accounts | ||
| BR.28 | Additional transponders may be added to a registered customer’s account by requesting a transponder(s). Adding a transponder requires adding a corresponding vehicle. The CBOS performs the same system checks associated with adding vehicles to an account as discussed previously. | Release 1 | |
| BR.29 | Customers can backdate the vehicle license plate’s addition to the registered account for a configurable amount of time (default to 90 days). If there are any unpaid invoices/notices associated with the added license plate in the configurable amount of time, any associated penalties/fines are reversed in the unregistered account, and tolls are posted to the account. | Release 1 | |
| BR.30 | Customers cannot transfer a sticker transponder from one vehicle to another. | Release 1 | |
| BR.31 | CSRs can add an exemption flag and exemption reason to any active vehicle or person that meets configurable criteria, as determined by ODOT. | Release 1 | |
| 2.7 | Deleting Transponders/Vehicles – for Active Accounts | ||
| BR.32 | Customers can delete transponders and vehicle license plates from their accounts. To maintain an active account status, there must be at least one transponder or vehicle license plate on the account. | Release 1 | |
| BR.33 | If after deletion of a transponder or license plate, a customer account will be left with no transponder or vehicle license plate, the customer is warned that their account will be suspended. If the customer proceeds and there is no remaining transponder or vehicle on the account, the account is suspended. | Release 1 | |
| BR.34 | Any transactions with a transaction date before the transponder is removed from the account are posted to the account. Any transactions after the removal date are not posted to the account the transponder is removed from, unless the vehicle and license plate is still on the account. The transaction would be posted as an imaged based transaction. | Release 1 | |
| 2.8 | Replacing Transponders | ||
| BR.35 | The CBOS fulfills transponder replacement requests by removing the old transponder from the account and adding the new transponder number to the account. The status of the old transponder is changed to lost/stolen, damaged, or defective based on the reason provided by the customer. The customer is advised to discard the old transponder if it is still in their possession, except for defective hard case or external-mount transponders (transponders that may have a fee associated with them). For those two transponder types, the customer must return the transponder to the CSC to avoid a replacement fee (replacement of lost/stolen and damaged hard case or external-mount transponders incurs a fee). | Release 1 | |
| 2.9 | Account Merge | ||
| BR.36 | Customers can merge accounts with the help of a CSR. | Release 2 | |
| BR.37 | The primary account holders of both accounts must consent to the merging of accounts. | Release 2 | |
| BR.38 | Both accounts must have balances greater than or equal to zero to be qualify for merging. | Release 2 | |
| BR.39 | Both accounts must be registered accounts. | Release 2 | |
| BR.40 | Customers must agree to close one of the accounts in this process. | Release 2 | |
| BR.41 | Merging of accounts transfers transponders/vehicles from the account to be closed to the merged account. | Release 2 | |
| BR.42 | Merging of accounts transfers the account balance from the account to be closed to the merged account. | Release 2 | |
| BR.43 | Payment instruments are removed from the closed merged account. | Release 2 | |
| BR.44 | Account history and account notes are not transferred from the closed merged account. | Release 2 | |
| BR.45 | Vehicles are end dated in the closed merged account as of the account’s merged date and time. | Release 2 | |
| BR.46 | The vehicle start date in the remaining open account for the transferred vehicles is the start date and time of the vehicle in the closed merged account. | Release 2 | |
| BR.47 | All transactions associated with vehicles and transponders from the closed account with the posted date and time after the merged date and time are posted to the new merged account irrespective of the transaction date. | Release 2 | |
| 2.10 | Transferring Transponder/Vehicle Between Accounts | ||
| BR.48 | Customers can transfer transponders and vehicles between accounts with help of a CSR. | Release 2 | |
| BR.49 | The primary account holders of both accounts must consent to the transfer. | Release 2 | |
| BR.50 | Customers must agree to remove vehicles and transponders from one account. The same rules apply as the rules for deleting transponders/vehicles for active accounts. | Release 2 | |
| BR.51 | The account history and account notes regarding vehicles and transponders are not transferred from the previous account. | Release 2 | |
| BR.52 | Vehicle(s) from the transferee account are end dated as of the move date and time. | Release 2 | |
| BR.53 | The vehicle start date in the transferred account for the transferred vehicle(s) is the date and time when the transfer occurs. | Release 2 | |
| BR.54 | All transactions associated with vehicles and transponders from the transferee account with the transaction date and time before the transfer date and time are posted to the transferee account. | Release 2 | |
| BR.55 | All transactions associated with vehicles and transponders from the transferee account with the transaction date and time after the transfer date and time are posted to the transferred account. | Release 2 | |
| 2.11 | Account Status | ||
| BR.56 | The following account statuses in Table 1 are supported for registered accounts | Release 1 | |
| a. Pending Active - Account creation process has been started but not completed | Release 1 | ||
| b. Canceled - An account with “pending active” status is canceled by the system after X hours/days (configurable parameter) | Release 1 | ||
| c. Active - Account creation has completed and is not Pending Closed, Closed, or Suspended | Release 1 | ||
| d. Pending Closed - Customer has requested the account be closed | Release 1 | ||
| e. Closed - Account has been closed | Release 1 | ||
| f. Suspended - CBOS has placed the account in this status because of irregularities, such as no transponders or vehicles on the account | Release 1 | ||
| BR.57 | For interoperability, when ODOT sends the file (list) of valid transponders to interoperable agencies, ODOT is notifying the interoperable agency that the accounts associated with the transponders are in good standing and payment is guaranteed. If an ODOT customer’s account balance falls to zero or below, ODOT can send out invoices. If an ODOT customer with a transponder status of invalid for interoperable use (zero or negative balance) drives roads operated by interoperable agency, the interoperable agency sends out the invoice. | Release 1 | |
| 2.12 | Account Conversion – Unregistered to Registered | ||
| BR.58 | The customer can convert an unregistered account to a registered account through self-service channels (new enrollment) and with the help of a CSR. | Release 1 | |
| BR.59 | Customers can request account conversion from unregistered to registered account before an invoice is assigned to collections. This requires the following actions: | Release 1 | |
| a. All unpaid fees and penalties are waived. | Release 1 | ||
| b. Unpaid toll charges are calculated (toll rate to be determined [TBD]). | Release 1 | ||
| c. The customer is prompted to select/add the following: | Release 1 | ||
| i. Payment method (prepaid, autopay) | Release 1 | ||
| ii. Replenishment method when prepaid is selected (automatic, manual) | Release 1 | ||
| iii. Payment instrument (if automatic replenishment method or autopay payment method is selected) | Release 1 | ||
| iv. Demographic information (e.g., transponders, vehicles, license plates, correspondence preference) | Release 1 | ||
| d. The amount due is calculated as replenishment amount plus toll charges. | Release 1 | ||
| e. The customer payment instrument is charged the amount due (if selected payment method is prepaid and replenishment method is automatic or payment method is autopay). | Release 1 | ||
| f. The customer is required to pay the amount due if the selected payment method is prepaid and replenishment method is manual. | Release 1 | ||
| 2.13 | Account Closure | ||
| BR.60 | Customers can request for their accounts to be closed. The account must be in “active” status for this request to be processed. When an account closure request is received: | Release 1 | |
| a. The account status is changed to “pending close.” | Release 1 | ||
| b. The customer is advised that they should destroy the transponders on the account and should not use those transponders to travel on toll roads. | Release 1 | ||
| c. License plates associated with the account are end dated as of account closure request date and time and the account status is changed to pending close for X days (configurable parameter) to allow for any unprocessed transactions to be posted to the account. | Release 1 | ||
| d. While the account is in pending close status: | Release 1 | ||
| i. All other account functions such as replenishment and communications to customer regarding their account continues. | Release 1 | ||
| ii. The customer cannot add any vehicles/transponders to their account. | Release 1 | ||
| iii. The customer can add payment instruments to the account. | Release 1 | ||
| e. Any toll transactions with a transaction date/time before the closure request date/time request are posted to this account. | Release 1 | ||
| f. After X days (configurable parameter), if the account has a positive balance, an account refund is processed using the preferred payment instrument registered in the account and the account status is changed to “closed.” | Release 1 | ||
| i. All unused toll credits are reversed and are not refunded to the customer. | Release 1 | ||
| iii. Accounts will have all payment instruments removed when the account status is changed to closed. | Release 1 | ||
| iii. A final communication confirming account closure is sent to the customer. | Release 2 | ||
| iv. No further communications are sent regarding closed accounts. | Release 1 | ||
| v. Customers no longer have online access to their closed accounts. | Release 1 | ||
| g. After X days (configurable parameter), if the account has a negative balance, the replenishment method is changed to manual if the payment method is prepaid and replenishment method is automatic. If the payment method is autopay, the payment method is changed to prepaid and replenishment method is set to “manual.” The account status is changed to “invoiced,” and customer is invoiced for unpaid transactions. | Release 1 | ||
| i. All payment instruments are removed from the account. | Release 1 | ||
| ii. Customers can log on to their accounts using their username and password. | Release 1 | ||
| iii. Customers can pay for their invoices. | Release 1 | ||
| iv. Customers cannot add any transponders/vehicles to their account while the account status remains unpaid. | Release 1 | ||
| vi. Toll transactions are charged at the “unregistered account” toll rate. | Release 1 | ||
| vii. Customers need to pay all outstanding balances on the account before the account status is updated to closed. | Release 1 | ||
| viii. Once the account is brought current and the status is changed to closed, the account closure process can continue according to the account closure rules above. | Release 1 | ||
| 2.14 | Account Fees | ||
| BR.61 | ODOT assesses administrative account fees for certain account-based actions such as mailing statements and returned checks. These fees are configurable in the CBOS and are applied by the CBOS. New fees can be configured at any time, as needed. | Release 1 | |
| a. Mailed Statement Fees - $2 | Release 1 | ||
| b. Returned Check/Automated Clearing House (ACH) Rejection Fee - $35 | Release 1 | ||
| c. Invoice Fee - $5 | Release 1 | ||
| d. Notice of Civil Penalty (NOCP) - $50 | Release 1 | ||
| 2.15 | Customer Statements | ||
| BR.62 | Customer statements are generated on the account anniversary date (monthly or quarterly as selected by the customer). | Release 1 | |
| BR.63 | Customer statement anniversary dates falling on the 29th, 30th, and 31st are generated on the first day of the following month. | Release 1 | |
| BR.64 | Customer statements should include financial activity appearing in chronological order based on posting date to the account. | Release 1 | |
| BR.65 | Statements are generated for registered accounts that are in active and pending close statuses. | Release 1 | |
| BR.66 | Customer statements should clearly identify account demographic and vehicle information, account balance, statement period and all transactions within the period, and any additional fees. | Release 1 | |
| 2.16 | Records Retention | ||
| BR.67 | The time limits (configurable parameters) presented in BR69 are honored for online availability, archiving, and deleting different types of collateral. | Release 1 | |
| BR.68 | Refer to the Oregon state data retention statutes for clarification: | Release 1 | |
| https://secure.sos.state.or.us/oard/displayDivisionRules.action?selectedDivision=591 | |||
| Statements: |
Online Availability: 1 Year Archive: According to state data retention statutes
| Delete: According to state data retention statutes | Release 1 | |
| Letters |
Online Availability: 1 Year Archive: According to state data retention statutes
| Delete: According to state data retention statutes | Release 1 | |
| Vehicle Images |
Online Availability: 30 days post settlement Archive: 30 days post settlement
| Delete: 30 days post settlement | Release 1 | |
| Invoices and Associated Notifications |
Online Availability: 1 Year Archive: According to state data retention statutes
| Delete: According to state data retention statutes | Release 1 | |
| Toll Rate Sign Images |
Online Availability: 30 days post settlement Archive: 30 days post settlement
| Delete: According to state data retention statutes | Release 1 | |
| Voice Recordings |
Online Availability: 3 months Archive: According to state data retention statutes
| Delete: According to state data retention statutes | Release 1 | |
| Chat Scripts |
Online Availability: 3 months Archive: According to state data retention statutes
| Delete: According to state data retention statutes | Release 1 | |
| Bot Scripts |
Online Availability: 3 months Archive: According to state data retention statutes
| Delete: According to state data retention statutes | Release 1 | |||
| 2.17 | Outgoing Correspondence Channels | |||
| 2.17.1 | General | |||
| BR.69 | The following outgoing correspondence channels are supported: | Release 1 | ||
| a. Mail | Release 1 | |||
| b. Email | Release 1 | |||
| c. Text message | Release 1 | |||
| d. In application on website and mobile app | Release 1 |
(mobile app Release 2)
| BR.70 | Customers can select their preferences for correspondence channel. | Release 1 | |
| 2.17.2 | |||
| BR.71 | The mailing service supports the tracking of letters using Intelligent Mail barcode and makes tracking information available in the CBOS. | Release 1 | |
| BR.72 | The mailing service supports electronic interfaces with returned mail and mail forwarding services provided by the U.S. Postal Service (USPS) and makes this information available to the CBOS. The CBOS uses this service to mark addresses undeliverable or update addresses based on this information. | Release 1 | |
| BR.73 | The mailing service supports mailing items to international addresses. | Release 1 | |
| 2.17.3 | |||
| BR.74 | No account-related information is displayed in the body of the email. | Release 1 | |
| BR.75 | Letters and statements are sent as links and require the user to log on to their account to view the information. | Release 1 | |
| BR.76 | Results are tracked that determine if the email was received, opened, or bounced back. | Release 1 | |
| BR.77 | Customers cannot opt out of receiving email messages when they receive the email. They need to log on to their account and change their account preferences. | Release 1 | |
| BR.78 | Email will be set as the preferred channel for correspondence by default. | Release 1 | |
| 2.17.4 | Text Messages | ||
| BR.79 | No account-related information is displayed in the body of the text message. | Release 1 | |
| BR.80 | To take any action based on the text message, the user needs to log on to their account. | Release 1 | |
| BR.81 | Users must pay for any charges related to text messaging subscription services. | Release 1 | |
| BR.82 | Users must opt in to receive text messages from the CBOS at enrollment or by logging into their account. Users will be warned that any message and data rates may apply. | Release 1 | |
| BR.83 | Users can opt out from receiving text messages by logging into their account. | Release 1 | |
| BR.84 | Text messages are sent out in accordance with Oregon law during X business hours and X business days. | Release 1 | |
| 2.17.5 | In Application | ||
| BR.85 | Notifications are displayed in the website and mobile application. | Release 1 |
(mobile app Release 2)
| 2.18 | Outgoing Correspondence Types | ||
| 2.18.1 | General | ||
| BR.86 | The types of outgoing correspondence include: | Release 1 | |
| a. Letters | Release 1 | ||
| b. Statements | Release 1 | ||
| c. Invoices | Release 1 | ||
| d. Notifications | Release 1 | ||
| BR.87 | Customers with registered accounts will be allowed to select their preference for correspondence channel to indicate whether they want to receive letters, statements, and invoices via physical mail or email. If customers select physical mail and also provide an email address, they will be sent correspondence via email in addition to physical mail. | Release 1 | |
| BR.88 | If a customer selects to receive letters, statements, and invoices via email, certain correspondence may be selected to be sent by physical mail at ODOT’s discretion. | Release 1 | |
| 2.18.2 | Letters | ||
| BR.89 | Letters are created to inform registered customers about an action they need to take or to communicate important information regarding their account. This is mandatory correspondence that all customers must receive. | Release 1 | |
| BR.90 | Letter are generated in the customer-indicated preferred language. | Release 1 | |
| BR.91 | All account letters are sent via email by default when an email address is available. | Release 1 | |
| BR.92 | Customers with an email address have the option to receive letters via mail in addition to email. A per-month fee may be assessed for this option. | Release 1 | |
| BR.93 | When an email address is not available or is removed, letters will be sent via mail. | Release 1 | |
| BR.94 | Letters related to account financial information may be sent out via mail in addition to email. | Release 1 | |
| BR.95 | When letters are sent via email, customers are notified of the type of correspondence that is being sent in the email message with a log on link. The customer then logs on to their account to view the letter. | Release 1 | |
| BR.96 | All letters to unregistered customers are sent via mail. | Release 1 | |
| 2.18.3 | Statements | ||
| BR.97 | Monthly and quarterly statements are supported. | Release 1 | |
| BR.98 | All account statements are sent via email by default when an email address is available. | Release 1 | |
| BR.99 | Statements are generated in the customer-indicated preferred language. | Release 1 | |
| BR.100 | When statements are sent via email, customers are notified that their statement is ready with a log on link. The customer then logs on to their account to view the statement. | Release 1 | |
| BR.101 | Customers can view and download statements from their accounts. | Release 1 | |
| BR.102 | Customers may request statements from the CSC for up to X months (configurable parameter) old. | Release 1 | |
| 2.18.4 | Invoices | ||
| BR.103 | All invoices and invoice-related correspondence to unregistered account holders is sent via mail. | Release 1 | |
| BR.104 | All invoices and invoice-related correspondence to registered customers are sent via email when email address is available, same as other correspondence. | Release 1 | |
| 2.18.5 | Notifications | ||
| BR.105 | Notifications are sent via email messages and text messages when feasible (customer has provided an email address and mobile phone number and has opted in to receive text messages), with an exception to details about hearings related to notice of civil penalties. That notice must be sent via mail, in accordance with ORS 183.413. | Release 1 | |
| 2.19 | Returned Mail, Nixie, and Skip Tracing | ||
| BR.106 | The Oregon Toll System uses an electronic interface with USPS to receive Nixie (returned mail) information. | Release 1 | |
| BR.107 | When an address is received as a nixie, the address is skip traced (look for an address using a third party). If a new address is received, the account address is updated, and account correspondence/invoice is sent to the updated address. | Release 1 | |
| BR.108 | If no account information is received, the address on the account is marked as “bad address”. | Release 1 | |
| BR.109 | No further correspondence is sent to accounts marked as bad address until a new address is received. | Release 1 | |
| 2.20 | Forwarded Mail | ||
| BR.110 | The Oregon Toll System uses an electronic interface with USPS to receive forwarded addresses. | Release 1 | |
| BR.111 | When a forwarded address is received, the account address is updated, and any subsequent account correspondence/invoice is sent to the updated address. | Release 1 | |
| 2.21 | Customer Correspondence | ||
| BR.112 | Customer correspondence is logged for tracking and reporting and includes both correspondence to and from the customer. | Release 1 | |
| BR.113 | Customers can submit an inquiry via the online website, mobile application, and online chat. | Release 1 | |
| 2.22 | Write-offs | ||
| BR.114 | Toll transactions, fees, and fines can be written off upon direction from ODOT. | Release 1 | |
| BR.115 | The Oregon Toll System supports handling write-off processes in accordance with state and federal laws. | Release 2 | |
| BR.116 | The write-off process needs to have segregation of duties such that a user preparing and editing the write-offs cannot approve or process the write-offs. | Release 2 | |
| BR.117 | A reason must be identified for each write-off. | Release 2 | |
| BR.118 | Write-offs need to be approved by ODOT designated individuals before processing is complete. This can be done by individual account, or batch approvals. | Release 2 | |
| 2.23 | Bankruptcy | ||
| BR.119 | The Oregon Toll System supports handling bankruptcy claims of customers with toll accounts in accordance with state and federal laws. | Release 1 | |
| BR.120 | Customer accounts are flagged in the CBOS when the bankruptcy filing is received. | Release 1 | |
| BR.121 | All unpaid transactions at the time of bankruptcy are put in “suspended” status. | Release 1 | |
| BR.122 | Escalation and collection efforts on suspended transactions are put on hold, including payment plans. | Release 1 | |
| BR.123 | All correspondence related to unpaid toll transactions covered under bankruptcy filing is suspended. | Release 1 | |
| BR.124 | Any toll transaction or NOCP that occurs after the bankruptcy filing date is subject to continued processing and is collectible. | Release 1 | |
| BR.125 | Accounts with an active bankruptcy flag may not be closed, except under specific conditions to be set forth by ODOT. | Release 1 | |
| BR.126 | Bankruptcy filings are given unique identifiers, and bankruptcy specific data such as filing date, type, status, and dismissal date, are captured. | Release 1 | |
| BR.127 | Bankruptcy dismissals and expirations are tracked, and appropriate notifications are sent to the customer. | Release 1 | |
| BR.128 | If a bankruptcy filing is dismissed or expires, the account flag and transaction hold will be removed, and account processing will be reinitiated with adjustments made for the hold period that was observed. | Release 1 | |
| 3 | Security | ||
| 3.1 | Username, Password, and Personal Identification Number | ||
| BR.129 | Customer usernames are unique in the system. | Release 1 | |
| BR.130 | Customers are prompted to create a username and password when enrolling in an account online. | Release 1 | |
| BR.131 | If the customer opens an account with a CSR, the CSR explains the process of creating a username and password to the customer after creating the account. | Release 1 | |
| BR.132 | Customers can reset usernames/passwords. | Release 1 | |
| BR.133 | Customers are prompted to create an interactive voice response (IVR) access personal identification number (PIN) for their account after they complete enrollment. | Release 1 | |
| BR.134 | Users can request a IVR access PIN reset via any communications channel other than IVR. | Release 1 | |
| BR.135 | The IVR system will only allow authorized users to make changes to recorded messages. | Release 1 | |
| BR.136 | The IVR system will utilize role-based security for typical functions. | Release 1 | |
| 3.2 | System Access Requirements | ||
| 3.2.1 | CBOS | ||
| BR.137 | CBOS users need to be able to remotely access the CBOS system to perform all assigned duties, based on assigned security roles. | Release 1 | |
| BR.138 | Access to the CBOS is solely for the purpose of fulfilling obligations for the Toll Program. | Release 1 | |
| BR.139 | All individuals or entities accessing the CBOS must reside within the United States. | Release 1 | |
| BR.140 | CBOS Users should have log-on access to the CBOS training and test environments. | Release 1 | |
| BR.141 | Authorized ODOT employees must be configured with access to the CBOS application. | Release 1 | |
| 3.2.2 | Phone/In Person | ||
| BR.142 | IVR customers must provide an account number and IVR access PIN to access their account information. | Release 1 | |
| BR.143 | CSC (Phone) – CSRs use the account name, zip code, and other demographic information to verify the customer’s identity. | Release 1 | |
| BR.144 | CSC (In Person) – CSRs require a valid current government-issued photo identification to verify a customer’s identity. | Release 1 | |
| 4 | Payment Processing | ||
| 4.1 | Payment Currency | ||
| BR.145 | The only acceptable currency is U.S. dollars. | Release 1 | |
| 4.2 | Payment Channels | ||
| BR.146 | The following payment channels are supported (support for a particular channel depends upon the payment instrument; Table 4 contains the mapping): | Release 1 | |
| a. CSC – In-Person Centers or any place where ODOT provides tolling customer service | Release 1 | ||
| b. CSC – CSR phone | Release 1 | ||
| c. Mail | Release 1 | ||
| d. IVR | Release 1 | ||
| e. Website | Release 1 | ||
| f. Mobile Application | Release 2 | ||
| g. Retailers through payment networks (e.g., grocery stores and convenience stores) | Future | ||
| 4.3 | Payment Instruments | ||
| BR.147 | Customers can use the following instruments to pay based on the account type and payment channel: | Release 1 | |
| a. Credit/debit cards | Release 1 | ||
| b. ACH bank account debit | Release 1 | ||
| c. Check/Money Order | Release 1 | ||
| d. Cash | Release 1 | ||
| e. PayPal | Future | ||
| f. Venmo | Future | ||
| g. Other applications, such as Apple Pay, Google Pay | Future |
| 4.4 | Credit Cards Supported | ||
| BR.148 | The following credit/debit cards are supported: | Release 1 | |
| a. Mastercard | Release 1 | ||
| b. Visa | Release 1 | ||
| c. American Express | Release 1 | ||
| d. Discover | Release 1 | ||
| 4.5 | Credit Card/Debit Card Expiration Dates | ||
| BR.149 | Expiration dates and/or account numbers are automatically updated by the CBOS through an interface with the merchant services provider for credit card systems that support this functionality. | Release 1 | |
| BR.150 | For the cards that are not updated through the automatic process, the CBOS sends out a communication to the customer about their upcoming expiration date and requests them to update the expiration date for their card. | Release 1 | |
| 4.6 | Payment Methods | ||
| BR.151 | Customers with registered accounts can select one of the following payment methods to pay for their tolls: | Release 1 | |
| a. Prepaid | Release 1 | ||
| i. Automatic replenishment | Release 1 | ||
| 1. Requires customers to maintain a prepaid balance and save a payment instrument on the account. | Release 1 | ||
| 2. When the prepaid balance falls below a certain threshold (replenishment threshold), the CBOS replenishes the account (using the saved payment instrument) by a certain amount (replenishment amount). | Release 1 | ||
| ii. Manual replenishment | Release 1 | ||
| 1. Requires customers to maintain a prepaid balance. | Release 1 | ||
| 2. When the prepaid balance falls below a certain threshold (replenishment threshold), the CBOS alerts the customer to replenish their account. The customer is responsible for replenishing their account and maintaining the required prepaid balance. | Release 1 | ||
| 3. Customer has the option to save payment instrument on the account. | Release 1 | ||
| b. Autopay (Postpaid) | Release 1 | ||
| i. Does not require customers to maintain a prepaid balance on the account. | Release 1 | ||
| ii. Requires customers to save a payment instrument on the account. | Release 1 | ||
| iii. Payment instrument is used to pay for the charges incurred for X days (configurable parameter) or $Y amount (configurable parameter), whichever is earlier. | Release 1 | ||
| BR.152 | Customers who do not have registered accounts will use the following payment methods to pay for their tolls: | Release 1 | |
| a. Pay As You Go: Customers can pay their toll charges within X days (configurable parameter) of travel before they are invoiced for the transactions. | Release 1 | ||
| b. Invoices: Customers without registered accounts with toll transactions who do not pay using pay-as-you-go methods are invoiced for their toll transactions. | Release 1 | ||
| 4.7 | Account Replenishment Amount and Replenishment Thresholds | ||
| BR.153 | The replenishment amount and replenishment threshold are configurable by account attribute and discount program. This will be determined by ODOT policy. | Release 1 | |
| BR.154 | Automatic replenishment amounts and replenishment thresholds may differ from manual replenishment amounts and replenishment thresholds. | Release 1 | |
| BR.155 | Toll activity is reviewed after 90 days of opening an account for replenishment evaluation. | Release 1 | |
| BR.156 | Customers can adjust their replenishment by increasing/deceasing the replenishment amount. The replenishment amount cannot be decreased below the system-required minimum replenishment amount. | Release 1 | |
| 4.8 | Automatic Replenishment | ||
| BR.157 | Customers can have up to a total of X payment instruments (configurable parameter) on file for automatic replenishments and are prioritized in the order which the customer wants the CBOS to attempt replenishment. | Release 1 | |
| BR.158 | When the account prepaid balance falls below the replenishment threshold, the CBOS attempts to replenish the account using the payment instrument on file as prioritized with a configurable number of attempts before dropping to the next prioritized payment instrument if the original payment attempt is not successful. | Release 1 | |
| BR.159 | If the payment instrument is a credit card, a configurable number of attempts (two) to process will occur before dropping to the next prioritized payment instrument. | Release 1 | |
| BR.160 | If an ACH payment instrument is not able to be processed, no additional attempts will occur, and a nonsufficient funds (NSF) fee will apply. | Release 1 | |
| BR.161 | When the replenishment is attempted with a credit card, after two failed attempts, the credit card is removed from the account. | Release 1 | |
| BR.162 | If the account cannot be replenished with any payment instrument, the CBOS sends out a communication to the customer advising them of the issue and requesting the customer to provide a valid payment instrument. | Release 1 | |
| BR.163 | Customers also have an option to make a one-time payment on their account at any time. | Release 1 | |
| 4.9 | Manual Replenishment | ||
| BR.164 | Accounts with the manual replenishment method have the option to store a payment instrument on file. | Release 1 | |
| BR.165 | When the account prepaid balance falls below the replenishment threshold, the CBOS sends out a communication to the customer to pay the replenishment amount. Customers have the choice to: | Release 1 | |
| a. Send a check by mail. | Release 1 | ||
| b. Use the CSC (In-person Center) and make payment via check, credit/debit card, or cash. | Release 1 | ||
| c. Use the IVR (automated or via CSR), website, or mobile application to make payment via credit/debit card or ACH. | Release 1 | ||
| d. Use ODOT-supported retail stores to pay by cash. | Future | ||
| BR.166 | Customers have the option to make one-time payments on their account at any time. | Release 1 | |
| 4.10 | Autopay (POSTPAID) | ||
| BR.167 | Customers may elect to have their account balance paid automatically with a payment instrument on file, such as credit/debit card or ACH, when the account balance reaches a certain amount ($X) (configurable parameter) or there have been certain days (Y days) (configurable parameter) since the first posted toll transaction. | Release 1 | |
| BR.168 | Customers can have up to a total of X payment instruments (configurable parameter) on file for autopay and can prioritize in the order in which they want the CBOS to attempt payment. | Release 1 | |
| BR.169 | When the account balance meets the above condition, the CBOS attempts to post the payment to the account using the payment instrument on file as prioritized. | Release 1 | |
| BR.170 | If the payment instrument is a credit card, a configurable number of attempts (two) to process will occur before dropping to the next prioritized payment instrument. | Release 1 | |
| BR.171 | If an ACH payment instrument is not able to be processed, no additional attempts will occur, and an NSF fee will apply. | Release 1 | |
| BR.172 | When the replenishment is attempted with a credit card, after two failed attempts, the credit card is removed from the account. | Release 1 | |
| BR.173 | If the account balance cannot be paid with any payment instrument, the CBOS sends out a communication to the customer advising them of the issue and requesting that the customer to provide a valid payment instrument. | Release 1 | |
| 4.11 | Converting Account Replenishment Methods for Prepaid Payment Method | ||
| BR.174 | Customers can change their account replenishment method. | Release 1 | |
| BR.175 | Converting from the automatic replenishment to the manual replenishment method requires the following actions: | Release 1 | |
| a. Customers are given the option to remove or change payment instruments from the account. | Release 1 | ||
| b. The replenishment amount and replenishment threshold are adjusted. | Release 1 | ||
| c. When the account balance falls below the manual replenishment threshold, the replenishment communication is triggered. | Release 1 | ||
| BR.176 | Converting from the manual replenishment to the automatic replenishment method requires the following actions: | Release 1 | |
| a. At least one payment instrument must be stored in the account. | Release 1 | ||
| b. The replenishment amount and replenishment threshold are adjusted. | Release 1 | ||
| c. When the account balance falls below the automatic replenishment threshold, the account is replenished with the automatic replenishment amount. | Release 1 | ||
| 4.12 | Converting Payment Methods | ||
| BR.177 | Customers can change their payment methods. | Release 1 | |
| BR.178 | Converting from the autopay payment method to the prepaid payment method and selecting manual replenishment method requires the following actions: | Release 1 | |
| a. The customer’s payment instrument is charged for the account balance and prepaid amount (replenishment amount). | Release 1 | ||
| b. The replenishment amount and replenishment threshold are added. | Release 1 | ||
| c. Customers are given the option to remove payment instruments from the account. | Release 1 | ||
| BR.179 | Converting from the autopay payment method to the prepaid payment method and selecting the automatic replenishment method requires the following actions: | Release 1 | |
| a. The customer’s payment instrument is charged for the account balance and prepaid amount (replenishment amount). | Release 1 | ||
| b. The replenishment amount and replenishment threshold are added. | Release 1 | ||
| c. The payment instrument(s) remain on the account. | Release 1 | ||
| BR.180 | Converting from the prepaid payment method to the autopay payment method requires the following actions: | Release 1 | |
| a. At least one payment instrument must be stored in the account. | Release 1 | ||
| b. The replenishment amount and replenishment threshold are removed. | Release 1 | ||
| c. Customer is refunded any remaining balance on the account. | Release 1 | ||
| 4.13 | Discounts and Credits | ||
| BR.181 | According to ODOT policy, discounts and credits are supported as follows: | Release 1 | |
| a. Discounts – Customer accounts, vehicles, or transactions meeting criteria may have discounts applied by ODOT (for example, a fixed amount or percentage of transaction value) on certain facilities and during a certain period. | Release 1 | ||
| b. Credits – Customer accounts, vehicles, or transactions meeting criteria may have credits applied to toll transactions incurred over a certain period to certain customers. When the credit period is over and/or the account is closed, unused credits are not refunded to the customer. | Release 1 | ||
| BR.182 | Multiple discounts/credits can be applied concurrently as long as required criteria for each discount/credit is met. | Release 1 | |
| CSRs shall follow a series of validation steps to determine customer eligibility for various discounts and credits, based on the direction from ODOT. | Release 1 | ||
| 4.14 | Payment Processing Order | ||
| BR.183 | Payments received from a customer for outstanding tolls/fees should be applied to toll transactions first, based on transaction date order, and then to any associated fees pending, followed by any fines. | Release 1 | |
| BR.184 | If any fees and fines remain unpaid but the outstanding toll transaction(s) have been satisfied, fees and/or fines that remain unpaid may escalate through the invoice and/or registration hold cycle(s). ODOT may adopt dispute policies and procedures as part of their customer service standard operating procedures. | Release 1 | |
| 4.15 | Payment Reversals/Adjustments | ||
| BR.185 | Manual debit and credit adjustments to accounts can be issued up to a specified amount. Adjustments more than this amount must be referred to ODOT for approval. | Release 1 | |
| BR.186 | An authorized user can make a financial adjustment to any payment transaction (including a previously made adjustment). | Release 1 | |
| BR.187 | The adjustment will not financially alter the original transaction being adjusted, and no original data will be altered. | Release 1 | |
| BR.188 | The reversal of any payment will result in the associated “paid” items to revert to “unpaid” status. | Release 1 | |
| 4.16 | Refunds | ||
| BR.189 | Refunds can be issued up to a specified amount. Refunds more than this amount must be referred to ODOT for approval. | Release 1 | |
| BR.190 | Refunds by check can be processed in the CBOS and the data transmitted to ODOT via file transfer for check printing/mailing. | Release 1 | |
| 4.16 | Overpayments and refunds – Unregistered accounts | ||
| BR.191 | Overpayments or credits on invoices will be applied to the next invoice generated for that account. | Release 1 | |
| BR.192 | When the overpayment is more than $X (configurable parameter) and remains on the account for Y days/months (configurable parameter), a refund will be issued to the customer within Z days (configurable parameter). | Release 1 | |
| BR.193 | When the overpayment is less than $X (configurable parameter) and remains on the account for Y days/months (configurable parameter), the overpayment will be (a) written off or (b) follow the state escheatment process. | Release 1 | |
| 4.17 | Refunds – Registered Accounts | ||
| BR.194 | Refunds are issued from accounts when there is a positive prepaid balance in the account after the account is closed or all remaining vehicles on the account are exempt vehicles. | Release 1 | |
| BR.195 | Toll credits received cannot be redeemed for anything other than toll charges, even if the account is closed. | Release 1 | |
| BR.196 | In special circumstances, customers may request refunds from their prepaid balance without closing an account. This request will require ODOT approval before a refund may be issued. | Release 1 | |
| BR.197 | Refunds are issued to the payment instrument that was used to pay the original payment—except for cash, where refunds are issued via check. | Release 1 | |
| BR.198 | When credit/debit card or ACH refund fails, the CBOS will default the refund to paper check mailed to the address on the account. | Release 1 | |
| BR.199 | Credit/debit card refunds in an amount less than $X (configurable parameter) should be processed within Y days (configurable parameter). | Release 1 | |
| BR.200 | Credit/debit card refunds in an amount greater than $X (configurable parameter) need ODOT approval and should be processed within Y days (configurable parameter). | Release 1 | |
| BR.201 | All check refunds are processed X days (configurable parameter) after the original check payment is posted. | Release 1 | |
| BR.202 | Check refunds in an amount greater than $X (configurable parameter) need ODOT approval and should be processed Y days (configurable parameter) after the payment is posted. | Release 1 | |
| BR.203 | All check refunds are issued to the primary account holder. | Release 1 | |
| BR.204 | Check refunds are not issued to account addresses marked as “bad address.” The amount remains on the account and follows the state escheatment process. | Release 1 | |
| 4.18 | Escheatment Process | ||
| BR.205 | The ODOT Finance Group maintains a register of all uncashed refund checks sent to customers. The register indicates the name, address, check number, amount of check, check issue date, customer account number, and reason for check issuance. | Release 2 | |
| BR.206 | Checks of less than $X (configurable parameter) that remain outstanding more than one year from the date of issuance are written off and the balance transferred to ODOT. The write-off and transfer occurs twice a year on December 31 and June 30. The transfer includes the details of the register of the individual checks that make up the transfer. At the time of the write-off, the amount is recorded as “Misc. Income – Stale Checks” in the ODOT general ledger. The entry at time of transfer is documented. | Release 2 | |
| BR.207 | Checks of $X (configurable parameter) or more that remain outstanding more than one year from the date of issuance are removed from the list of outstanding checks and transferred to a liability account. The transfer occurs twice a year on December 31 and June 30. The transfer includes the details of the register of the individual checks that make up the transfer. At the time of the transfer, the amount is recorded as “Accounts Payable – Unclaimed Checks/Property” in the ODOT general ledger. The entry at time of transfer is documented. | Release 2 | |
| BR.208 | The unclaimed checks that have been held by ODOT for at least 3 years are escheated to the State of Oregon. | Release 2 | |
| BR.209 | Other account balances, such as dormant registered account balances and unregistered account overpayments, are subject to the escheatment process. | Release 2 | |
| 4.19 | Returned Checks, Automated Clearing House Rejections, and Chargebacks | ||
| BR.210 | For NSF checks and ACH rejections, the following rules apply: | Release 1 |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .