2. 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
1.2
2
Business Areas Impacted ........................................................................................ 3
Business Assumptions ............................................................................................ 3
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
Page 2 of 15
DMDC-CCC Business Requirements Document
3. INSPIRITEC CONFIDENTIAL
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.
Page 3 of 15
DMDC-CCC Business Requirements Document
4. INSPIRITEC CONFIDENTIAL
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.
FortKnoxDataCenter
AS6
Responsibility for patching the OS will be with the
FortKnoxDataCenter.
FortKnoxDataCenter
AS7
Responsibility for patching Service Desk will be with HP /
InspiriTec.
Responsibility for patching SQL Server will be with the
FortKnoxDataCenter.
HP/InspiriTec
Availability of Military Base Facilities and Infrastructure will
be the responsibility of Ft.Knox and DMDC government
organizations.
DMDC, Ft. Knox NEC
AS8
AS9
FortKnoxDataCenter
Page 4 of 15
DMDC-CCC Business Requirements Document
5. INSPIRITEC CONFIDENTIAL
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)
2)
3)
4)
5)
6)
7)
8)
9)
10)
11)
12)
13)
14)
15)
16)
Assist users with application execution / installation
Assist with completing user application
Reactivate record within eQIP or JPAS
Troubleshoot/resolve application issues
Review site/application ticket call history (See reporting section)
Clearly document customer issues in trouble ticket
Answer FAQs
Other technical support as needed
Escalate issues as needed via a DMDC application such as Data Request System
(DRS); See escalation procedures
Explain policies and procedures applicable to the personnel security program
Troubleshoot all client call problems within scope of the defined PSA applications.
Update/create troubleshooting documents for common issues to provide to customers.
Provide customers with troubleshooting documents
Contribute towards DMDC Message Board- CCC will provide monthly suggested
updates. This is not an electronic interface.
Monitor email, fax, voicemail, and other customer communication methods.
Provide and update recorded announcementsin 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 Requirements
All Tickets will collect the basic information listed below.
Page 5 of 15
DMDC-CCC Business Requirements Document
6. INSPIRITEC CONFIDENTIAL
2.1.1.1
Contact Profile Information
Field Name
Description
Name
Primary phone number (unique
key)
SMO code
Format
Full Name
Used as primary lookup
Security Management Office
code
CAGE code
Email address
Alt Phone number
User ID
User Key Work
Default
10 digit plus 4 for ext
7
nd
Allow 2 phone
optional
To Be Defined by User(optional)
7
Default
10+4
Default
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 required
d) User’s alternate phone for call back, if other than the primary phone number.
2.1.1.2
Ticket Information
Field
Ticket
Number
Type
Application
Area
Comments
System generated with YY as a prefix
Incident or Request
Default to Incident
List of Values –
JPAS, eQIP, SWFT, DCII, General, SAR
Length
Default field length
and structure
Default
CA-SDM Category
Application
Sub Area
See Table below for values
Source of
Ticket
Need By
Date
Caller
Social
Security
Number
(SSN)
Affected
Phone, Fax, Email, Paper Mail, Web, Other
CA-SDM Sub
Category for each
category
Drop Down List
Customer requested completion date
Default
Use if required - will be displayed only to the rep assigned to the ticket
9 numeric – no dash
or space
Optional field – use if needed
Default name field
Page 6 of 15
DMDC-CCC Business Requirements Document
7. INSPIRITEC CONFIDENTIAL
Field
Subject
Name
Affected
Subject
SSN
Affected
Subject
Date of
Birth
Affected
Subject
Phone #
Affected
Subject
email
Nominating
Official
Name
Priority
Problem
Description
Problem
Summary
Notes
Status
SAR
Resolution
Escalation
Root Cause
Related
Ticket
Number
Ticket
Date, time
indicators
Comments
Length
length
Use if required - display only to the agent who is currently assigned the ticket
9 numeric
Use only if required
MM/DD/YYYY
Use only if required
10+4
Use only if required
Default
Use only if required – optional text field to be used as needed on SAR and other
tickets.
Default for a name
Default 1-5 Values to Be defined
Open field text to describe the problem
Default
Default length
Optional Summary of Problem
Default length
Area to describe ticket activity and changes to the ticket and who made the change
and when
Open, Closed, Tier 3, Under Review and Waiting
Processed And Accept
Accept
or Rejected with reason codes of:
i.
Reject - Obsolete SAR form submitted
ii.
Reject - Incomplete SAR
iii.
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 access
viii. Reject - Applicant already possesses requested access
Change in ticket assignment in terms of the person or group
Table of Values – Hold for future table definition
Optional field - with up to 5 values of ticket numbers
Default values and
length
Default
List of Values
Ticket open – date/time, close date/time ; status change date/time, etc.
Use standard values
of CA-SDM
Default
List of Valid Values
Alphanumeric, 50
characters
Page 7 of 15
DMDC-CCC Business Requirements Document
8. INSPIRITEC CONFIDENTIAL
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 Information
Some 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 Values
The 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.
Page 8 of 15
DMDC-CCC Business Requirements Document
9. INSPIRITEC CONFIDENTIAL
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 SSN
o Any values optionally entered in these fields will be displayed only to the person
to whom the ticket is assigned
o These fields will not appear on any reports
o These fields will not be transferred to Tier 3
o The fields will be visible only to the CSR to whom the ticket is assigned
o 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 flow
o 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-populate
o FSO will describe the inquiry for the affected party
o 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 agent
o Updates to the ticket are made by the Tier 2 agent
o 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
Page 9 of 15
DMDC-CCC Business Requirements Document
10. INSPIRITEC CONFIDENTIAL
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
Page 10 of 15
DMDC-CCC Business Requirements Document
11. INSPIRITEC CONFIDENTIAL
2.1.4
Knowledge Base Requirements
1) 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 Summary
This 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 alarge document of 100+ pages.
2.1.5
Escalation Procedure Requirements
While 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 Requirements
The 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
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.
Page 11 of 15
DMDC-CCC Business Requirements Document
12. INSPIRITEC CONFIDENTIAL
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 Requirements
o
o
o
o
o
o
2.1.6
2.1.6.1
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.
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.
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.
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.
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.
All issues statuses will be logged in the Tier 2 Support Tracking Log.
Tracking and Monitoring
Tracking Access Types
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:
Page 12 of 15
DMDC-CCC Business Requirements Document
13. INSPIRITEC CONFIDENTIAL
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 Level
In 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
2.3.1
Report Requirements
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.
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.
Page 13 of 15
DMDC-CCC Business Requirements Document
14. INSPIRITEC CONFIDENTIAL
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
The report will show a total of
the following:
Data Types
Tickets Received
Application Area
Source of the Contact
The report
following:
will
show
the
Total Tickets in period
Contact type
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 the
following:
The report will show the total
number of General Personnel
Inquiry tickets
The report will show a
summary of SAR accepted
and rejected with list of
rejection reasons sorted by
Total of all General
category tickets.
ApplicationArea=
Personnel Inquiry
SAR accepted
SAR rejected
List of rejectioncode
Data Structure
Contacts received, sorted by
application area, and then by
source of the contact (JPAS,
phone,email, fax, etc.)
All contacts sorted by contact
type and then by application
area.
The report will show all
contacts, sorted by type, and
averages for daily call volume
by application.
Contact received information
for records that meet the
Application area= General
Personnel Inquiry requirement
All SAR requests filtered by
Accepted type and Rejected
type. .
Page 14 of 15
DMDC-CCC Business Requirements Document
15. INSPIRITEC CONFIDENTIAL
frequency of occurrence
counts
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
Page 15 of 15
DMDC-CCC Business Requirements Document
