Customer Correspondence Functional Specification and System Design

Document Version Number 2.3 FSD-SDD-08-01, February 06, 2020

     

Customer Correspondence

Functional Specification and System Design Document

Version Number 2.30

FSD-SDD-08-01

 

 

 

 

 

 

 

 


     

 

 

 

 

 

 

                        TollPlus, LLC

                        July10,February 06, 2020 2019

                                         

 

Version History

Version No.

Date

Changed By

Description

v1.0

07/02/2019

TollPlus Team

Initial release with review comments from NTTA

V2.0

07/10/2019

JoAnn Carlisle

Update Post Approval

UC-08-01-01 embedded matrix updated to reflect comments regarding the following correspondence items:

-          Updated Vehicle: per business rule ownership change notification is suppressed

-          Updated Overpayment: suppressed at this time, note for configurable system trigger

-          Updated Fees: will be handled via MBS

-          Added Account plan change: suppressed at this time

-          Updated Escheatment: updated to include web and mobile app as channels

-          Updated Underpayment: suppressed at this time

-          Updated Automatic Waiver of Admin Fee: suppressed at this time, will be handled as part of receipt

V2.1

07/29/19

JoAnn Carlisle

Update Post Approval

UC-08-01-07 :

COR-BR-34          Removed REQ for use case and added to Section 1.5 Parked Requirements per clarification receive in ICD workshop.

 

UC-08-01-02:

COR-REQ-43.3     Remapped REQ to UC-08-01-09 as it is applicable to template management.

 

UC-08-01-01:

TXN-REQ-141        Mapped REQ to use case as it applies to payment decline correspondence.

 

NOT-REQ-26         Remapped REQ to use case as it is applicable to Excessive VTOLL correspondence type.

 

Updated embedded RTM to reflect ‘Parked’ mapping.

 

Updated embedded RTM to reflect “ICD” classified requirements.

 

Updated embedded RTM to include use case mapping of COR-REQ-12 to UC-08-01-02.

V2.2

1/27/20

JoAnn Carlisle

UC-08-01-03:

COR-REQ-27     Remapped REQ to UC-08-01-09 as it is applicable to template management.

 

Embedded Matrix:

Updated to include delivery method prioritization.

Added Transmission type column.

Updated Default and Sender Values where needed.

Added Frequency values.

Updated Data elements

Added additional correspondence types – Forgot Username, Forgot/Rest Password, Forgot/Reset Pin, Airport and parking Credit Card (or payment method) transaction failed letter.

 

Section 1.5:

Added COR-REQ-4.20,COR-REQ-4.3, andCOR-REQ-4.51

 

UC-08-01-01: embedded Matrix replaced with most current copy

Section 1.5:

Added COR-REQ-5.6

 

UC-08-01-04: added additional narrative regarding

Response code actions.

V2.3

02/06/20

JoAnn Carlisle

UC-08-01-01: embedded Matrix replaced with most current copy

 

UC-08-01-04: Updated narrative regarding Ignore

Response code action.

 

Moved the following requirements to Parked per discussion on 2/4 with NTTA Business Team.

COR-REQ-11

COR-REQ-11.1

COR-REQ-11.2

COR-REQ-11.3

COR-REQ-11.4

COR-REQ-12

 

Table of Contents

1       Introduction.. 7

1.1    Business Objective 7

1.2    Scope 7

1.3    Requirements 9

1.4    Related Requirements 9

1.5    Parked Requirements 9

1.6    Project Requirements 10

1.7    Reference Documents 11

2       Functional and Technical Requirements. 13

2.1    UC-08-01-01: General Correspondences 13

2.2    UC-08-01-02: Correspondences Configuration. 18

2.3    UC-08-01-03: Correspondence Generation and Resending. 24

2.4    UC-08-01-04: Tracking and Distribution. 25

2.5    UC-08-01-05: Correspondence/Notification Suppression. 28

2.6    UC-08-01-06: Recipient Lists 29

2.7    UC-08-01-07: Notification History, Storage and Viewing. 31

2.8    UC-08-01-08: Barcodes, Scan Lines and QR codes 32

2.9    UC-08-01-09: Template Management 33

3       Appendix: Requirements Traceability. 35

1       Introduction. 6

1.1    Business Objective. 6

1.2    Scope. 6

1.3    Requirements. 8

1.4    Related Requirements. 8

1.5    Parked Requirements. 8

1.6    Project Requirements. 9

1.7    Reference Documents. 10

2       Functional and Technical Requirements. 11

2.1    UC-08-01-01: General Correspondences. 12

2.2    UC-08-01-02: Correspondences Configuration. 16

2.3    UC-08-01-03: Correspondence Generation and Resending. 21

2.4    UC-08-01-04: Tracking and Distribution. 22

2.5    UC-08-01-05: Correspondence/Notification Suppression. 25

2.6    UC-08-01-06: Recipient Lists. 26

2.7    UC-08-01-07: Notification History, Storage and Viewing. 28

2.8    UC-08-01-08: Barcodes, Scan Lines and QR codes. 29

2.9    UC-08-01-09: Template Management 30

3       Appendix: Requirements Traceability. 32

1       Introduction.. 5

1.1    Business Objective 5

1.2    Scope 5

1.3    Requirements 7

1.4    Related Requirements 7

1.5    Parked Requirements 7

1.6    Project Requirements 8

1.7    Reference Documents 9

2       Functional and Technical Requirements. 10

2.1    UC-08-01-01: General Correspondences 11

2.2    UC-08-01-02: Correspondences Configuration. 15

2.3    UC-08-01-03: Correspondence Generation and Resending. 20

2.4    UC-08-01-04: Tracking and Distribution. 21

2.5    UC-08-01-05: Correspondence/Notification Suppression. 23

2.6    UC-08-01-06: Recipient Lists 24

2.7    UC-08-01-07: Notification History, Storage and Viewing. 26

2.8    UC-08-01-08: Barcodes, Scan Lines and QR codes 27

2.9    UC-08-01-09: Template Management 28

3       Appendix: Requirements Traceability. 29

Table of Figures

Figure 1: T-BOS High Level System Architecture. 7

Figure 2: Typical Notification Workflow.. 11

Figure 1: T-BOS High Level System Architecture. 6

Figure 2: Typical Notification Workflow.. 10

 

 

1       Introduction

1.1          Business Objective

This document aims to describesthe functionality required for customer correspondences/notifications, business and system processes that trigger them based on NTTA’s Business Rules and associated functionality provided by T-BOS.

1.2          Scope

The purpose of this document is to defineand explain general customer correspondence and notification functionalityprovided by T-BOS.

  1. General Correspondences
  2. Correspondence Configuration
  3. Correspondence Generation and Resending
  4. Tracking and Distribution
  5. Correspondence/Notification Suppression
  6. Recipient Lists
  7. Notification History, Storage and Viewing
  8. Barcodes, Scan Lines and QR codes
  9. Template Management

 

