Report potential eligibility of customer accounts for payment plan and settlement status for a given period; Prevent any other activities, such as dismissal once the account is flagged for payment plan and settlement; Segregate existing activities from payment plan/settlement activities; Keep track of status and statistics on all payment plan related activities, such as the number of customers on a payment plan, the total amount due, all payment activities, auto draw rejections, etc.; Have a role based setup process for establishing a customer payment plan. WSDOT is the approval authority to put the customer on a payment plan; Exclude customer accounts under a payment plan from other enforcement efforts deemed as appropriate by WSDOT, such as DOL hold, collections, etc. Customer Website General Requirements The Vendor will provide a website that supports account maintenance activities for customers having a Good To Go! Account with a link to the WSDOT corporate website. The Vendor will support all modifications, enhancements, and redesign based on usability study results to the Good To Go! website authorized by WSDOT to ensure it remains current. The BOS Vendor will follow a recurring schedule of website updates to keep it current in consultation and authorization of WSDOT. The BOS Vendor will provide and use content management software to allow for non-secure site content modifications, information posting and editing and published changes keeping the website live. The live changes via content management software will allow minimal downtime for the website unless absolutely needed. An accessible website entry point shall be provided to allow authorized Good To Go! customers to perform account-related activities online. The BOS Vendor will provide a separate, secure website to host the customer account access functions, which will be linked to/from the WSDOT CBOS. The BOS Vendor shall ensure that appropriate security measures are instituted to prevent unauthorized access to the BOS server(s) through the website and that confidential data entered and viewed by the customer remains secure as per applicable federal, state and local laws, PCI standards and applicable WSDOT policies. The BOS website shall provide the following functionality at a minimum: Allow WSDOT customers to open a Good To Go! account; Provide Good To Go! customers a well-organized portal from which to manage account activities; Show unpaid toll bills for customers to pay; Provide at a 12-month history of toll transactions; Provide the ability to view license plate image details for the violation transaction; Provide the ability to view a breakdown of fares and fees, as applicable, for each transaction;
Time period (day, month, year). Toll Transaction Processing Summary Report The OBOS receives transactional information from roadside toll systems and builds them into viable transactions. WSDOT requires the OBOS to receive and process roadside toll information according to WSDOT business rules and guidelines. It is critical for OBOS to document both viable and non-viable transactions. It is a check point for roadside toll systems performance. WSDOT requires OBOS to produce a comprehensive toll transactions processing report that will document the processing status for all toll transactions built for a given period. The report shall also provide the ability to locate a specific transaction by license plate or pass number. Specific requirements for this report shall include: The OBOS is responsible to build complete toll transactions as either pass-based or image-based. This report will summarize all information received from each roadside toll system and put them in the following processing categories: Received; Viable; Built completed, In review, Dismissed (from image review, duplicates, etc.), and Specialties (from HOV); Non-viable; Variances; For the In-image review and dismissed categories, the report will provide additional details, to ensure all images are being reviewed and all dismissals are accounted for correctly. This includes: Image review transactions -The report shall follow the normal image review workflow and summarize the transaction counts in each stage of the workflow, and Dismissed - The report list all dismissal reasons, including various image review rejection/dismissal reasons, and summarize the transaction counts for each dismissal reason. The dismissal reasons must be configurable based on WSDOT business rules; This report will support both operations and financial reconciliations. The report must be capable of running with multiple parameters. These parameters shall include but not be limited to: Toll facility; Toll lane; Type of transactions (pass vs.
INT010 Toll Transportation Facility Counts Traffic Management System Request for traffic counts by facility (outbound) Traffic count data by facility (inbound) INT011 Washington State Ferry Integration WSF Facilities (multiple) Customer account status (outbound) WSF fare transactions (inbound) Acknowledgement of payment (outbound) INT012 Registered Vehicle Owner Information Washington State Department of Licensing (DOL) Vehicle Registration System License plate from image (outbound) Registered Owner information (inbound) INT013 Registered Vehicle Owner (Out-of-State from State with reciprocal agreement) Law Enforcement System or third party Vendor License plate from image (outbound) Registered Owner information (inbound) INT014 Registration Hold DOL Hold Request System Submit Request for Hold (outbound) Acknowledgement of request (inbound) Release hold (outbound) Acknowledge release of hold (inbound) INT015 Registered Vehicle Information (Third Party sources) Skip Trace Service and other third party sources Available information on registered vehicle (outbound) Acknowledgement of request from third party source(inbound) Address and other information available from third party source (inbound) INT016 Commercial Accounts Upload of vehicle and transponder information in pre-defined format Commercial account uploads vehicle and transponder information Commercial account holder receives confirmation of posting of information Trial
INT017 Financial Institutions Office of State Treasurer ACH batch files INT018 Financial Institutions Lockbox Inbound Customer payments INT019 Financial Institutions Credit Card Processor Request for credit card verification (outbound) Response from bank (inbound) Credit card payment (outbound) (inbound) Credits, refund transactions, returned and notifications of change (outbound) INT020 WSDOT Accounting and Financial Management WSDOT TRAINS General Ledger Journal Voucher for all system financial activities (outbound) GL files including warrant registry files, TRAINS adjustment files (inbound) Generate payment voucher files for customer refunds (state warrants) (outbound) INT021 WSDOT Accounting and Financial Management TRAINS to Data Warehouse Outbound Extract of accounting transactions to data warehouse environment INT022 Collections Third party collection system(s) on State contract Account information (outbound) Confirmation of receipt of information (inbound) Receipt of payment or other status update by collection agency (inbound) WSDOT confirmation of receipt of payment or status update from collection agency (outbound)
Receipt of payment by for an account in collections (outbound) Collection agency acknowledgement of payment received by (inbound) INT023 Print House Department of Enterprise Services Outbound Invoice mailing Statements Notifications INT024 Sales Tax Department of Revenue Inbound Sales tax lookup, shipping address based INT025 Interoperability California Tolling Operations Committee (CTOC) Need to add Inoperability interface for future implementation. Exhibit 3-2: Inventory of Anticipated BOS Interfaces For estimating the assumed/reserved work effort hours for additional interfaces, the Vendor will use the complexity guidelines and number of programs provided in Exhibit 3-3 below. Complexity Interface Complexity Estimating Descriptions Complexity Indication Simple Simple One table to one table map Average ODBC, JDBC, SQL-based, and common database or software EAI adapters/connectors One table to multiple table map Complex Multi-format flat files, and other lesser known data/database and EBCDIC (mainframe) adapters/connectors Multiple table to multiple table map Custom Adapter must be developed for a specific platform or specific data storage mechanism be old database platforms, binary data, platforms, etc.) Offeror to provide estimate and rationale Exhibit 3-3: Interface Complexity Estimating Guidelines For estimating purposes, the Vendor will assume the breakout of assumed/reserved interfaces provided in Exhibit 3-4.