dmdc ccc-ticketing system requirements v7b

Defense Manpower Data Center Consolidated Contact Center

- PSA _ CSR Ticketing System -Business Requirements Document (BRD)

Version 1.1 - Ken Fulmer Feb 21, 2013

INSPIRITEC CONFIDENTIAL MATERIAL

INSPIRITEC CONFIDENTIAL

Document Version Control

Version Date Change Description Author

1.0 2/15/13 Initial version Ken Fulmer

1.1 2/21/13 Updated with comments from 2/20/13 review Alecia Chrin

TABLE OF CONTENTS

1 PROJECT OVERVIEW...........................................................................................................3

1.1 Business Areas Impacted........................................................................................3

1.2 Business Assumptions............................................................................................3

2 REQUIREMENTS................................................................................................................... 5

2.1 Business Requirements...........................................................................................5

2.1.1 Ticket Information Requirements................................................................................5

2.1.2 SSN Privacy approach...............................................................................................9

2.1.3 Application and Sub Application Areas.....................................................................10

2.1.4 Knowledge Base Requirements...............................................................................11

2.1.5 Escalation Procedure Requirements........................................................................11

2.1.6 Tracking and Monitoring...........................................................................................12

2.2 Interface Requirements..........................................................................................13

2.3 Report Requirements.............................................................................................13

2.3.1 Report 1 - The Daily Operations Report...................................................................13

2.3.2 Report 2 – AQL Report.............................................................................................14

2.3.3 Report 3 – Monthly Operations Summary................................................................14

2.4 Non-Functional Requirements..............................................................................15

of 15

DMDC-CCC Business Requirements Document


1 PROJECT OVERVIEW

The primary purpose of this document is to set the scope and requirements for the Personnel Security Assurance (PSA) ticketing system, which will be leveraging the Computer Associates (CA) Service Desk Manager (CA-SDM) application. The system will be used to take phone calls and other contacts to get support for key PSA systems as described in the Consolidated Contact Center (CCC) Performance Work Statement (PWS).

The CA Service Desk Manager was selected as it is integrated with other Defense Manpower Data Center (DMDC) call center components, and therefore is a logical tool to use for the CCC operation. There was a further decision to install the system on site at Ft. Knox, to enable a simplified network operation for a short term start up.

The scope of the system is short term focused to get operational with the PSA calls by April 1, 2013, the go live date.

The system will track the call status of all PSA calls that DMDC is responsible for, including the Joint Personnel Adjudication System (JPAS), Electronic Questionnaires for Investigations Processing (e-QIP), Defense Central Index of Investigations (DCII), and Secure Web Fingerprint Transmission (SWFT) systems. It will also handle all contact types (phone, email, etc.) as well three (3) escalation levels.

The first escalation level is the Tier 1 contact center reps who have been trained in handling calls in a specific problem area; calls will be directed to the Tier 1 reps via a call routing capability in the phone switch to a queue. That queue will be responded to by the first available agent in that area. The second escalation level is the Tier 2 reps; these are more deeply trained specialists and trainers who also can spend more time with the caller or conduct research. The Tier 2 reps are part of the contact center staff. The third level of escalation is Tier 3. Escalation to Tier 3 takes place when a contact issue is needed to be sent to someone outside the direct control of the contact center. The call tracking system will keep track of the issue and age the issues for time outstanding, and track the issue until it is resolved.

Reporting is also part of the scope of this requirement definition. There are several types of reports - for operational, AQL management, and internal performance management needs. Reports are mostly run on a schedule, but can also be ad-hoc. Scheduled and ad-hoc reports and queries are intended to remain small, so that they minimize the performance impact on the call center’s CA-SDM application.

1.1 Business Areas Impacted

The ticketing system is for use by InspiriTec to be used in support of the DMDC consolidated contact center.

1.2 Business Assumptions

This section documents any assumptions related to the project.

of 15



Identifier Assumption Internal or External

AS1 There are no electronic interfaces from the call tracking system to DMDC applications in scope at this time.

DMDC and caller impact

AS2 The startup date will constrain decisions to take a short term focus to get operational in a timely manner.

External

AS3 All calls/contacts will be closed in the ticketing system. Any Tier 3 agency or group will need to communicate ticket closure status back to the contact center.

InspiriTec will track all calls and update status info until closure

AS4 Infrastructure such as network and telephony is the responsibility of Ft. Knox and DMDC government organizations.

Per project plan