Special Note:

  • Interface details for various interactions between T-BOS and QuestMark is not in scope of this document. ICD definition/completion pending further discussion.
  • MBS is not in the scope of this document and is specifically covered in FSD-05-01 Monthly Billing Statement.


 

 

The following diagram depicts the T-BOS high-level system architecture; the highlighted section is addressed and covered in this document.

 

Figure 1: T-BOS High Level System Architecture


1.3          Requirements

The following section of Functional Requirements and related Business Rules are included in this document. 

MODULE

 

Requirements

8. Customer Correspondence

8.1 Customer Correspondence – General Requirements

8. Customer Correspondence

8.2 Notification Configuration Requirements

8. Customer Correspondence

8.3 Notification Account Management Requirements

8. Customer Correspondence

8.4 Notification Tracking and Distribution Requirements

15. Interfaces

15.12 INTERFACE TO PRINT/MAIL SERVICE PROVIDER REQUIREMENTS

15. Interfaces

15.13 INTERFACE TO ELECTRONIC MONTHLY BILLING STATEMENT SERVICE PROVIDER REQUIREMENTS

 

1.4          Related Requirements

  • FSD and SDD 01-01 Account Management
  • FSD-01-06 Address Management
  • FSD-05-01 Monthly Billing Statement
  • FSD-10-01 Customer Portals
  • FSD-18-01 Global System Requirements

 

1.5          Parked Requirements

The following requirements are included in the referenced sections above and are recommended or agreed to be parked.  These requirements are not included in the use cases to follow.

Requirement #

Description

Reason

COR-REQ-4.7

·        the Account Agreement has been updated;

Parked per review comments 

COR-REQ-4.57

·        penalty assessed;

Parked per review comments 

COR-REQ-4.61

Credit Card will be charged;

Parked per review comments 

COR-REQ-5.2

·        certified mail;

Parked per review comments 

COR-REQ-5.3

·        certified mail returned receipt;

Parked per review comments 

COR-REQ-43.21

·        setting the number of days, from the mailing of the dispute reject letter, to extend the payment date;

Parked per review comments 

COR-BR-4

An “Account application needs more information” notification shall be sent to the Customer if a valid email address, cell phone number or address is provided.

Parked per review comments 

COR-BR-34

Notifications that are downloaded or printed from a Customer’s Account shall be watermarked “COPY”.

Parked per ICD clarifications

COR-REQ-4.20

·        SOV travel on HOV-only mode;

Parked per ICD clarifications

COR-REQ-4.3

·        unsuccessful Account opening;

Parked per ICD clarifications

COR-REQ-4.51

·        unpaid transactions at each aging level;

Parked per ICD clarifications

COR-REQ-5.6

·        fax;

Parked due to RTP functionality no longer needing to be supported.

COR-REQ-11

The BOS shall provide the capability for generating and sending Notifications to multiple addresses (Configurable) or contacts (Configurable); including, but not limited to:

Parked per 2/4 discussion with NTTA Business

COR-REQ-11.1

·        addresses for a single contact; i.e., 3rd notices – owner address and renewal address;

Parked per 2/4 discussion with NTTA Business

COR-REQ-11.2

·        customer contacts;

Parked per 2/4 discussion with NTTA Business

COR-REQ-11.3

·        the BOS-defined address and multiple customer defined addresses, and;

Parked per 2/4 discussion with NTTA Business

COR-REQ-11.4

·        configure Customer Notifications to send to multiple HV addresses, based on NTTA’s Business Rules.

Parked per 2/4 discussion with NTTA Business

COR-REQ-12

The BOS shall provide the capability (Configurable) to define an order of Priority, for using multiple mailing addresses, based on the source from which an address was received (i.e., ROV, Skip Tracing and/or NCOA).

Parked per 2/4 discussion with NTTA Business

 

1.6          Project Requirements

1.5.1

Functional Specification Document (FSD)

Covered?

PROJ-REQ-101

The VSI shall develop and submit an FSD to NTTA for review and Approval.  The FSD shall describe the detailed functional T-BOS Design, which describes how the Contract Requirements (using the RTM) and Business Rules will be met in the T-BOS.

Yes

 

PROJ-REQ-102

The FSD shall define functions of the VSI’s system, or its component, with a set of inputs, behavior, and outputs.

Yes

PROJ-REQ-103

The FSD shall include system and user interface screen diagrams, reports, figures and tables, and contain the following; including, but not limited to:

Yes

PROJ-REQ-103.1

  • overall business objective and high-level Requirements;

Yes

PROJ-REQ-103.2

  • system overview that shows the overview of the system components and how they align with the high-level Requirements and business objectives;

Yes

PROJ-REQ-103.3

  • high-level conceptual Design, such as a diagram of the system components affected, including any data flows between the applications;

Yes

PROJ-REQ-103.4

  • common system behavior including navigation controls, menu structures and access to help that impact certain T-BOS function, or all T-BOS functions;

Yes

PROJ-REQ-103.5

  • details of system changes required clearly indicating existing functionality, configured or customized;

Yes

PROJ-REQ-103.6

  • detailed Use Cases that show the behavior of the system with data flows;

Yes (scenarios and process flow included)

PROJ-REQ-103.7

  • detailed user Process Maps/Flows with any alternate paths;

Yes

PROJ-REQ-103.8

  • user interface screens, including screen mockup, reports, screen controls, user actions and application behavior;

Yes

PROJ-REQ-103.9

  • Interface specification, including purpose, whether it’s new or existing, sender, receiver, frequency and format;

Yes

PROJ-REQ-103.10

  • Non-functional Requirements and how they will be delivered.  Examples include: performance, audit control, security configuration, message catalog, and;

Not Applicable

PROJ-REQ-103.11

  • High-level test conditions, including description.

No; will be covered in Test Plans

 

1.7          Reference Documents

Document References

Source

ICD

Business Rules

NTTA

NTTA Business Rules-v2018.3 BASELINE - DESIGN ANALYSIS with Edit Marks 2... (1)

NTTA Business Rules

NTTA

RFP 04482-NTT-00-CS-IT

RFP

NTTA

NTTA_1919-ICD_V1_FINAL

ICD

QuestMark

NTTA/TollPlus Print Vendor Workshop – Version 1.3

 

 

 

2       Functional and Technical Requirements

NTTA may send notifications/correspondences to its customers, based on NTTA’s Business Rules and customer notification preferences. This section will give an overview of notifications and their configurable triggers; if multiple notifications are triggered by the same condition, the notification hierarchy will be based on NTTA’s Business Rules.

 

Typical Notification Workflow

 

 

Figure 2: Typical Notification Workflow

 

 

2.1          UC-08-01-01: General Correspondences

T-BOS correspondences shall allow notifications to be sent from the BOS to NTTA customers, using multiple distribution methods or notification channels. These notifications comprise of Email, SMS text messages, USPS, fax, phone, Self-Service Mobile Application and Self-Service Website. Every notification item has associated business or system criteria which triggers its generation, i.e. when an account meets an eligibility criterion, customer account qualifies for a specific notification item.

Outgoing notifications are created, processed and transmitted, based on Configurable Account Attributes, Notification Configuration and Notification delivery preferences.  All notifications related to an account, shall sent using a standard and approved template and will be associated with that account, if applicable, in T-BOS.

T-BOS will generate data elements and will interface with NTTA’s current print vendor (QuestMark) to exchange the necessary data elements that are applicable for each notification/correspondence that is triggered.

T-BOS will comply with communication and privacy laws  and other laws applicable to the transmission of consumer notifications.

NOTE: More details on the exchange of information needed between NTTA and print vendor (QuestMark) to facilitate the high-volume printing and mailing needs of NTTA will be provided in the Print ICD.

2.1.1        Configuration Items

Applicable information regarding notifications/customer correspondences, business and system scenario triggers for correspondence generation, default channels and preferences, and other necessary details related to each one of them are further detailed in the below use cases and embedded matrix.

Note: To be finalized during correspondence template discussions.

 

2.1.2        Screen Layouts/Wireframes

Not Applicable

2.1.3        Technical Design

Not Applicable

2.1.4        Requirements and Business Rules

Requirements and Business Rules Covered

Reference           Description

COR-REQ-1

The BOS shall provide all outgoing customer Notifications with a standard template, as Approved by NTTA.

COR-REQ-4

The BOS shall provide the capability to automatically initiate customer correspondence and Notifications, based on Account events, Attributes, Flags and NTTA’s Business Rules; including, but not limited to:

COR-REQ-4.1

·        Account status (open, delinquent, suspended, closed) changes (Configurable);

COR-REQ-4.2

·        Account creation;

COR-REQ-4.4

·        customer request received or updated;

COR-REQ-4.5

·        status change of a customer’s Case;

COR-REQ-4.6

·        Account changes (Configurable), such as the addition of a vehicle to the Account or change of password;

COR-REQ-4.7

·        the Account Agreement has been updated;

COR-REQ-4.8

·        temporary License Plate expiring;

COR-REQ-4.9

·        change in vehicle ownership;

COR-REQ-4.10

·        amount due reminders;

COR-REQ-4.11

·        transponder order placed;

COR-REQ-4.12

·        an issue with customer’s transponder;

COR-REQ-4.13

·        transponder shipped;

COR-REQ-4.14

·        transponder recall and/or replacement;

COR-REQ-4.15

·        change in transponder status;

COR-REQ-4.16

·        Account balance is a Configurable amount above the Low Balance Level;

COR-REQ-4.17

·        daily Account balance;

COR-REQ-4.18

·        payment posted to Account;

COR-REQ-4.19

·        a specific transaction was posted to the Account; i.e., TEXPress Transaction or airport transaction;

COR-REQ-4.21

·        a VToll was posted to the Account;

COR-REQ-4.22

·        Excessive VToll threshold is exceeded;

COR-REQ-4.23

·        Account balance level is below the required balance threshold;

COR-REQ-4.24

·        Account auto-replenishment (Credit Card, ACH, Payment Service) failure;

COR-REQ-4.25

·        Account replenished (indicating primary or secondary replenishment type);

COR-REQ-4.26

·        auto-replenishment suspended;

COR-REQ-4.27

·        auto-replenishment recalculation;

COR-REQ-4.28

·        Credit Card update successful (from the Credit Card update service);

COR-REQ-4.29

·        Credit Card update failure (from the Credit Card update service);

COR-REQ-4.30

·        Credit Card is within a Configurable number of days from its expiration;

COR-REQ-4.31

·        Credit Card expiration date changed;

COR-REQ-4.32

·        Credit Card has expired;

COR-REQ-4.33

·        MBS;

COR-REQ-4.34

·        MBS is available (manually-generated, monthly and quarterly);

COR-REQ-4.35

·        delinquent Account;

COR-REQ-4.36

·        Citation issued;

COR-REQ-4.37

·        dispute accepted;

COR-REQ-4.38

·        dispute rejected;

COR-REQ-4.39

·        Administrative Hearing request acknowledgement;

COR-REQ-4.40

·        Administrative Hearing schedule;

COR-REQ-4.41

·        Administrative Hearing result (accepted/rejected);

COR-REQ-4.42

·        warning of Registration Block;

COR-REQ-4.43

·        rental car License Plate subscription;

COR-REQ-4.44

·        Account about to be set with inactive Flag;

COR-REQ-4.45

·        inactive Account with positive balance, before their Account is escheated, based on NTTA’s Business Rules;

COR-REQ-4.46

·        inactive Account with $0.00 balance;

COR-REQ-4.47

·        Account is flagged with a bankruptcy status, or change in bankruptcy status;

COR-REQ-4.48

·        undeliverable mail situation;

COR-REQ-4.49

·        undeliverable email situation;

COR-REQ-4.50

·        bad phone/fax situation;

COR-REQ-4.52

·        outstanding balance;

COR-REQ-4.53

·        overpayment;

COR-REQ-4.54

·        underpayment/partial payment;

COR-REQ-4.55

·        returned check;

COR-REQ-4.56

·        fee assessed;

COR-REQ-4.57

·        penalty assessed;

COR-REQ-4.58

·        receipt generated;

COR-REQ-4.59

·        refund issued;

COR-REQ-4.60

·        TollPerks updates;

COR-REQ-4.61

·        Credit Card will be charged;

COR-REQ-4.62

·        customer has funds to be escheated, which exceed a Configurable amount, and;

COR-REQ-4.63

·        Airport and parking Credit Card (or payment method) transaction failed letter.

COR-REQ-5

The BOS shall provide the capability to distribute and track Notifications through Notification channels; including, but not limited to:

COR-REQ-5.1

·        mail;

COR-REQ-5.4

·        email;

COR-REQ-5.5

·        SMS/text messaging;

COR-REQ-5.7

·        Self-Service Website;

COR-REQ-5.8

·        Self-Service Mobile Website, and;

COR-REQ-5.9

·        Self-Service Mobile Application.

COR-REQ-19

The BOS shall provide the capability (Configurable) to send a Notification to a customer, regarding an undeliverable mail situation, by using a different Notification channel.

COR-REQ-48

The BOS shall provide the capability to setup the Configurable parameters that will trigger Notifications for Excessive VTolls.

COR-REQ-21

The BOS shall provide the capability (Configurable) to send a Notification to a customer, regarding an undeliverable email situation, by using a different Notification channel.

COR-REQ-22

The BOS shall provide the capability to mark phone and fax numbers as bad, after a Configurable number of failed contact attempts.

COR-REQ-23

The BOS shall provide the capability (Configurable) to send a Notification to a customer, regarding a bad phone or fax number situation, by using a different Notification channel.

COR-REQ-33

The BOS shall provide the capability for Notifications to include images, graphics, lists (i.e., lists of License Plates and/or transponders) and text.

COR-REQ-66

The BOS shall provide the capability to electronically deliver receipts, based on the choice of the Authorized User or customer; i.e., a receipt may be displayed, with print options, emailed, or sent by text.

COR-REQ-75