AS5 Responsibility for backups will be with the Fort Knox Data Center, this is agreed upon by Ft. Knox NEC.

Fort Knox Data Center

AS6 Responsibility for patching the OS will be with the Fort Knox Data Center.


AS7 Responsibility for patching Service Desk will be with HP / InspiriTec.

HP/InspiriTec

AS8 Responsibility for patching SQL Server will be with the Fort Knox Data Center.


AS9 Availability of Military Base Facilities and Infrastructure will be the responsibility of Ft. Knox and DMDC government organizations.

DMDC, Ft. Knox NEC

of 15



2 REQUIREMENTS

This section presents requirements that must be fulfilled by the proposed solution.

2.1 Business Requirements

The Service Desk ticketing system will allow the PSA contact center operation to capture, track and report on all functional and technical inquiries received by InspiriTec’s PSA agents.

PSA agents will provide support for the following applications: DCII, JPAS, e-QIP and SWFT and provide response to related procedural and policy inquiries. The ticketing system should support relevant sub-tasks which may include:

1) Assist users with application execution / installation2) Assist with completing user application3) Reactivate record within eQIP or JPAS4) Troubleshoot/resolve application issues5) Review site/application ticket call history (See reporting section)6) Clearly document customer issues in trouble ticket7) Answer FAQs8) Other technical support as needed9) Escalate issues as needed via a DMDC application such as Data Request System

(DRS); See escalation procedures10) Explain policies and procedures applicable to the personnel security program11) Troubleshoot all client call problems within scope of the defined PSA applications. 12) Update/create troubleshooting documents for common issues to provide to customers.13) Provide customers with troubleshooting documents14) Contribute towards DMDC Message Board- CCC will provide monthly suggested

updates. This is not an electronic interface.15) Monitor email, fax, voicemail, and other customer communication methods.16) Provide and update recorded announcements in the event of any system outage or

production slowdown to avoid callers reaching an agent to get the same information. of any agency or location wide issue for customers calling the call center

The following sections outline the minimum requirements of the current Personnel Security/Assurance Applications Information Management System (IMS). All fields are subject to change in the future as needed.

2.1.1 Ticket Information RequirementsAll Tickets will collect the basic information listed below.

of 15



2.1.1.1 Contact Profile Information

Field Name Description Format

Name Full Name DefaultPrimary phone number (unique key)

Used as primary lookup 10 digit plus 4 for ext

SMO code Security Management Office code

7

CAGE code 7Email address DefaultAlt Phone number Allow 2nd phone 10+4User ID optional DefaultUser Key Work To Be Defined by User(optional) 12 characters alphanumeric

a) Contact primary phone number (This will be the first field entered), and is the key between the contact info and the ticket info.

b) User’s name will be captured and verified by the Customer Service Representative (CSR) to confirm the caller’s id along with at least one other item of verification from the contact profile to validate that the caller is who they say they are.

c) User’s email address will be used if follow-up is requiredd) User’s alternate phone for call back, if other than the primary phone number.

2.1.1.2 Ticket Information

Field Comments Length

Ticket Number

System generated with YY as a prefix Default field length and structure

Type Incident or RequestDefault to Incident

Default

Application Area

List of Values – JPAS, eQIP, SWFT, DCII, General, SAR

CA-SDM Category

Application Sub Area

See Table below for values CA-SDM Sub Category for each category

Source of Ticket

Phone, Fax, Email, Paper Mail, Web, Other Drop Down List

Need By Date

Customer requested completion date Default

Caller Social Security Number

Use if required - will be displayed only to the rep assigned to the ticket 9 numeric – no dash or space

of 15



Field Comments Length(SSN)Affected Subject Name

Optional field – use if needed Default name field length

Affected Subject SSN

Use if required - display only to the agent who is currently assigned the ticket 9 numeric

Affected Subject Date of Birth

Use only if required MM/DD/YYYY

Affected Subject Phone #

Use only if required 10+4

Affected Subject email

Use only if required Default

Nominating Official Name

Use only if required – optional text field to be used as needed on SAR and other tickets.

Default for a name

Priority Default 1-5 Values to Be defined DefaultProblem Description

Open field text to describe the problem Default length

Problem Summary

Optional Summary of Problem Default length

Notes Area to describe ticket activity and changes to the ticket and who made the change and when

Default values and length

Status Open, Closed, Tier 3, Under Review and Waiting DefaultSAR Resolution

Processed And Accept- Accept

or Rejected with reason codes of:i. Reject - Obsolete SAR form submitted