The BOS shall provide additional functionality and reporting as necessary for NTTA to comply with communication and privacy laws (such as the Telephone Communication Protection Act (TCPA) and the CAN-SPAM Act) and other laws applicable to the transmission of consumer notifications.

TXN-REQ-141

The BOS shall send a Notification to the BMS when Credit Card payments are credited, based on Configurable settings.

NOT-REQ-26

The BOS shall track established KPIs (number/percentage) for VTolls/MTolls, during a Configurable period, and flag the Customer Account(s) if the number/percentage is above a Configurable threshold.

COR-BR-5

A “Bad Address” notification shall be sent to a Customer when the mailing address has been determined to be bad and there’s no forwarding address. These notifications shall only be emailed, available via the Mobile App or sent via text or SMS.

COR-BR-6

A “Rejected/Failed Payment” notification shall be sent to a Customer when their auto-replenishment payment, automatic payment or mailed-in payment failed, was rejected due to insufficient funds, was bounced or a Credit Card was blocked or cancelled.

COR-BR-7

Receipts shall be sent to a Customer automatically for payments or replenishments and successful parking transactions, or as manually requested for any other transaction.

COR-BR-9

Receipts shall be sent automatically to a Customer after defined conditions (i.e., a parking transaction or a payment) if a valid email address or cell phone number is provided.

COR-BR-10

An “Account Status Change” notification shall be sent to the Customer when an Account changes in the following ways: 1. Account changes from prepaid to delinquent2. Account changes from prepaid to postpaid3. Account changes from postpaid to prepaid4. Account close has been initiated

COR-BR-11

A “No Balance” notification shall be sent to the Customer when the Account is cash-based and the Account has reached a zero or negative balance.

COR-BR-12

A “Low Balance” notification shall be sent to the Customer every day for the first three (3) days and for every week thereafter, once a week, when the Customer’s Account has reached their Low Balance Level and is not replenished.

COR-BR-13

An “Outstanding Amount Due” notification shall be set to “not be sent” to a Customer at this time.

COR-BR-14

An “Overpayment” notification shall be set to “not be sent” to the Customer at this time.

COR-BR-15

An “Account Update” notification shall be sent to the Customer anytime the following occurs: 1. Contact information is changed or added2. Address information is changed or added3. Telephone information is changed or added4. Email information is changed or added5. Vehicle information is changed or added6. Transponder information is changed or added7. Payment information is changed or added

COR-BR-16

An “Excessive VToll” notification shall be sent to the Customer when the “Excessive VToll” condition is set or reset based on the Transaction Processing Business Rules.

COR-BR-17

A “License Plate Transponder Required” notification shall be sent to a Customer when the vehicle type associated with a windshield-type Transponder has been determined to be a type requiring a License Plate Transponder, and the Transponder is being fulfilled and sent to the Customer. Note: A sample list of vehicles is in the following:

COR-BR-18

A “Statement is Ready” notification shall be sent to every Customer who has not selected a paper statement to be mailed, and a statement for their Account has been generated and is available to the Customer.

COR-BR-19

A “Monthly Billing Statement” shall be mailed to a Customer if the Account is system-generated and the distribution method is mail.

COR-BR-20

A “Request to Update Temporary License Plate” notification shall be sent to the Customer every thirty (30) days, when a temporary License Plate is active on an Account and the License Plate has expired.

COR-BR-21

A “Vehicle Ownership Change” notification shall not be sent to Customers.

COR-BR-22

A “Refund Issued” notification shall be sent to the Customer after a refund check is confirmed to be sent to the Customer or a refund is issued using the original payment method.

COR-BR-23

A “Request Received” notification shall be sent when a Customer has sent a request via email or mail.

COR-BR-24

Toll Enforcement Remedy notifications shall be sent when a Customer meets the HV conditions defined in Toll Enforcement Remedies.

COR-BR-25

Escheatment notifications shall be sent when a Customer meets the escheatment amount to generate a notification. Escheatment notifications shall be mailed.

COR-BR-26

Account change (from prepaid to postpaid or postpaid to prepaid) shall be sent when an Account transitions. This notification shall be sent to the Customer if a valid email address or cell phone number is provided.

COR-BR-27

An “Account Replenishment amount has changed” notification shall be sent when an Account’s replenishment amount is recalculated, or when an Authorized User changes the replenishment amount and the new amount is different from the current Account Replenishment amount. This notification shall be sent to the Customer if a valid email address or cell phone number is provided.

COR-BR-28

A “Credit Card expiration” notification shall be sent when an Account’s Credit Card is set to expire and has not been updated, and there is not another payment method on file. This notification shall be sent to the Customer if a valid email address or cell phone number is provided.

COR-BR-29

A “Credit Card has been updated” notification shall be sent when an Account’s Credit Card has been updated. This notification shall be sent to the Customer if a valid email address or cell phone number is provided.

COR-BR-30

A “Transaction has been cited” notification shall be sent when one (1) or more transactions for a vehicle’s License Plate have been cited. Only one (1) notification shall be sent if multiple transactions are cited. This notification shall be sent to the Customer if a valid email address or cell phone number is provided.

COR-BR-31

A “Payment Plan Installment Due” notification shall be sent X days prior to an installment due date where the installment has not already been paid.

TXN-BR-138

The customer shall be notified when a transponder is not read more than ten (10) times.

Reference S.B. 198: Requires tolling entities to notify customers with a transponder if more than 10 transponder misreads register on the customer’s account.

 

2.2          UC-08-01-02: Correspondences Configuration

T-BOS will allow for the configuration of Correspondence items and associated attributes by authorized user. T-BOS will trigger some correspondences/notifications to customers through the default mode that is defined in T-BOS SAC (Service Administrative Center) module based on account attributes, account flags, configurable parameters as per NTTA’s Business Rules. Fees associated with correspondence mailings can be configured per correspondence item.  Authorized users with defined role and privileges can change the configuration setting for the following:

  • Channel(s) available for delivery
  • Default Channel(s)
  • Opt-in/Opt-out
  • Fee associated with delivery of correspondence

Notification attributes will be configured within the backend service to include logic and configuration items such as:

  • Eligible address type(s)
  • Address Priority
  • Item frequency
  • Item criteria
  • Adding new item
  • Activating/ deactivating
  • Etc.

There are a few notifications that are triggered based on opt-in/opt-out preference made at customer’s account such as account activity and marketing/newsletters. T-BOS allow customers to select preferences associated with Address and Account Management functions, such as preferred mailing address(s) and language, as well as opt-in/opt-out preferences for correspondence. Customer Address Hierarchy will also be available for configuration in the SAC module, Ref. FSD 01-06 Address Management; Section 3.5. If customers select a notification channel that is tied to a fee, the customer will be alerted via a pop up and request the customer confirm the selection and authorize the fee.

T-BOS will record of each opt-in/out selection(s) that a customer has provided on the account. Ref. FSD 10-01 Customer Portals UC-10-01-04; Customer Service>Account Preferences; example of delivery options available for a specific correspondence, ability to opt in or out of email and SMS notifications.

2.2.1        Configuration Items

Key data Elements – SAC Configuration

Field

Mandatory/Optional

Values

Comments

Correspondence Name

Mandatory

Character

Correspondence name/ type

Default Channel

Mandatory

Character

Default for correspondence delivery

Channels

Mandatory

Character

All channels available

Opt-in/ Opt-out

Mandatory

Character

Available to opt-in or opt-out

Address

Mandatory

Character

Address(es) available within Hierarchy for delivery

Fee

Mandatory

Number

Fee associated with the delivery of correspondence

 

Key data Elements – Customer Account Preferences 

Field

Mandatory/Optional

Values

Comments

Correspondence Name

Mandatory

Character

Correspondence name/ type

Default Channel

Mandatory

Character

Default for correspondence delivery

Preference

Mandatory

Character

Customer can choose prefer channel where available.

Opt-in/ Opt-out

Mandatory

Character

Email or SMS opt-in for delivery; or opt-out of receiving a particular correspondence where available to do so.

 

2.2.2        Screen Layouts/Wireframes

 

UI-08-01-01: Sample SAC Configuration Screen for Communication Settings

2.2.3        Technical Design

Not Applicable

2.2.4        Requirements and Business Rules

Requirements and Business Rules Covered

Reference

Description

COR-REQ-32

The BOS shall provide Configurable settings for Notification channels for each Notification item; including, but not limited to:

COR-REQ-32.1

·        NTTA required Notification channel(s);

COR-REQ-32.2

·        customer preference, and;

COR-REQ-32.3

·        preferred address type for mailing; i.e., home, business, or ROV Lookup provided.

COR-REQ-6

The BOS shall provide the capability to Configure a default Notification channel, per Notification, should the Notification channel not be specified.

COR-REQ-47

The BOS shall provide the capability to set a fee, to be charged to the customer’s Account, for each Notification and Notification channel. If the fee is set to $0, the customer’s Account shall not reflect a fee charge when the Notification is generated and distributed.

COR-REQ-10

The BOS shall provide the capability for a Notification item to be distributed using multiple Notification channels; i.e., send the Notification via the customer’s preferred Notification channel, which is either by email or by mail, based on customer preferences and NTTA’s Business Rules.

COR-REQ-43

The BOS shall provide the capability to manage Notification items and their attributes; including, but not limited to:

COR-REQ-43.1

·        adding new Notification items;

COR-REQ-43.2

·        activating and deactivating items;

COR-REQ-43.4

·        adding a marketing Notification as a MBS message;

COR-REQ-43.5

·        item criteria;

COR-REQ-43.6

·        item frequency;

COR-REQ-43.7

·        sending for Third-Party address lookup;

COR-REQ-43.8

·        setting a variable due date, based on the Configurable number of days until payment is due;

COR-REQ-43.9

·        setting a fixed due date; i.e., monthly customer Anniversary Day;

COR-REQ-43.10

·        setting the number of days until action must be taken;

COR-REQ-43.11

·        setting the number of Calendar Days between the due date and escalation to the next Notification level;

COR-REQ-43.12

·        setting a number of Calendar Days between the creation date and issue date;

COR-REQ-43.13

·        setting a fixed issue date; i.e., monthly customer Anniversary Day;

COR-REQ-43.14

·        setting the number of Calendar Days between the creation date and issue date;

COR-REQ-43.15

·        setting the number of times to resend; i.e., three (3) times with no response, then stop;

COR-REQ-43.16

·        setting the number of days before the Notification is resent;

COR-REQ-43.17

·        setting to resend if a new address is received;

COR-REQ-43.18

·        setting to escalate, but not print, if address is marked ‘bad’;

COR-REQ-43.19

·        allowable Notification channel(s);

COR-REQ-43.20

·        Notification channel escalation;

COR-REQ-43.21

·        setting the number of days, from the mailing of the dispute reject letter, to extend the payment date;

COR-REQ-43.22

·        setting eligible address type; i.e., DPS Citation must be mailed to the ROV’s address, as provided by the ROV Lookup source;

COR-REQ-43.23

·        setting address source Priority; i.e., mail to the ROV Lookup address, and if that Notification is returned with a forwarding address, then use the forwarding address;

COR-REQ-43.24

·        updating the address on the Account, if a valid forwarding address is provided, based on NTTA’s Business Rules;

COR-REQ-43.25

·        setting the Notification response address; i.e., some Notifications may require that payment go to the Lockbox, while others require response be sent to the BOS;

COR-REQ-43.26

·        setting the Notification return address; i.e., some Notifications may use the return address of the Collection Agency, while others will use NTTA designated address(es);

COR-REQ-43.27

·        setting the Print/Mail Service Provider (if utilized);

COR-REQ-43.28

·        setting the Notification Quality Control review sample size, and;

COR-REQ-43.29

·        indicating whether Notification Quality Control review and approval is required.

COR-REQ-50

The BOS shall provide the capability for an Authorized User to set “opt-in” and “opt-out” options on an Account, for configured correspondence items; including, but not limited to:

COR-REQ-50.1

·        Account activity, and;

COR-REQ-50.2

·        marketing/newsletters.

COR-REQ-52

The BOS shall provide the capability for an Authorized User to Configure whether a customer may “opt-out” of a Notification item.

COR-REQ-53

The BOS shall provide the capability for Authorized Users, to select their preferred Notification channels for each Notification category; i.e., the customer may prefer Account letters and statements be sent via email, and Account activity, where a Credit Card payment failed, via SMS text and email.

COR-REQ-54

The BOS shall provide the capability for customers to opt-in for SMS messages.

COR-REQ-55

The BOS shall display the configured fee amount to be charged to the Customer, when selecting Notifications via the Configured Notification channel where a fee is charged.

COR-REQ-56

The BOS shall provide a message, visible to the customer, stating they are authorizing the Notification fee to be billed to their Account, each time the Notification is generated and distributed via the selected Notification channel.

COR-REQ-57

The BOS shall charge the customer’s Account, the configured fee, when a fee is charged for the Notification and Notification channel, for each Notification occurrence.

COR-REQ-51

The BOS shall properly record, retain and provide the capability of producing evidence of opt-in/opt-out selections made by the customers.

COR-BR-32

The Customer shall be charged a notification fee for a mailed notification based on the following schedule of charges.

 

No

Notification

Charge to Customer

1

Account application needs more information

0

2

Account Welcome Letter

0

3

Bad Address

0

4

Rejected/Failed Payment

0

5

Receipt (for any transaction)

0

6

Account Status Change (Closed, Suspended, etc.)

0

7

No Balance

0

8

Low Balance

0

9

Outstanding Amount Due

0

10

Overpayment

0

11

Account Update Confirmation (Name Changed, Vehicle Updated, etc.)

0

12

Excessive VTolls

0

13

License Plate Transponder Required

0

14

Statement is Ready

0

15

Monthly Billing Statement

For prepaid Accounts, $1.50 for every 3 Vehicles.

16

Request to update Temporary License Plate

0