ii. Reject - Incomplete SARiii. Reject - No LOA submitted (JPAS primary account managers – Industry)iv. Reject -Nominating official not KMP in ISFD v. Reject - Military’ request (JPAS)

vi. Reject - User’ (or ‘non-primary’ account manager) request (JPAS, DCII, SWFT)

vii. Reject - Applicant not eligible for requested accessviii. Reject - Applicant already possesses requested access

List of Values

Escalation Change in ticket assignment in terms of the person or group DefaultRoot Cause Table of Values – Hold for future table definition List of Valid Values Related Ticket Number

Optional field - with up to 5 values of ticket numbers Alphanumeric, 50 characters

Ticket Ticket open – date/time, close date/time ; status change date/time, etc. Use standard values

of 15



Field Comments LengthDate, time indicators

of CA-SDM

All ticket fields are defaulted to the standard system values where possible, including links to the knowledge base and to the contact profile information. For AQL reporting purposes a ticket is open whether it is open to Tier 1 or Tier 2.

2.1.1.2.1 Handling of the Affected Subject InformationSome tickets will not be about the caller but about an affected subject. An example is an industrial Facility Security Officers (FSO) calling about a person in their organization applying for a security clearance. In cases where it is appropriate to the ticket the agent will fill in the Affected Subject data values as needed. The SSN value is usually required for such situations, and as such the SSN follows the same Personally Identifiable Information (PII) rules of only being displayed to the agent who has the ticket assigned and is left blank in all other situations.

2.1.1.2.2 Default ValuesThe normal Service Desk Management handling values are assumed to take the defaults. A partial list is included here for illustration -

Ticket number – Sequential number assigned by the system Date/time opened – System assigned based on system date and time Days/time elapsed – System calculated based on time open to time closed Date/time closed – Entered by system date at the time the ticket is in status = closed Related Ticket Number – Assigned by CSR for any reference – optional field with up to 5

values of ticket numbers.

of 15



2.1.2 SSN Privacy approach

The Social Security Number (SSN) privacy solution for the PSA helpdesk will be similar to, and based on the solution used by the DMDC Support Office (DSO) call center solution. Not only will this approach provide an easier transition when DSO is brought into the CCC solution, but it will also provide consistent protection for PII data. This solution will only display the SSN to the CSR assigned to the ticket.

When a PSA phone call goes to the CSR, the CSR/System will call up the CA SDM contact record using the caller's Primary Phone Number. The CSR will use the SSN to access JPAS through the application itself. Since CA-SDM assigns a 'ticket number' or 'case ID' to each caller event, the information about the CSR resolution will be stored by case ID or ticket number in the comments section. No PII data will be written into the text because the CSR resolution information is linked to the contact information by case ID/ticket number in the application. With this approach, there will always be a way to find out incident history for a given caller.

The requirements for this approach are listed below:

Each ticket will support only 1 affected user. If an FSO calls about multiple affected users, that will result in multiple tickets.

The contact database will not be pre-populated with data. As incidents are received, the contact database will be populated over time with user information.

Each incident will contain 2 custom fields: Caller SSN, and Affected Party SSNo Any values optionally entered in these fields will be displayed only to the person

to whom the ticket is assignedo These fields will not appear on any reportso These fields will not be transferred to Tier 3o The fields will be visible only to the CSR to whom the ticket is assignedo Tickets are assigned to an agent by name

All ticket creation will begin in the Profile Browser. When the ticket is created, the Assignee field will be auto-populated with the creator

name. The ticket will always have an Assignee who can view the SSN, if an SSN is entered.

Typical process flowo FSO calls; CSR will ask for name, email, phone number, etc. If the FSO’s

contact exists in the system, the appropriate fields will auto-populateo FSO will describe the inquiry for the affected partyo If the inquiry requires storing the SSN, agent will ask for the SSN by phone, and

enter it in the appropriate field All adjusting "activity" done to the ticket is inherently tracked. When a ticket is escalated to Tier 3

o Status is set to “Moved to Tier3”o Ticket stays assigned to a Tier 2 agento Updates to the ticket are made by the Tier 2 agento If there is an SSN related inquiry from Tier 3, the assigned Tier 2 agent will look

up the Affected Party SSN field and relay the SSN over phone to the Tier 3 agent The SSN will not be encrypted in the database for the current phase

of 15



2.1.3 Application and Sub Application Areas

Application Sub-Application

JPAS Password Reset

Account Setup

Tech Question

General/Other

Record Reactivation

eQIP Password Reset