17

Vehicle Ownership Change

0

18

Refund Issued

0

19

Dealership, Rental or Fleet Reassignment

0

20

Request Received or Updated

0

21

Toll Enforcement Remedies

0

22

Escheated Account

0

23

Account changed from prepaid to postpaid or postpaid to prepaid

0

24

Replenishment Amount has changed

0

25

Credit Card expiration

0

26

Credit Card has been updated

0

27

Transaction has been Cited

0

28

Account Agreement has been updated

0

29

Transponder Recall and/or Replacement

0

30

Transponder status has changed

0

31

Account Balance

0

32

Payment Plan Installment Due

0

Table BR-COR-2: Notification Schedule of Charges

 

 

2.3          UC-08-01-03: Correspondence Generation and Resending

T-BOS allows for the generation of notifications and correspondences through multiple methods;

  • Bulk generation
  • Manual generation
  • Resending

A backend service will assist in the bulk generation of notifications and correspondence. Ref. FSD 05-01 Monthly Billing Statements; Section 2, Figure 1 for an example of the generation process overview. Each correspondence item requiring bulk generation will be defined within the backend generation engine with a specific workflow to that correspondence item.Quality control with be included in the workflow as required in order to check a sample set of individual mail pieces to be sent to customers. Authorized users can request the generation manually or resend via the CSC portal application. Correspondence items meeting specified criteria will be resent using predefined logic, i.e. failed delivery will be sent to a back-up method as required.

2.3.1        Configuration Items

Not Applicable

2.3.2        Screen Layouts/Wireframes

Not Applicable

2.3.3        Technical Design

Not Applicable

2.3.4        Requirements and Business Rules

Requirements and Business Rules Covered

Reference

Description

COR-REQ-2

The BOS shall provide the capability for an Authorized User to manually generate and distribute Notifications.

COR-REQ-3

The BOS shall provide the capability to automatically generate and distribute Notifications.

COR-REQ-13

The BOS shall provide the capability to initiate bulk Notifications, either automatically, or manually, via any Configured Notification channel.

COR-REQ-27

The BOS shall provide Authorized Users with a common Notification management and creation process user interface.

COR-REQ-26

The BOS shall provide the capability for an Authorized User to schedule the generation and distribution of Notifications.

COR-REQ-24

The BOS shall provide the capability to manually select Notifications to be resent; i.e., when a new address has been provided.

COR-REQ-16

The BOS shall provide the capability to resend Notifications, which failed to be delivered, to another address or phone number, for the same delivery method or an alternate delivery method.

COR-REQ-18

The BOS shall provide the capability to automatically resend Notifications, after Skip Tracing activities return a new address.

COR-REQ-42

The BOS shall provide the capability to specify the Configurable actions and workflow, which can be taken for each category of conditions that require Quality Control; i.e., when reviewing Notifications that the Authorized User can ‘approve’, ‘reject’ or ‘correct’ errors identified during the review process.

COR-BR-8

Receipts may be sent manually to a Customer, by an Authorized User, as requested by the Customer.

 

2.4          UC-08-01-04: Tracking and Distribution

T-BOS will track the various stage(s) which the correspondence item would undergo within T-BOS. The stages which a correspondence item undergoes will vary, however, T-BOS will standardize the use of statuses which are assigned. The print vendor also provides a feedback a response file containing detailed response codes per for each correspondence submitted as to when the correspondence was printed and mailed or sent via email or text. T-BOS will consume this information and store its against the correspondence item for future references.  Authorized user can track a notification delivery response for each individual notification by viewing additional details such as status, notification record (channel, type, date, due date, etc.).

Response codes will also be mapped to actions that TBOS is required to perform and includes:

  1. SUCCESS – When we receive this code, the correspondence should be considered as successfully sent to the customer, no action is needed by T-BOS at this point other than logging the status code.
  2. TBOS no action – Success – Correspondence was sent successfully/ has been completed, no other action needed. Log status code.
  3. TBOS No Action – Same as “TBOS no action – Success”
  4. Ignore – There is not a matching COA or an invalid COA. TBOS should NOT update the address in these cases and should continue with the normal process or potentially trigger next delivery method. Log code received.
  5. TBOS Opt out –The customer should be opted out of the delivery channel if applicable. If opt-out is applicable for correspondence items, update communication preference to the next delivery method available for the correspondence item. Log code received.
  6. TBOS wait X-days for follow-up code – No Action at this time until a follow-up code is received. During this time QM will be trying to resolve the issue related to the status code/ reattempting delivery of the correspondence item. Log code received. If TBOS does not receive a response after X days, TBOS will trigger the correspondence item to be sent via the next available channel. If no other channel is available a case will be created for MBS, MAS and TER related correspondences, all other correspondence types will have the response code logged in the exception table.
  7. QM Retry –No Action performed until a follow-up code is received. During this time QM will be trying to resolve the issue related to the status code/ reattempting delivery of the correspondence item. Log code received.
  8. QM Investigate – No Action performed until a follow-up code is received. During this time QM will be trying to resolve the issue related to the status code/ reattempting delivery of the correspondence item. Log code received.
  9. Send to Manual Queue – This may be the instance of a future code that we currently do not have a mapping for or other exception response code which requires manual review. A Case will be created and capture relevant information to the correspondence that was attempted to be sent to the customer.Log code received.
  10. Mark Bad Address– Mark existing address as bad, assumes bad delivery, need to trigger correspondence to be sent using the next available channel if no COA or good address is provided with return file. Log code received.
  11. Mark Bad Address, send to manual queue– Mark existing address as bad, follow same steps in “Send to Manual Queue”. Log code received.
  12. Update with new address – Mark existing address as bad and update with returned COA address for future system use. Log code received.

T-BOS will internally assign a status to each notification for tracking purposes , visible through the UI to CSRs and other authorized users, including but not limited to:

  • Triggered
  • In Quality Control
  • Sent to 3rd Party Notification distributor
  • Acknowledged by 3rd Party Notification distributor
  • Distributed
  • Undeliverable
  • Delivered
  • Follow-up sent
  • Re-queued
  • Re-issued

Other attributes of customer correspondence/notification will be available for authorized user to access and view the details.

2.4.1        Configuration Items

Not Applicable

2.4.2        Screen Layouts/Wireframes

Not Applicable

2.4.3        Technical Design

Not Applicable

2.4.4        Requirements and Business Rules

Requirements and Business Rules Covered

Reference

Description

COR-REQ-25

The BOS shall provide the capability to update the mailing date, upon successful mailing of the Notification, as verified and provided by the Print/Mailing Service Provider.

COR-REQ-15

The BOS shall provide the capability to display on the Notifications that it was regenerated because of retrieval of a new contact information, for any Notification channel.

COR-REQ-44

The BOS shall store the mailing date for each Notification item.

COR-REQ-68

The BOS shall provide the capability to track a Notification delivery response for

each individual Notification.

COR-REQ-69

The BOS shall provide the capability to send a follow-up Notification, via the

same Notification channel previously used, if no response is received or an

unsatisfactory response is received.

COR-REQ-70

The BOS shall provide the capability to send follow-up Notification, through a

different Notification channel, if no response is received or an unsatisfactory

response is received.

COR-REQ-71

The BOS shall provide reconciliation of all Notifications transmitted to Third-

Party Notification distributors.

COR-REQ-72

The BOS shall provide the capability to send an Alert, if reconciliation has not

been received in a Configurable amount of time.

COR-REQ-73

The BOS shall provide the capability to assign a status to each Notification;

including, but not limited to:

COR-REQ-73.1

· triggered;

COR-REQ-73.2

· in Quality Control;

COR-REQ-73.3

· sent to Third-Party Notification distributor;

COR-REQ-73.4

· acknowledged by Third-Party Notification distributor;

COR-REQ-73.5

· distributed;

COR-REQ-73.6

· undeliverable;

COR-REQ-73.7

· delivered;

COR-REQ-73.8

· follow-up sent;

COR-REQ-73.9

· re-queued, and;

COR-REQ-73.10

· Reissued.

COR-REQ-74

The BOS shall provide the capability to create a Notification record for each Notification generated; including, but not limited to:

COR-REQ-74.1

· Notification channel;

COR-REQ-74.2

· Notification type;

COR-REQ-74.3

· Account Notification preference and last update date/time;

COR-REQ-74.4

· date the Account triggered to have that Notification generated;

COR-REQ-74.5

·  date the Notification was generated;

COR-REQ-74.6

· date the Notification was sent to the Third-Party Notification distributors;

COR-REQ-74.7

·  due date (if applicable);

COR-REQ-74.8

· date the Notification was printed;

COR-REQ-74.9

·  date the Notification was mailed;

COR-REQ-74.10

·  date the Notification was identified as undeliverable;

COR-REQ-74.11

·  date the Notification was delivered;

COR-REQ-74.12

· date the Notification was re-queued, and;

COR-REQ-74.13

 

·  date the Notification was Reissued; i.e., if a Notification is returned with a forwarding address, a new Notification is sent to the new address.

COR-REQ-75

 

The BOS shall provide additional functionality and reporting as necessary for NTTA to comply with communication and privacy laws (such as the Telephone Communication Protection Act (TCPA) and the CAN-SPAM Act) and other laws applicable to the transmission of consumer notifications.

 

2.5          UC-08-01-05: Correspondence/Notification Suppression

TBOS allows notifications to be suppressed based on defined criteria, account attributes etc.; i.e. T-BOS will interface with the print vendor to receive updated status in terms of bounced or undeliverable correspondence, emails, texts, phone calls. Once the account flag or attribute has been updated, T-BOS will suppress notification until the condition is removed.

Notifications can also be manually suppressed by authorized users with specified roles and privileges.

2.5.1        Configuration Items

Field

Mandatory/Optional

Values

Comments

Account Flag

Mandatory

Character

Specified Account Flag

Account Attribute

Mandatory

Character

Specified Account Attribute

 

2.5.2        Screen Layouts/Wireframes

Not Applicable

2.5.3        Technical Design

Not Applicable

2.5.4        Requirements and Business Rules

Requirements and Business Rules Covered

Reference

Description

COR-REQ-17

The BOS shall provide the capability to prevent Notifications from being sent to addresses marked as undeliverable or bad.

COR-REQ-20

The BOS shall provide periodic Configurable checks for bad (bounced) emails, or upload bad email addresses from the email verification vendor, and mark the email addresses as undeliverable after a Configurable number of failed delivery attempts.

COR-REQ-21

The BOS shall provide the capability (Configurable) to send a Notification to a customer, regarding an undeliverable email situation, by using a different Notification channel.

COR-REQ-22

The BOS shall provide the capability to mark phone and fax numbers as bad, after a Configurable number of failed contact attempts.

COR-REQ-23

The BOS shall provide the capability (Configurable) to send a Notification to a customer, regarding a bad phone or fax number situation, by using a different Notification channel.

COR-REQ-59

The BOS shall provide the capability for Authorized Users to suppress the generation of all or a particular Notification item, for a specific Account; i.e., a supervisor may have already spoken with a customer and may not want a returned payment Notification to be sent.

COR-REQ-60

The BOS shall provide the capability to suspend all correspondence for a specific Account, for a Configurable default number of days, and up to a Configurable maximum number of days, with auto-expiration.

COR-REQ-61

The BOS shall provide the capability for Authorized Users to override the correspondence suspension.

COR-BR-1

Correspondence shall not be mailed to a Customer when every mailing address on the Customer’s Account is bad

COR-BR-2

Correspondence shall not be emailed to a Customer when every email address on the Customer’s Account is bad.

COR-BR-3

Correspondence shall not be texted or sent via SMS to a Customer when every cell phone number on the Customer’s Account is bad.

 

2.6          UC-08-01-06: Recipient Lists

T-BOS will generate recipient lists for specific correspondence pieces, distributions and notifications based on predefined business and system process triggers.Authorized users can also generate ad hoc distribution listsbased on criteria such as:

  • use of a particular Roadway or Location (overall or by direction);
  • use of a particular Toll Plaza (overall or by direction);
  • use of a particular toll ramp (overall or by direction);
  • use of a particular Roadway, Plaza or lane during a specified period of time;
  • use of a particular payment method;
  • transactions by zip code;
  • transactions by Vehicle Class;
  • transactions by Account Attribute;
  • transactions by Account Flag(s);
  • transactions by Discount Plan;
  • transactions by transponder type;
  • recipients of DPS Citations issued for selectable Roadway use;
  • recipients of DPS Citations issued for selectable time periods, and;
  • recipients of DPS Citations issued for a combination of selectable Roadway use and selectable time period.

 

Seed lists will be used as a Quality Assurance / Quality Control mechanism. T-BOS will allow for the use of Seed Lists, and as indicated in the Correspondence Matrix, which can be configured and maintained through T-BOS’s SAC module by authorized users based on defined roles and privileges.

2.6.1        Configuration Items

Not Applicable

2.6.2        Screen Layouts/Wireframes

Not Applicable

2.6.3        Technical Design

Not Applicable

2.6.4        Requirements and Business Rules

Requirements and Business Rules Covered

Reference

Description

COR-REQ-34

The BOS shall provide the capability (Configurable) to include a Seed List, in each day’s Notifications, to provide Quality Control over the Notifications being generated.

COR-REQ-35

The BOS shall provide the capability to use Seed Lists in all Notification channels.

COR-REQ-36

The BOS shall provide the capability to add the Seed List information regardless of whether they match the criteria for the particular Notification, or not.

COR-REQ-37

The BOS shall provide the capability, to prevent Notifications generated for a Seed List, from escalating.

COR-REQ-38

The BOS shall provide the capability, to prevent Notifications generated for a Seed List, from creating expected revenue.

COR-REQ-39

The BOS shall provide the capability, to set Account Attributes related to the Seed List rules, for each Notification item; including, but not limited to:

COR-REQ-39.1