Golden Question reset

Application Submission

Tech Question

SWFT Password Reset

Account Setup

General/Other

Tech

DCII Account Setup

Password Reset

Tech

General/Other

General Adjudicative/Clearance Inquiry

Investigation Status

General Personnel Inquiry

Compelling Need

Congressional Inquiry –Govt.

SAR JPAS,

SWFT

DCII

of 15



Application Sub-Application

2.1.4 Knowledge Base Requirements1) There will be several thousand knowledge base articles in the ticketing system to support

the information needed to respond to calls. Either the full text of the information, or a Uniform Resource Locator (URL) link to the information will be stored in the CA-SDM ticketing system

2. The information will have a header record that will contain the following fields: Title, Description, and Resolution information; and this will be used for search and retrieval. This information will be assigned by InspiriTec on each Knowledge Management (KM) article for loading into the KM database.

3. The KM articles will be in the Acrobat PDF format for inclusion into the KM database .

4. The template for loading the PDF articles is as follows:

Category (e.g. JPAS)

Title of Article Problem SummaryThis section will contain keywords

FileName for the attachment

5. The underlying articles will contain both specific solutions for solving common problems, as well as entire online user guides, administrator guides, and other documents for use by the CSR, or Tier 2 reps in resolving problems. So, an attached PDF file may be as small as 1-3 pages, or it could be a large document of 100+ pages.

2.1.5 Escalation Procedure RequirementsWhile the ultimate goal is to create a one call resolution philosophy, processes have been developed to accommodate Tier 2 and Tier 3 escalations

2.1.5.1 Tier 2 Escalation RequirementsThe following types of calls are usually escalated to the Tier 2 reps:

Customer complaints of service, either via phone or email Advanced troubleshooting

If the Tier 1 CSR cannot resolve the issue within 5 minutes or whatever the sub-application guideline indicates, the call will be escalated to Tier 2. Any call that is beyond the skill level of knowledge of the Tier 1 CSR to resolve will also be escalated to the team leader for that application area. The phone call and ticket information will be saved, and the issue will be transferred to the team leader, who will act as the Tier 2. Since the CA-SDM ticket doesn’t have

of 15



the capability to make the assessment if the ticket is beyond the skill level of the CSR, a manual assignment of the ticket by the Tier 1 CSR to Tier 2 will take place.

At the time of the transfer, the status of the ticket will be set to “Open” and moved to Tier 2 for handling of the ticket. Information will otherwise remain unchanged until acted upon by the next agent in Tier 2. A status of Under Review and Waiting is assigned if the ticket requires special research to finalize the issue. For AQL reporting, the status will report which level of agent is handling the call, and for what period of time.

At the completion of the Tier 2 escalation, if the issue is resolved, the disposition of the ticket will be noted as “Closed”, and the resolution will be added into the description field for the CSR to review. If the issue is not resolved, then it will be marked as needing follow-up, but will not be completed in real time. This will initiate the date and time of the status tracking.

In the reporting section, any item that is not closed, and not escalated to Tier 3 will be aged, and a daily operations review will focus on any items that are open for more than one day, and a plan developed for each item to be resolved. If items age more than 2 business days, then the Call Center Manager will decide if those calls need to be elevated to Tier 3 for assistance.

2.1.5.2 Tier 3 Escalation Requirementso Any call or contact that cannot be resolved by the on-site call center would need

to be transferred to specialists outside the call center, such as to DMDC, Defense Security Service (DSS), the sustainment team, or other contract firms for resolution. The ticket will be marked as escalated to the organization that it is being transferred to. The ticket date and time of the escalation will be recorded to the database, and the specific person or group assigned will be noted.

o A status code of “Moved to Tier 3” will be established and assigned to tickets escalated to Tier 3. This will leave the ticket still assigned to a Tier 2 agent on site, and that Tier 2 agent will have control of the ticket while any offsite follow-up at Tier 3 is taking place.

o A manual email follow-up to the DMDC program office, and to the receiving organization will be generated to confirm that this action has been taken, and the email will contain the ticket number and relevant information from the description. In the email, the Tier 2 agent will select text from the description field and cut and paste that into the email system for manual email forwarding. In addition, the agent may call the Tier 3 group to confirm receipt for the ticket handling.

o Also included will be instructions to send notice back to the On-Site Call Center so that the ticket can be tracked, and closed upon notice back of final disposition from the Tier 3 group.

o The Government lead will attempt to resolve the issue. If not able to do so, the issue will be forwarded to Program Manager for further assistance.

o All issues statuses will be logged in the Tier 2 Support Tracking Log.

2.1.6 Tracking and Monitoring

2.1.6.1 Tracking Access Types

of 15



In CA-SDM, there are Access Types associated with the Contact Types. The standard Contact Types in CA-SDM are:

Analyst Employee Group Guest

For this implementation, we will create two(2) Access Types for the Analyst Contact Type:

Analyst I Analyst II

These two Access Types will allow CA-SDM to differentiate between Tier I and Tier 2 Analysts. All Tier 1 agents will have an Access Type of Analyst I, and all Tier 2 agents will have an Access Type of Analyst II in CA-SDM.

One can find out if a given agent is part of the Tier 1 or the Tier 2 group by clicking on the agent’s name in the ticket; this will take the user to the agent’s contact info where the Access Type will reveal if the agent is a Tier 1 or Tier 2 agent.

2.1.6.2 Monitoring Ticket Escalation LevelIn order to monitor ticket escalation levels (identify if a given ticket is being worked on at the Tier 1 or the Tier 2 escalation level), the solution will be implemented with a checkbox to indicate that the ticket is being escalated to Tier 2. When the ticket is being moved to Tier 2, the Analyst would check the box and save the ticket. This would create an entry in the activity log when field is changed.

One can see if a ticket is being worked by the Tier 1 or Tier 2 agents by inspecting if the checkbox is "checked". Further, by adding the auditing of the checkbox, one can also identify who escalated the ticket to Tier 2, and when the escalation took place.

The Status field on the ticket can be used to verify if a ticket has been transferred to Tier 3.

2.2 Interface Requirements

There are no electronic interfaces at this time.

2.3 Report Requirements

2.3.1 Report 1 - The Daily Operations Report The Daily operations report will provide a list of all tickets for the past business day, by

application type in the summary.

The Daily Operations Report will show all tickets handled within 5 minutes and all calls exceeding 5 minutes, sorted by application type and by count.

of 15



For all ticket open times exceeding 7 minutes a list of the ticket numbers will be displayed.

For all tickets in a status of Open for more than 24 hours, and Not of the Category=SAR, those tickets will be listed by application area, by ticket number.

For all tickets marked as type = SAR, and open more than 72 hours, the ticket will be listed by ticket number with the SAR type and sub-application identified.

2.3.2 Report 2 – AQL Report

2.3.3 Report 3 – Monthly Operations Summary The report will show a total of all tickets received, sorted by application area, and then by

source of the contact (e.g. JPAS, by phone, by email, by fax, etc.).

The report will show all tickets sorted by contact type, and then by application area.

The report will show all tickets, sorted by type, and averages for daily call volume by application.

The report will show the total number of Compelling Need (DoD CAF) tickets

The report will show the total number of Personnel Inquiry Write-ups contacts

The report will show a summary of SAR accepted and rejected with list of rejection reasons.

If the ticket type = SAR, exclude from report

If status = tier 3, exclude from the report

Monthly Operations Summary Reporting Requirements

Requirement Data Types Data Structure

The report will show a total of the following:

Tickets Received

Application Area

Source of the Contact

Contacts received, sorted by application area, and then by source of the contact (JPAS, phone, email, fax, etc.)

The report will show the following:

Total Tickets in period

Contact type

Application Area

All contacts sorted by contact type and then by application area.

The report will the show the following:

Sub Applic within each Application area

Source of contact

Daily average of call volume total and by Application Area

The report will show all contacts, sorted by type, and averages for daily call volume by application.

The report will show the following:

of 15



The report will show the total number of General Personnel Inquiry tickets

Total of all General category tickets.

Application Area= Personnel Inquiry

Contact received information for records that meet the Application area= General Personnel Inquiry requirement

The report will show a summary of SAR accepted and rejected with list of rejection reasons sorted by frequency of occurrence

SAR accepted

SAR rejected

List of rejection code counts

All SAR requests filtered by Accepted type and Rejected type. .

2.4 Non-Functional Requirements

Non-Functional requirements include organizational changes, training, or documentation requirements such as user manuals. The non-functional requirements are listed below.

ID Special Requirement Priority Requirement Type Source

NFR1 Resource Training High Training development

InspiriTec

NFR2 Training the trainer High Training development

DMDC

NFR3 Training Materials Development- Create materials necessary to provide training remotely

High Training development

InspiriTec

of 15


dmdc ccc-ticketing system requirements v7b

Technology