·        names and addresses for Seed List recipients;

COR-REQ-39.2

·        assigning specific Seed List addresses to Notification items;

COR-REQ-39.3

·        number of Seed List Notifications by item;

COR-REQ-39.4

·        number of Seed List Notifications by channel, and;

COR-REQ-39.5

·        number of Seed List Notifications by day.

COR-REQ-46

The BOS shall provide the capability to select a Notification target audience, for either pre-developed or ad hoc Notification, using criteria; including, but not limited to:

COR-REQ-46.1

·        use of a particular Roadway or Location (overall or by direction);

COR-REQ-46.2

·        use of a particular Toll Plaza (overall or by direction);

COR-REQ-46.3

·        use of a particular toll ramp (overall or by direction);

COR-REQ-46.4

·        use of a particular Roadway, Plaza or lane during a specified period of time;

COR-REQ-46.5

·        use of a particular payment method;

COR-REQ-46.6

·        transactions by zip code;

COR-REQ-46.7

·        transactions by Vehicle Class;

COR-REQ-46.8

·        transactions by Account Attribute;

COR-REQ-46.9

·        transactions by Account Flag(s);

COR-REQ-46.10

·        transactions by Discount Plan;

COR-REQ-46.11

·        transactions by transponder type;

COR-REQ-46.12

·        recipients of DPS Citations issued for selectable Roadway use;

COR-REQ-46.13

·        recipients of DPS Citations issued for selectable time periods, and;

COR-REQ-46.14

·        recipients of DPS Citations issued for a combination of selectable Roadway use and selectable time period.

 

2.7          UC-08-01-07: Notification History, Storage and Viewing

Correspondences that are triggered and sent to customers will stored and linked to the customer account automatically if generated and sent from T-BOS or upon receipt from the print vendor. T-BOS will interface with the print vendor in order to obtain scanned documents i.e. envelopes and associate to the customer’s account. These correspondence items can be accessed by the customer and an authorized user. T-BOS will provide a notification dashboard on each account that will be accessible by an authorized user with specific roles and privileges.Authorized users will be able to search for correspondence and notification items, view and print and have been previously covered in the following FSD’s and use cases:

1.FSD and SDD 01-01 Account Management; UC-01-01-21 – for the customer viewing correspondences associated with their account.

2.FSD18-01 Global System Requirements; Section 4, Searches

3. FSD 10-01 Customer Portals; UC-10-01-04 and -5;Screenshots, Documents > Received Documents

2.7.1        Configuration Items

Not Applicable

2.7.2        Layouts/Wireframes

Not Applicable

2.7.3        Technical Design

Not Applicable

2.7.4        Requirements and Business Rules

Requirements and Business Rules Covered

Reference

Description

COR-REQ-44

The BOS shall store the mailing date for each Notification item.

COR-REQ-49

The BOS shall provide a Notification Dashboard on each Account, accessible by an Authorized User.

COR-REQ-58

The BOS shall provide the capability to ensure historical Notifications, associated with Accounts, do not change (maintain original form and content), regardless of any changes that are subsequently made to the template for that Notification item.

COR-REQ-62

The BOS shall provide the capability for an Authorized User to upload documentation, to complete a customer request, where additional documentation is required (i.e. Bill of Sale).

COR-REQ-63.1

·        the BOS shall link the documentation to an existing Account and customer Case, and;

COR-REQ-63.2

·        provide a link to the documentation, from the customer’s Account, and Case.

COR-REQ-64

The BOS shall provide the capability to automatically associate a copy of the Notification, with the Account, upon successful distribution of the Notification.

COR-REQ-65

The BOS shall provide the capability for Authorized Users to access Notifications generated for the Account.

COR-REQ-66

The BOS shall provide the capability to electronically deliver receipts, based on the choice of the Authorized User or customer; i.e., a receipt may be displayed, with print options, emailed, or sent by text.

COR-BR-33

A Customer can print and download any notifications associated with their Account.

COR-BR-34

Notifications that are downloaded or printed from a Customer’s Account shall be watermarked “COPY”.

 

2.8          UC-08-01-08: Barcodes, Scan Lines and QR codes

Bulk mailings requiring the use of barcodes, scan lines and QR codes for the identification of and associations with customer account with be handled via the print vendor (Questmark). The insertion of barcodes, scan lines and QR codes to notifications and envelopes with be the responsibility of the print vendor (Questmark).

2.8.1        Configuration Items

Not Applicable

2.8.2        Screen Layouts/Wireframes

Not Applicable

2.8.3        Technical Design

Not Applicable

2.8.4        Requirements and Business Rules

Requirements and Business Rules Covered

Reference

Description

COR-REQ-29

The BOS shall provide the capability to add a barcode, scan line, or quick response code (QR Code), to each outgoing Notification (excluding text and email body), so the returned Notification can be scanned and automatically associated with the proper Account, and if applicable, Case.

COR-REQ-30

The BOS shall provide the capability to include a barcode, scan line, or quick response code (QR Code), to each outgoing envelope for processing returned mail, so that the returned Notification can be scanned and automatically associated with the proper Account, and if applicable, Case.

COR-REQ-14

The BOS shall provide the capability to read and create the USPS Intelligent Mail Barcode (IMB), for both incoming and outbound mail.

 

2.9          UC-08-01-09: Template Management

Template management will be provided via a third-party vendor (Questmark). Authorized users will manage templates and perform associated actions via the functionality provided by this vendor. T-BOS will interface with the print vendor and exchange data information as needed.

2.9.1        Configuration Items

Not Applicable

2.9.2        Screen Layouts/Wireframes

Not Applicable

2.9.3        Technical Design

Not Applicable

2.9.4        Requirements and Business Rules

Requirements and Business Rules Covered

Reference

Description

COR-REQ-31

The BOS shall provide the capability (Configurable) to define hardcopy Notification type and size; i.e., postcard or letter.

COR-REQ-27

The BOS shall provide Authorized Users with a common Notification management and creation process user interface.

COR-REQ-28

The BOS shall provide standard templates for each Notification item, which are editable by Authorized Users.

COR-REQ-7

The BOS shall provide the capability to generate the Notification using the active (Configurable) template for the Notification item.

COR-REQ-40

The BOS shall provide the capability to create and assign version numbers and revision dates to Notification item templates.

COR-REQ-41

The BOS shall provide the capability and require an Authorized User to approve a Notification item template, before putting it in use.

COR-REQ-43.3

·        viewing and selecting for the activation of past versions of items;

COR-REQ-45

The BOS shall provide the capability for Authorized Users to view all versions of each Notification item template (including those items that have been modified); including, but not limited to:

COR-REQ-45.1

·        date modified;

COR-REQ-45.2

·        version number;

COR-REQ-45.3

·        User ID of who made the modification(s), and;

COR-REQ-45.4

·        samples of the Notification as it looked in all previous versions.

 

3       Appendix: Requirements Traceability

The attached table includes all requirements and business rules that are included in this FSD.  Any requirement or business rule in the appropriate sections that have been excluded are identified.