POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
Document Title: ICL Pathway Customer Service: Service Management
Operations Manual
Document Type: Operations Manual
Abstract: Details of the Customer Services processes and procedures
performed to provide the Pathway solution
Status: Working draft
Distribution: CS department
Library
Author: John Russell
Comments to: John Russell
Comments by: 1198
© 1998 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE Page 1 of 104
ICL Pathway ICL Pathway Customer Service: Customer Ref:
Service Operations Manual version:
POL00393875
POL00393875
CS/MAN/004
0.2
29/06/98
0 Document control
0.1 Document history
Version Date
0.1 1/5/98
0.2 1/7/98
Reason
Working draft
New material incorporated suggested by P Burden.
0.2 Approval authorities
Name
S. Muchow
Position Signature
Director Customer Services
0.3 Associated documents
Reference
CS/PRD/0010
CS/PRD/0011
CS/PRD/0013
CS/PRD/0014
CS/PRD/0015
CS/PRO/0033
CS/PRO/0047
CS/PRO/0048
Vers
0.3
0.1
0.1
0.1
0.1
0.1
0.2
0.1
0.1
Title
Horizon Service Review Forum
Horizon User Satisfaction Surveys
Service Visit Record Process
BPS Card and PUN Production and
Distribution Process
BPS Temporary Token Production and
Distribution Process
BPS Card Receipt and Issue at Post
Office
Management Care Visits
Payment Card Helpline Processes and
Procedures
Horizon System Helpdesk Processes and
Procedures
Date
Source
PDA
ICL Pathway
ICL Pathway
ICL Pathway
ICL Pathway
ICL Pathway
ICL Pathway
ICL Pathway
ICL Pathway
COMMERCIAL IN CONFIDENCE
Page 2 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
0.4 Abbreviations
APS
BA
BIA
BPS
CAP.
CMS
Benefits Agency
Customer Accounting and Payment Strategy
Card Management Service
Customer Service
De La Rue Card Systems
Department of Social Security
Extended Verification Procedure
Financial Accounting Division (of the Post Office)
Horizon System Helpdesk
International Computers Limited
Identity
Information Technology
Information Technology Services Agency
Management Care Visit Process
One Shot Password
Payment Authorisation Service
Payment Card Helpline
Post Office
Post Office Counters Limited
Pick Up Notice
Service Visit Record
COMMERCIAL IN CONFIDENCE
Page 3 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
0.5 Changes in this version
Addition of new information.
COMMERCIAL IN CONFIDENCE Page 4 of 104
ICL Pathway
POL00393875
POL00393875
ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
0.6 Table of content
41
4.2
4.3
5 Customer Management.
5.1
Areas of responsibility.
Principles..
Objectives.
Horizon Service Review Forum
5.1.1 Horizon Service Review Forum
5.1.2 Context of Meetings.........
5.1.3 Frequency of Meetings.
5.1.4 Attendees.
5.1.5 Current Constitutions
5.1.6 Relationship between the Horizon Service Review Forum and Contract
Management Groups... 15
5.1.7 Preliminary Activities. 15
6 Customer Satisfaction 17
6.1 Service Visit Records (SVR) cards................. 17
6.1.1 SVR Production......... 17
6.1.2 SVR Distribution 17
6.2
6.3
6.1.3 SVR Analysis. 17
6.1.4 Review Meetings. 19
6.1.5 Back-up Of Historical Dat: 19
6.1.6 Charitable Donations... 19
21
Satisfaction Surveys.
6.2.1 Initial Preparation............. 21
6.2.2 The Project Plan. 21
6.2.3 Focus Events. 21
6.2.4 Telephone Surveys. 21
6.2.5 Areas Covered By Surveys.
22
6.2.6 Survey Results.... 22
Management Care Visits. . 23
6.3.1 Purpose...
6.3.2 Training.
6.3.3 Preparations And Documentation...............0:cceee
COMMERCIAL IN CONFIDENCE Page 5 of 104
ICL Pathway
POL00393875
POL00393875
ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
7 System Service.
7.1
8 Horizon System Helpdestk...........
8.1
8.2
9 Payment Card Helpline.
9.1
9.2
9.3
6.3.4 Arranging Appointments
6.3.5 The Interview.
6.3.6 Follow Up Letters.
6.3.7 Feedback Reports..............
6.3.8 Analysis.
6.3.9 Interviewer’s Summary Guide
Service Logistics Review.
Overview..... a
Horizon System Helpdesk information
8.2.1 Horizon System Helpdesk telephone numbers.
8.2.2 Horizon System Helpdesk service hours...
8.2.3 Contacting the Horizon System Helpdesk.
8.2.4 PO outlet incidents...
8.2.5 Regional Helpdesk incidents.
8.2.6 Security incidents.
8.2.7 Planned changes
8.2.8 POCL client interface incidents.
8.2.9 Reconciliation incidents.
8.2.10 Pathway remote and central system incident:
8.2.11 Pathway implementation incidents.
Overview...
Payment Card Helpline information
9.2.1 Payment Card Helpline telephone numbers
9.2.2 Payment Card Helpline service hours.
9.2.3 Contacting the Payment Card Helpline.
9.2.4 Call escalation.
9.2.5 Contingency.
9.2.6 Call redirecting.
9.2.7 Call recording.
9.2.8 Call logging.
9.2.9 Payment Card Helpline helpdesk to caller verification procedure....... 44
9.2.10 Caller identification
PO counter staff calls..
9.3.1 Card/batch calls (PCDF)
9.3.2 System failure: CMS calls (PCDF).
COMMERCIAL IN CONFIDENCE Page 6 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
9.3.3 System failure: Encashment calls..............
9.3.4 System failure: Payment calls.
9.3.5 Complaint calls.......
9.3.6 Rollout-only calls.
9.3.7 Encashment anomaly calls.
9.3.8 System failure: OBCS calls..........
9.3.9 PO counter staff calls on behalf of customers in exceptional
circumstances. wee
9.3.10 PO counter staff inappropriate calls
9.4 DSS staff calls.
9.4.1 Payment calls.........
9.4.2 Card/PUN calls.
9.4.3 Temporary token calls.
9.4.4 Complaint calls...
9.4.5 Rollout-only calls.
9.4.6 DSS office calls on behalf of customers in exceptional circumstances
52
9.4.7 DSS staff inappropriate calls.
9.5 DSS customer calls.
9.5.1 Card/PUN status call
9.5.2 PUN receipt calls...
9.5.3 Card collection calls.
9.5.4 Lost/stolen/damaged PUN calls.
9.5.5 Lost/stolen/damaged card calls.
9.5.6 Lost/stolen/damaged temporary token calls........
9.5.7 Card change calls
9.5.8 Complaint calls.
9.5.9 Payment error calls.
9.5.10 Rollout only calls. sesereeeeeeeeeeeeee seseseseaeecieateeeeeeee serene 58
9.5.11 DSS customer inappropriate calls
9.6 Third party calls. we
9.6.1 Third party valid calls.
9.6.2 Third party inappropriate calls
9.7 Horizon System Helpdesk calls
10 System Management Centre.......
10.1 Roles And Responsibilities.
10.1.1 SMC Service Manager.
10.1.2 SMC Technical Consultant (Tivoli).
COMMERCIAL IN CONFIDENCE Page 7 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
10.1.3 SMC Manager.
10.1.4 SMC Team Leader.....
10.1.5 SMC Technical Specialist.....
10.1.6 SMC Technician
10.2 Review Mechanisms - Internal
10.2.1 Meetings.
10.2.2 SMC Meeting.
10.2.3 Other Meetings...
10.2.4 Example Meeting Minutes.
10.2.5 Reports.......
10.2.6 SMC Support Handover Log
10.2.7 SMC Handover Log
10.2.8 SMC Statistics Report...
10.2.9 SMC Management Report.
10.2.10 SMC Summary Progress Report.
10.2.11 SMC Individual Progress Report.
10.3 Customer Acceptance Criteria
10.4 Customer Complaints.
10.5 Recognition.
10.6 Skills...
10.7 Skills Grade Criteria
10.8 Contingency, Security And Risk.
10.8.1 Contingency Plans.
10.8.2 Security And Risk Analysis Plans.
10.9 Escalation
10.10 Training Plan
10.11 Audit Reports And Corrective Actions
10.12 Staff Appraisals...
10.12.1 SMC Manager's Responsibilities.
10.13 Documentation.
10.13.1 Key Documents.
10.13.2 ICL CFM Pathway Services Division Operations Manual................ 75
10.13.3 SMC Binder Library.........
11 Card and PUN production.
12 Rollout: Cards/PUNS and Temporary Tokens.
13 POCL Card Receipt Service..
14 Operational Business Chang:
14.1 Operational Business Change - Outlets.
COMMERCIAL IN CONFIDENCE Page 8 of 104
ICL Pathway
POL00393875
POL00393875
ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
14.2 Operational Business Change - Product.
14.1.1 Change types.
14.1.2 Card & payment management....
14.1.3 Top Level Processes - Outlet.
14.1.4 Change Advice Note (CAN) details.
14.1.5 Release 1c.
14.1.6 Second Level Processes - Outlet..
14.2.1 Change Types.....
14.2.2 Top Level Processes - Product.
14.2.3 Change Advise Note (CAN) Details.
14.2.4 Second Level Processes- Product
COMMERCIAL IN CONFIDENCE Page 9 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
Introduction
The objective of this manual is to provide details of the operations performed by ICL
Pathway Customer Service - Customer Service in support of the Customer.
2 Scope
Operations described in this manual apply only to the Customer Service area of CS,
as follows:
e¢ Customer management
* Customer satisfaction
e System service
« Horizon System Helpdesk (HSH)
« Payment Card Helpline
« System Management Centre (SMC)
e Card/PUN production
* Rollout: Cards/PUNs and temporary tokens
« POCL card receipt service
COMMERCIAL IN CONFIDENCE Page 10 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
Mission and vision
<information needed>
COMMERCIAL IN CONFIDENCE Page 11 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
Overview
4.1 Areas of responsibility
4.2
4.3
The areas of responsibility of the Customer Service Unit are:
« Customer management
* Customer satisfaction
e System service
« Horizon System Helpdesk
« Payment Card Helpline
« System Management Centre
¢ Card/PUN production
¢ Rollout: Cards/PUNs and temporary tokens
« POCL card receipt service
Principles
The principles by which the Customer Service Unit works are:
« <information needed>
Objectives
The objectives of the Customer Service Unit are:
« <information needed>
COMMERCIAL IN CONFIDENCE
Page 12 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
Customer Management
5.1 Horizon Service Review Forum
This section outlines the agreed terms of reference for the Horizon Service Review
Forum.
The nature, extent and associated performance of the services provided by ICL
Pathway are specified in the Related Agreements. These contracts must always be
used as the definitive source of information and interpretation of the contracted
service.
At a lower level, the DSS, POCL and ICL Pathway have jointly developed a Service
Management Framework to support working level co-operation and day to day
control of the live service environment. The framework establishes a structure of
core functions and control mechanisms to underpin the effective management of an
end to end service.
The Horizon Service Review Forum is a key element of the overall Service
Management Framework.
5.1.1 Horizon Service Review Forum
The Horizon Service Review Forum provides a regular opportunity for senior
managers from the DSS, POCL and ICL Pathway to meet, review and discuss the
overall performance of ICL Pathways systems and services in the live environment.
The forum is a tripartite event to provide focus upon the mutual interests of the
DSS, POCL and ICL Pathway. However, from time to time there may be separate
review meetings between the DSS or POCL and ICL Pathway to review and discuss
matters of exclusive interest, for example, AP and EPOSS services.
The Horizon Service Review Forum is concerned with maintaining satisfactory levels
of service at an operational and practical level. Separate forums exist to consider,
decide upon and escalate matters of a contractual/commercial nature, that is, the
Contract Administration Groups and Contracts Steering Group. If any contractual or
commercial issues do arise at the Horizon Service Review Forum, the details are
noted and referred on to the appropriate forum for consideration, discussion and
determination.
5.1.2 Context of Meetings
The Horizon Service Review Forum addresses all facets of the ICL Pathway
contracted services, primarily focusing upon
1. Review of Performance Reports and relevant Management Information Statistics
(MIS).
1. Quantitative and qualitative assessment of the services.
1. Review of major incidents and/or significant outstanding problems.
1. Matters escalated from the DSS or POCL internal Service Review processes.
1. Review of impending changes or enhancements to the live service environment.
1. Development and monitoring of service improvement initiatives.
1. Implementation Requirements (non Roll-Out)
A typical agenda for the Horizon Service Review Forum appears in the DSS Agreement
Schedules D5 & E5 and POCL Agreement Schedules D5, E5, F5, G7, HS
COMMERCIAL IN CONFIDENCE Page 13 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
5.1.3. Frequency of Meetings
5.1.3.1 Each Month
It is recognised that the Related Agreements formally provide for quarterly Service
Review meetings. However, for the time being it is anticipated that the Horizon
Service Review Forum will meet on a monthly basis. This reflects the early and
evolving state of the live environment. The monthly meeting will normally be within
10 working days of ICL Pathway publishing their Performance Reports and MIS
data. Other meetings may be arranged on an ad-hoc basis.
5.1.3.2 Every Third Month
Prior to each third monthly meeting, ICL Pathway will also provide information about
the level of any remedies applicable during the preceding service period. The
circumstances which have given rise to the performance deficiencies will be
considered at the Horizon Service Review Forum and output in the form of a report
to the Contract Administration Group(s).
5.1.4 Attendees
5.1.4.1 DSS and POCL
Both the DSS and POCL have each appointed/empowered a Business Manager
and Liaison Manager to undertake Service Management functions. The respective
roles and responsibilities of these individuals are detailed in the DSS Agreement
Schedules D5 & E5 and POCL Agreement Schedules D5, E5, F5, G7, H5. The
Business Manager(s) will attend the Horizon Service Review Forum and may be
accompanied by other DSS/POCL personnel as necessary.
5.1.4.2 ICL Pathway
ICL Pathway will appoint/empower an Operational Service Manager, Service
Manager and Service Help Desk Manager to undertake Service Management
functions The respective roles and responsibilities of these individuals are detailed
in the DSS Agreement Schedules D5 & E5 and POCL Agreement Schedules D5,
E5, F5, G7, H5. The Operational Service Manager will attend the Horizon Service
Review Forum and may be accompanied by other ICL Pathway personnel as
necessary.
5.1.5 Current Constitutions
The present constitution of the Horizon Service Review Forum is as shown in the
block diagram that follows.
COMMERCIAL IN CONFIDENCE Page 14 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
5.1.6
HORIZON SERVICE REVIEW FORUM
Operaional BuslnessIManager Business Manager
Service Manager POCL Si!
(Chairman)
Steve Muchow Graham Beck Paul Hanson
PRESCRIBED -
ATTENDEES Secretariat
POTENTIAL
ATTENDEES __I Service Manager Liaison Manager
' POCL
I Liaison Manager
Dss
Peter Burden
Dave MeLaughlin Facki Paterson
I Incident
I Manager I
Others
Others j
Phil
"Lewis
Relationship between the Horizon Service Review Forum and Contract
Management Groups
The Horizon Service Review Forum supports and informs the Contract Management
function. The forum has no authority to take decisions of a contractual or
commercial nature. The associated Contract Management function is outlined in
Schedules A4 to the Authorities Agreement, DSS Agreement and POCL
Agreement.
The Horizon Service Review Forum provides reports to the Contract Administration
and Contracts Steering Groups for contract monitoring purposes and the
consideration or determination of any contractual issues. In particular, the Contract
Administration Groups considers the overall performance of ICL Pathway services
for the purpose of invoice authorisation and the application of remedies where
appropriate.
Preliminary Activities
Following receipt of the ICL Pathway monthly Performance and MIS reporting pack
both the DSS and POCL conduct their own internal Service Review meetings.
Separate terms of reference exist within each organisation for these forums. In
general, the meetings provide an opportunity for representatives from a variety of
business units and working groups in the DSS and POCL to:
1. Review the ICL Pathway performance and MIS reports
1. Discuss the prioritisation, progress and resolution of outstanding problems
1. Facilitate operational feedback about the contracted services
1. Review Service Management processes and procedures
1. Identify improvement opportunities
COMMERCIAL IN CONFIDENCE Page 15 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
The internal Service Review meetings are normally chaired by the respective
Liaison Managers and the ICL Pathway Service Manager is usually invited to attend.
Counterparts from the other organisations Service Management team may also be
invited on a regular or ad hoc basis. The full Horizon Service Review Forum
provides a primary route for the escalation of matteres that cannot be resolved at
the DSS and POCL internal Service Review meetings
Following the internal Service Review meetings the DSS and POCL Business
Managers are briefed by their respective Liaison Managers. Subsequently, the two
Business Managers will meet in advance of the full Horizon Service Review Forum
to highlight and discuss matters of mutual interest or concern.
The target timeframe for preliminary activities leading up to the Horizon Service
Review Forum is shown in the following diagram.
A = Submission of Performance & MIS Reports by ICL Pathway
B = Analysis of Performance & MIS Reports
C = DSS and POCL internal Service Review meetings
D = DSS and POCL Business Managers meet
E = Horizon Service Review Forum
0 4 9 10 Working Days
COMMERCIAL IN CONFIDENCE Page 16 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
6.1
6.1.2
6.1.2.1
Customer Satisfaction
The customer satisfaction functions of Customer Support are concerned with the
following:
« Service Visit Record (SVR) cards
e Satisfaction surveys, and
« Management care visits
Service Visit Records (SVR) cards
This section defines the procedure by which Service Visit Records (SVRs) are
distributed to Horizon users, that is, Postmasters or Sub-Postmasters. The
feedback card allows the Postmaster to comment briefly on the quality of the service
provided by an engineer during his visit, including any related contact through the
Horizon System Helpdesk (HSH). The card is then received, analysed and action is
then taken by ICL Pathway according to the content of the card.
SVR Production
ICL Pathway are responsible for the initial design and production of the SVR, plus
any subsequent updates or amendments. A sample SVR is given at the end of this
section.
The feedback section of the SVR is reply-paid. The Royal Mail invoice Pathway for
the cost of the reply-paid service.
SVR Distribution
Within ICL
ICL Pathway arrange for batches of SVRs to be printed and then provide them to
the SORBUS SVR Co-ordinator for distribution to their engineers.
ICL Pathway process new orders for batches of SVRs on request by the SORBUS
SVR Co-ordinator.
6.1.2.2 Within Post Offices
Each time a SORBUS engineer visits a Post Office, he completes the front sheet of
the SVR and obtain a signature from the Postmaster verifying irs content. The
engineer then retains the top copy, leaving a copy of the SVR and attached
Feedback Card with the Postmaster. The Postmaster should keep the SVR copy for
his records and then complete the feedback card and return it to ICL Pathway.
SORBUS and CFM have a similar internal procedure for handling the SVRs that
complements the ICL Pathway procedure described here (see document Reference
ICLS/PATHWAYUKSS).
SVR Analysis
The Feedback Card asks seven brief questions about the service provided by
SORBUS or CFM. Against each question the Postmaster need only tick a box for
Yes, No or, where relevant, N/A. There is also space for brief comments. Each card
has a unique serial number.
When returned to ICL, the card is received in the central mail room of the ICL
Pathway office in Feltham (FEL 01). Itis then delivered to the Customer Service
COMMERCIAL IN CONFIDENCE Page 17 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
department and passed to the Customer Satisfaction Manager for entry into a
database, which is updated daily.
The database holds all the information from the feedback cards, as follows:
Unique serial number
Date Call No.
Contact Name Position
Post Office FAD Code
Postcode Tel No
Service Provided by Service Unit
Arrival Completion
Yes, No or N/A response against each of the seven questions
Free text comments or suggestions
The free text comments may relate to SORBUS engineers or the HSH.
There is a field in the database for SORBUS or HSH responses, for actions taken
by them, plus a date column for when the response was received from them.
A field entitled Action Required is also available to help the ICL Pathway Customer
Satisfaction Manager note any additional actions required.
6.1.3.1 Individual Card Analysis
Immediately after entering the data from each feedback card into the database,
those which show one or more No responses to any of the questions, or have
negative comments/ suggestions, are electronically extracted and converted to a
Word document as a single SVR. These are sent to the SORBUS SVR Co-
ordinator, or the CFM Horizon System Helpdesk Manager, according to who the
particular issue relates.
SORBUS or CFM then investigate the issue and takes appropriate corrective action,
in accordance with their own internal procedure. This includes contacting the
Postmaster directly to obtain further details. Once resolved, SORBUS or CFM
should contact the Postmaster to confirm resolution of the issue.
Details of the cause of the issue and the action taken are entered on the electronic
SVR, and noted as complete. The completed SVR is then returned electronically to
ICL Pathway Customer Satisfaction by the SORBUS SVR Co-ordinator, or the CFM
Horizon System Helpdesk Manager, within 10 working days of receipt. For issues of
a more serious nature, best endeavours must be made to return the completed
electronic SVR within five working days.
The ICL Pathway Customer Satisfaction Manager then updates the database with
details of the returned, completed SVRs.
The ICL Pathway Customer Satisfaction Manager must contact either the SORBUS
SVR Co-ordinator or the CFM Horizon System Helpdesk Manager, immediately, if
an SVR is not completed within 10 working days, to establish the reason for the
delay and to agree a satisfactory method of resolution.
6.1.3.2 Top Level Analysis
Routine, monthly analysis is performed giving basic statistics, as follows:
1. Percentage of feedback cards returned compared with total visits made. A
figure for the total number of visits made in the month is obtained from SORBUS
COMMERCIAL IN CONFIDENCE Page 18 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
and entered onto the spreadsheet.
1. Percentage of positive and negative responses by question.
1. Comments on key areas of satisfaction, or dissatisfaction.
The SORBUS SVR Co-ordinator and the CFM Helpdesk Manager receive a copy of
the report every month.
Review Meetings
Review meetingsare held monthly between the ICL Pathway Customer Satisfaction
Manager, SORBUS SVR Co-ordinator and CFM Helpdesk Manager.
These meetings are part of a general ‘satisfaction’ review, but specific to the SVR
procedure. They ensure that correct procedures are adhered to, that statistics are
analysed, that all necessary actions have been taken, that outstanding issues have
been dealt with, or that a plan of action is agreed.
Back-up Of Historical Data
Hard copies of the Feedback Cards are filed in numerical order by ICL Pathway and
held for a period of six months before they are destroyed.
The electronic data (database) is held on hard disk and backed-up onto diskette.
The data is held for three years before being destroyed.
Charitable Donations
ICL Pathway make a donation to charity for every feedback card returned. The
amount and charity chosen by ICL Pathway may change from time to time.
COMMERCIAL IN CONFIDENCE Page 19 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
1. Top Sheet 2. Bottom Sheet
Service Visit Record Feedback Card
Date Call No. Date Call No.
Contact Name Position Contact Name Position
Post Office FAD Code Post Office FAD Code
Postcode Tel No Postcode Tel No
Service Provided by Service Unit Service Provided by Service Unit
Arrival Completion Arrival Completion
Service required /fault details Tam committed to providing you with the best service possible
but to do this I need your help. Please take the time to
complete this form and in recognition of your reply we will
make a donation to charity.
Stephen Muchow
Action taken Director - Horizon Customer Service
YES NO NIA
Overall were you satisfied with
the service provided in response
to your call?
v
When you placed your call was__
Equipment detail adequate help provided?
Ea
Were you given an expected
time of arrival for the
Representative?
.
Was the estimated time of
arrival achieved?
5. Were you kept informed of the
progress of your service call?
Type/Bar/Serial (old) 6. Was the service provided ina
‘Type/Bar/Serial (new) courteous and efficient manner?
7. Did the service avoid disrupting
your business?
Comments or suggestions (especially where you have
Signature answered No).
(for and on behalf of the customer) t'}
0
Name. 1
(in block capitats please)
TOP COPY - ENGINEER TOP COPY - ENGINEER
MIDDLE COPY - CUSTOMER MIDDLE COPY - CUSTOMER
Horizon Customer Service sorromcory-ic.copy I Horizon Customer Service _ sortomcory-ici cory
COMMERCIAL IN CONFIDENCE Page 20 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
6.2
6.2.1
6.2.2
6.2.3
6.2.4
6.2.5
Satisfaction Surveys
This section defines the Procedure by which Post Office Counters Limited (POCL)
Research Department prepare for and carry out User Satisfaction Surveys during
the implementation of releases 1b and 1c of the Horizon system. This section also
explains how the survey results are documented and reported back to ICL Pathway
for action, as appropriate.
Initial Preparation
The basic actions consist of preparing a project plan for all activities, including dates
for each task. Also, performing initial Focus events, targeting a small cross section
of Users to help compile questionnaires for broader telephone surveys.
POCL Research Services and ICL Pathway meet whenever required during the
course of the project to communicate progress or resolve issues. No set dates are
established, and the meetings occur as and when necessary. However, results
from the Focus Events are presented at the Satisfaction Forum.
The Project Plan
A colour coded plan is produced and maintained by POCL Research Services. It
indicates when Go Ahead for the activity is to be approved by the PDA, when the
fieldwork is to be expedited and when the results are due.
The above details apply to each release stage of 1b and 1c of the Horizon
implementation.
Focus Events
A Focus event is a meeting chaired by POCL Research Services. It is attended by
asmall number of Postmasters, picked by POCL Research Services, who are at an
appropriate stage in the implementation of Horizon. There are normally eight
Postmasters at each event. Four Focus events are held in quick succession in
towns located within the chosen geographical implementation areas, for example,
Bristol and Newcastle.
With input from ICL Pathway a discussion document is assembled by POCL
Research Services which is used as an informal script to help ensure all relevant
topics are covered during the event. However, the events are designed to allow the
Postmasters to air their views on any aspect of the implementation or services of
Horizon if they feel it is relevant. It is the Chairman’s responsibility to ensure that all
the topics are covered and the meeting keeps to the agenda.
The results of the Focus events will be used to develop a more specific
questionnaire which will form a telephone survey of a further 100 Post Office sites.
Telephone Surveys
Using the data gathered during the Focus events, a telephone questionnaire was
generated by POCL Research Services. This questionnaire is much more formal,
and is performed by an independent, outside agency. The telephone surveys are
timed to be carried out once the planned 190 sites for Release 1b have been
implemented. The whole procedure, from Focus event to telephone survey, is
started from scratch for Release 1c.
Areas Covered By Surveys
The initial Focus events are designed to be informal, but the event should address
the following areas:
COMMERCIAL IN CONFIDENCE Page 21 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
6.2.6
6.3
Communication
User Awareness Event
Training
Survey
Installation and Modifications
Follow up Visits
General: Helpdesks/Documentation/Using the System
These topics will again be used to compile the more scripted telephone surveys.
Survey Results
The results of the Focus events, may themselves indicate problem areas that
require immediate and specific corrective action, or areas where customer
satisfaction has been particularly positive.
The results of the telephone surveys give a more comprehensive and specific
analysis of a much larger cross section of Horizon users. Again these results
enable ICL Pathway to pinpoint specific areas of concern or satisfaction and take
relevant action.
The ICL Pathway Customer Satisfaction Manager receive the reports of both the
Focus event and telephone surveys, and instigate and co-ordinate any required
actions.
The Horizon users are contacted with regard to the general results of the surveys
and the sort of actions that will be taken, when appropriate.
The appropriate methods of communication with users, suppliers and internally, will
be considered on receipt of the survey results.
COMMERCIAL IN CONFIDENCE Page 22 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
6.3.1
6.3.2
6.3.3
Management Care Visits
In order to monitor the user’s perception of ICL Pathway’s Post Implementation
Customer Service, Customer Service manage the Management Care Visit
Programme (MCVP). The MCVP involves senior ICL Pathway representatives
visiting selected post offices and collecting feedback using a predefined interview
pack.
Purpose
The purpose of the MCVP is to monitor the user’s perception of ICL Pathway’s Post
Implementation Customer Service. The interviews allow ICL Pathway to gain an
understanding of the user’s (Postmasters) problems, concerns, suggestions and
good news. Where and when relevant ICL Pathway can act upon this information
as an aid to resolving problems, taking pre-emptive action and learning from good
news and positive feedback.
This programme is non-contractual, and is managed within the Customer Service
department of ICL Pathway.
The MCVP is performed annually, with visits around 500 Post Offices per year after
full roll out of the programme (1999 onwards). Until that time a small number of
Post Offices will be visited in Q4 of 1997 and around 200 in 1998. Cumulative
analysis is carried out internally on a monthly basis, and results published quarterly.
A number of relevant senior ICL Pathway representatives have been selected to
carry out the interviews, hereafter known as the interviewers.
Training
The Customer Satisfaction Manager presents the details of the procedure to the
interviewers before they have contact with any Post Offices regarding the
interviews.
The purpose and the goals of the MCVP are presented. The interview procedure
and questionnaire are explained in detail and the interview process is established.
All other relevant documentation is presented, and any questions or concerns raised
by the interviewers are addressed.
Section 9 of this document is the Interviewer’s Summary Guide, which is designed
to be copied and used as a reference guide during the interviews.
It is important for the interviewers to understand why each interview must follow a
standard procedure, to ensure all results can be fairly compared and a true analysis
obtained.
Preparations And Documentation
The interviewers are sent electronic copies of relevant documentation, plus hard
copy ‘Interview Packs’ containing all relevant reference documentation, which
should be maintained by the interviewers,. These packs must be taken to the
interviews.
The Interview Packs contain the Procedure document (including Interviewer’s
Summary Guide), Phone Script, sample forms and documents (referred to in the
questionnaire), the Questionnaire and the list of Post Offices to be contacted.
Before contacting the Post Offices, the interviewers must familiarise themselves with
recent Horizon System Helpdesk call history. The call history should be assessed to
check that there is no reason why the Post Offices should not be contacted now to
arrange a visit. The decision not to visit a particular post office will be made by the
COMMERCIAL IN CONFIDENCE Page 23 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
6.3.4
6.3.5
Customer Satisfaction Manager (or nominated representative).
Arranging Appointments
Once the list of Post Offices has been received by each interviewer, he or she can
start to arrange the visits, after first requesting and having the Horizon System call
history checked by the Customer Satisfaction Manager.
Details of the Post Offices, FAD Code, Address, Phone Number and Contact Name
are supplied to the interviewers. Each list is personalised for each interviewer, only
containing the Post Offices to be visited by that interviewer.
The interviewers should first familiarise themselves with the Phone Script (Ref:
MCVP 97/script.doc) and then telephone the Post Offices, using the script, to
arrange the appointments.
As each visit is arranged details of the Post Office and appointment must be sent to
the Customer Satisfaction Manager for entry onto an Appointments Database.
The interviewers must ensure the Post Offices have a contact number and the
interviewer's name so that they can contact the interviewer should a problem arise
with the arranged appointment. If an interviewer is, in general, difficult to contact
they should leave the contact number for the Customer Satisfaction Manager as an
alternative.
The interviews should always be arranged at a time to suit the Post Office. This
may involve a lunch time, or in some cases an evening meeting. The interviewers
should also stress that the interviews need take no more than half an hour, but that
there is no time limit applied.
If the interviews are arranged significantly in advance (more than 10 days) the
interviewer should contact the Post Office nearer the visit (no more than 2 days
before) to confirm it can still go ahead.
It is up to the interviewers to obtain directions to the Post Offices.
The Interview
Before going to the Post Offices the interviewers must familiarise themselves with
the questionnaire.
The questionnaire has eleven sections. Before commencing with Section 1
onwards the interviewers should explain a little more about the purpose and
objectives of the visit, as stated in the notes on the front sheet of the questionnaire.
Section 1
This section can be pre-filled, where possible, before the interview, to save time.
However, all information must be checked with the interviewees before moving on to
the next section.
Section 2
The interviewers should gain a very brief understanding of how the implementation
of the Post Office went in general. This will not form part of the statistics, but it will
help ICL Pathway understand if any implementation experiences have influenced
the subsequent views of the interviewees, either positively or negatively.
Sections 3 to 10
All the answers to the questions in these sections are analysed. There is an ‘N/A’
(Not Applicable) option for each question, but it should be avoided if at all possible.
When asking each question the interviewers should read out the positive and
COMMERCIAL IN CONFIDENCE Page 24 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
6.3.6
negative answer options, and only then offer ‘N/A’ if it appears unavoidable.
Where ‘N/A’s are recorded the number of Post Offices that can be analysed against
that question is reduced, thus giving a smaller sample of Post Offices’ views.
The interviewers must mark the boxes appropriate to the answers given. The
interviewers must not suggest answers or influence answers in any way, other than
to try to avoid ‘N/A’ answers where possible. The interviewer must ensure the
interviewees understand the questions fully before they answer.
There is an opportunity for the interviewees to comment further on the response
given to each question. The interviewers should ask if there are any comments
after each question is answered.
It is especially important to get comments when the questions have a negative
answer. This helps ICL Pathway to understand the reasons behind the negative
comments, and thus enables them to take any possible corrective action, either
generically or for a single Post Office, if relevant.
Section 11
This section gives the interviewees a chance to express any concerns, problems or
suggestions for improvement to the Horizon system or services. The interviewers
should also encourage any positive comments or experiences the interviewees can
share. This helps to keep this section balanced.
At this point the interviewers should try to engage general conversation in order to
get opinions free flowing and less ‘closed’ than those given during the
questionnaire, but remembering to keep the conversation relevant to the purpose of
the interviews, that is, about the service provided after implementation.
Questions such as:
‘What else would you want ICL Pathway to do to improve services?
What sort of things do we do well and what sort of things do we need to improve
on?’
If the interviewees ask any questions, the interviewers should note them down and
explain that they are not in a position to answer any specific questions as part of the
interview process. If required an ICL Pathway representative could contact the
interviewees at a later time to respond to any specific questions. These questions
should be noted down in Section 11 or in the additional notes area.
At the end of Section 11 the interviewers must ask whether the interviewees are
willing to be contacted again, if necessary, after the interview results are analysed.
The interviewers must delete either the ‘willing’ or ‘unwilling’ part of the statement
accordingly.
The interviews can then be terminated. The interviewers should remember to thank
the interviewees for their time and co-operation, and then leave the premises.
Follow Up Letters
As soon after the visit as possible the interviewers should write to the interviewees
confirming the main points of the interview, to ensure there is no future controversy
or misunderstanding about the information provided by the interviewees.
The first and last paragraphs of the letter are supplied as a standard. The middle
section of the letter is a summary of the interview, as compiled by the interviewers.
This does not need to include details about sections 3 to 10 of the questionnaire,
but should cover the information provided for sections 1, 11 and any additional
notes made.
COMMERCIAL IN CONFIDENCE Page 25 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
6.3.7
6.3.8
6.3.9
Feedback Reports
The completed questionnaires and reports must be treated as confidential within ICL
Pathway. They must be kept securely until they can be passed on to the Customer
Satisfaction Manager, as quickly as possible.
The results of the questionnaires are entered on to an analysis spreadsheet (see
document reference MCVP 97/analysis97.xls). The FAD code is used as the unique
reference for each completed questionnaire. The hard copies are filed securely in
numerical order by FAD code. Any questions, concerns or required actions logged
are recorded against the FAD code.
Analysis
Pre-designed graphs reflect Positive, Very Positive, Negative, Very Negative results
for each section, from 3 to 10.
A report is produced monthly showing graphs with the cumulative results to date and
a brief summary on each section's results. Relevant information from Section 11,
and any additional notes, is also summarised. This report is for limited distribution
within ICL Pathway.
A quarterly report is produced, similar to the monthly reports, which reflects the
cumulative, quarterly results. There will also be further recommendations for action
on feedback of note.
Results are formally published internally each quarter. The most appropriate
method of publication is decided at the relevant time.
The quarterly report is presented to the PDA, via the Satisfaction Forum.
General publication to all Post Offices is expected to be a brief write-up, using the
most appropriate method of publication, which is decided at the relevant time.
Concerns, suggestions or comments which require further action are recorded
separately on the spreadsheet as a log for action. The FAD code, name of the
Post Office, and details of the comments are noted, and any actions taken can be
recorded. The record is kept open until a satisfactory conclusion is reached. The
action can then be marked as closed. The Customer Satisfaction Manager
maintains and manages the log.
The Post Offices is only contacted to follow up any feedback if they agreed at the
interview to further contact and then, only when considered necessary by ICL
Pathway.
COMMERCIAL IN CONFIDENCE Page 26 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
Interviewer’s Summary Guide
Preparation
If there are any outstanding questions or concerns regarding the visits or the
procedure, contact the Customer Satisfaction Manager before contacting any
Post Offices.
You should have received electronically the Phone Script (ref: MCVP 97/script.doc),
Questionnaire (ref: MCVP 97/Quest&Report.doc), standard follow up letter (ref:
MCVP 97/letter.doc) and MCVP Procedure document (ref: CS/PRO/033). A new
questionnaire should be printed for each Post Office visit (always have a spare
questionnaire in your Interviewer’s Pack just in case).
You will have received an ‘Interviewer’s Pack’. This should contain:
e Phone Script
* Questionnaire
e Sample documents
¢ Interviewers Summary Guide
¢ Post Office list.
Arranging Appointments
First check the Horizon System Helpdesk call history, which will be supplied by the
Customer Satisfaction Manager on request. Contact only the Post Offices on your
list. Arrange a time to visit using the phone script. Make sure you cover all the
information on the phone script.
Get directions to the Post Office.
Feed back immediately all appointments made to Customer Satisfaction Manager,
giving:
e FAD Code
« POName
¢ PO Contact
¢ Phone Number
e Date
¢ Time.
lf any appointment details change, notify Customer Satisfaction Manager asap.
The Interviews
Section 1 can be completed before the interviews, where possible. You must check
this information with the interviewees before moving on to Section2. Make sure
your handwriting is always legible.
Just get any points of note regarding the implementation work, as it may have a
bearing on how the interviewees respond to the questionnaire. If nothing out of the
ordinary happened during implementation and the interviewees appear fine about it,
just enter OK in Section 2.
Do not rush the questions. Make sure the interviewees understand each question
before giving an answer. Read out the four positive and negative options available
as answers. Only volunteer the N/A option if you see no alternative
COMMERCIAL IN CONFIDENCE Page 27 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
7.1
8.1
8.2
The small italic print in brackets under some questions is for your information only, do
Not repeat it at the interview. Some reference the sample documents you have in
your Interview Packs. These can be shown to help identify the documents referred
to in the question.
Make sure you ask for any other comments after each question is answered,
especially where negatives have been given.
When you get to Section 11 try to contain the responses to relevant issues,
concerns and always ask if there are any good news stories the interviewees can
share with us. Encourage discussion about their views. Use the additional notes
section if needed.
Delete the ‘willing/unwilling to be contacted again’ statement as appropriate.
Thank the interviewee for their time, shake hands, and leave the premises.
Follow Up Letters
A standard letter should be completed. The middle section should be your summary
of the interviewee’s views, questions, concerns, etc, but not the responses to
sections 3 to 10 of the questionnaire.
Feedback Reports
Keep the completed questionnaires and reports confidential and secure. Return
them to the Customer Satisfaction Manager as soon as possible.
Reprint the questionnaire and add it to the Interview Pack ready for your next
Interview. If you are doing more than one a day make sure you take enough copies
of the questionnaire with you.
System Service
<information needed>
Service Logistics Review
<information needed>
Horizon System Helpdesk
Overview
The Horizon System Helpdesk (HSH), provides Post Office Counters Ltd counter
staff with a single point of contact for dealing with all problems relating to the
Horizon IT equipment installed on the counter. Additionally it provides a single point
of contact for technical interface queries from DSS (CAPS) staff via the ITSA
Service Helpdesk IBDN: POCL Interface still to be agreed by POCLI. Any calls received
that are inappropriate to this helpdesk are re-directed to the appropriate service
point, if sufficient information is available.
Horizon System Helpdesk information
The Horizon System Helpdesk (HSH) deals with all technical and operational calls
COMMERCIAL IN CONFIDENCE Page 28 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
related to the ICL Pathway environment or the data feeds into ICL Pathway from
Post Office Counters Ltd (POCL) and their clients such as DSS (CAPS) or DVLA
(TIP). It provides a single point of contact for counter staff, ICL Pathway operation
staff and POCL clients such as DSS (CAPS), for ICL Pathway-related incidents. All
incidents reported to the HSH from outside of the Pathway environment are sent via
a client service desk, for example, DSS incidents that affect the ICL Pathway
environment are sent via the ITSA Service Helpdesk.
IDN: Interfaces from POCL are still not agreed]
8.2.1 Horizon System Helpdesk telephone numbers
The HSH telephone contact number is I
TDN: HSH number changing due to BT enforced change - subject to Pathway CP]
8.2.2 Horizon System Helpdesk service hours
The service hours of the HSH are:
Full Service 0800 - 2000 Monday to Saturday
Skeleton Service 0500 - 0800 Monday to Saturday
Skeleton Service 2000 - 2400 Monday to Saturday
Skeleton Service 0700 - 2200 Sunday
The service is not provided on English Bank Holidays.
During these hours of operation, all calls are handled by Pathway operators with the
telephone equipment relaying messages to callers in exceptional circumstances, for
instance when call volumes exceed the telephone system limits.
8.2.3. Contacting the Horizon System Helpdesk
8.2.3.1 Call validation
The HSH is available to receive calls from any of its authorised sources and takes
calls that are described on the HSH Call Enquiry Matrix. When the HSH is
contacted, the helpdesk operator asks several questions in order to verify the
caller's identity and to ascertain the nature of the problem. These include name,
post office FAD or site code (where applicable) and details of the problem.
Before calling the helpdesk the caller should gather as much information as possible
to enable the helpdesk operator to diagnose the nature of the problem quickly.
8.2.3.2 Call logging
The operator attempts to resolve or diagnose the problem during this initial
telephone call. The information is recorded onto a helpdesk system and allocated a
unique call reference number.
Once the problem has been diagnosed the operator informs the caller of the call
identity number and what action to expect next. This identity number should be
recorded by the caller and quoted if the caller needs to ring the helpdesk about this
problem again.
If the customer's query/problem is not resolved within the initial telephone call, the
helpdesk advise the customer the date/time by which they will next receive contact.
This contact will take the form of either a site visit by an engineer or a telephone call
from someone in the Pathway support chain.
COMMERCIAL IN CONFIDENCE Page 29 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
8.2.3.3 One-shot password verification procedure
If the caller requires emergency password access, the HSH verifies the caller's
identity using agreed procedures, before issuing the emergency password.
The One Shot Password (OSP) facility is only available to Office Managers or
Supervisors, selected Regional Managers and auditors. Each person authorised to
use the OSP service is registered and undergoes a verification procedure before a
password is provided.
[DN: The verification procedure will be inserted here when agreed (CP1172).1
8.2.3.4 Third party calls
All incidents affecting the Horizon BPS and OBCS services, occurring in the DSS
environment must be reported to the ITSA Service Helpdesk. (The ITSA SHD is the
service point for all DSS IT calls. It is owned and managed by the DSS and provides
a single interface for issues that cross the boundary between DSS and ICL
Pathway.) Incidents reported from the ITSA SHD into the HSH are allocated a
reference number and subjected to the same call handling and escalation
procedures as for other calls. If calls are received direct from the DSS environment,
that is, not from the ITSA SHD, these are re-directed as described in Section 8.2.3.6
Call redirecting.
Similarly, incidents affecting the EPOSS, APS or reference data services that arise
in the POCL environment are also reported to the HSH in accordance to agreed
procedures.
[DN : Interfaces into POCL still not known or agreed. This issue is being driven by POCL
Product Management)
In the event of an unplanned post office closure, the affected post office contacts
the POCL Regional Helpdesk and informs them. The POCL Regional Helpdesk then
contacts the HSH on behalf of the affected post office to register an incident. The
POCL Regional Helpdesk operator quotes the post office FAD code, their name and
telephone number and the nature of the problem (see the NR2 Operating
Environment PPD [Ref. CS/PRO/0024)].
8.2.3.5 Call escalation
The HSH system manages each call throughout its life and alerts the HSH
supervisors should the helpdesk service levels approach or pass minimum SLA
levels. A manual escalation and alert procedure ensure timely escalation into ICL
Pathway, its suppliers, Post Office Counters Ltd and DSS. The escalation procedure
utilises a problem manager at a predetermined point. The problem manager is
responsible for ensuring that the correct management and resources are in place to
resolve the problem and restore the service levels. The problem manager is
supported by an escalation process that covers the BA, ITSA, Post Office Counters
Ltd and ICL Pathway organisations in case any disputes of ownership and
responsibility arise.
8.2.3.6 Call redirecting
The HSH retains responsibility for resolution and escalation of the call. Calls that
cannot be resolved in the initial phone call are passed electronically to support
specialists for resolution. All calls raised in the HSH are subject to SLA timings to
ensure that failures in the operation are resolved as quickly as possible. Should the
HSH receive calls that are not applicable to the service provided by that helpdesk,
they are re-routed to the appropriate helpdesk. Should the HSH receive calls that
COMMERCIAL IN CONFIDENCE Page 30 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
are for another Pathway helpdesk, such calls are re-directed via telephony links
between the two helpdesks. If the HSH receives calls for another authority's
helpdesk, the helpdesk operator advises the caller to ring the appropriate number.
Where possible the helpdesk operator supplies the phone number of the
appropriate desk.
8.2.3.7 Contingency
8.2.4
8.2.4.1
For contingency purposes, the helpdesk service is provided from two sites. These
sites are geographically separated, but linked by common computer and telephony
systems. In normal operation the service is provided from one site with a second site
being used to deal with over-spill at peak times. Should the first site become unable
to operate, the second site takes over. Depending on the nature and extent of the
problem, there may be a period of around two hours during which only a reduced
service is possible. In the extreme situation of neither site being able to provide the
helpdesk service, the telephone lines would be directed to respond to callers with a
pre-recorded message.
PO outlet incidents
This section gives descriptions of the calls that may be received by the HSH from
PO counter staff.
PO hardware incidents
The calls that may be received from PO counter staff about hardware incidents are
as follows:
Call ref Description
POHCO1 Hardware incidents may be logged by the Post Master or counter
to staff if a problem arises in using the equipment installed at the
POHC12 counter.
and Pan , -
PCHC15 Should such a situation occur, the caller rings the HSH to gain access
to suitable support. The caller is required to make a note of the
activity being performed when the problem arose, before the
helpdesk is called.
In the event of a Counter PC system failure or a peripheral failure, the
HSH allocates an engineer to attend the post office. The caller is told
when the engineer is expected to arrive.
The engineer normally carry spare parts with him; however
occasionally spare parts may need to be sent by courier to the post
Office. In this instance, the engineer will be scheduled to arrive shortly
after the spare part has been delivered. The post office is informed in
advance to expect a spare part to be delivered. Once at the post
office the engineer replaces the faulty part, tests its operation and
then checks that the Post Master is happy that the system is now
operational. The engineer must remove any broken equipment when
he leaves.
For more details see the NR2 Operating Environment PPD [Ref.
CS/PRO/0024].
POHC16 Post offices that have equipment destroyed or damaged should
contact the HSH who will deal with the call in the same way as a
hardware incident. If equipment is damaged the engineer completes
a report on the circumstances surrounding the damage which must
COMMERCIAL IN CONFIDENCE Page 31 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
be agreed and signed by the Post Master.
8.2.4.2
COMMERCIAL IN CONFIDENCE Page 32 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
8.2.4.3
PO software incidents
The calls that may be received from PO counter staff about software incidents are
as follows:
Call ref
Description
POSC01
to
POSCO5
Software problems can arise in the form of an error message
displayed on the screen or during the use of the system when
something fails to work correctly. Counter staff should record any
messages appearing on the screen or details of what activity was
being undertaken at the time of the problem and appraise the
helpdesk operator of these messages and actions. Details of the
incident are captured by the HSH operators, who determine the
nature of the problem, allocate a call identification number and inform
the caller of the next expected action. If the problem has occurred
before and has been previously resolved, the operator issues
instructions to the caller to help them to circumvent the problem, or
alternatively the helpdesk operator may attempt to resolve the
problem by repeating the process on the HSH reference system.
If the problem requires a more technical solution, the incident is
passed into the ICL Pathway support organisation. The incident is
then investigated and a workaround or resolution applied. The
support technicians may contact the caller to understand the incident
circumstance more fully, or to gather more evidence to assist the
investigation.
COMMERCIAL IN CONFIDENCE Page 33 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
PO network incidents
The calls that may be received from PO counter staff about network incidents are as
follows:
Call ref Description
PONW01 The network is monitored centrally and any fault will most likely be
to resolved before it becomes visible to the post office. However should
PONWOS _ the post office encounter networking difficulties the HSH should be
contacted. These are likely to show themselves as messages saying
that the central system cannot be contacted. If this occurs during a
foreign encashment transaction the Payment Card Helpline should be
contacted to perform the foreign encashment, then the call should be
transferred by the Payment Card Helpline to the HSH who should
take details of the network fault. The fault is investigated and
corrected by support staff who inform the Post Master when the
network link has been restored.
8.2.4.4 PO operation incidents
The calls that may be received from PO counter staff about operation incidents are
as follows:
Call ref Description
POOP01 Should the post office encounter operational difficulties whilst using
to the system, or the equipment and the system is not performing as
POOPO08 described in the counter procedures, the HSH should determine the
nature of the fault, the service affected, such as EPOSS and the
function that is failing, such as report printing. The incident is
recorded and passed onto Pathway support for investigation. The
caller is told what to expect next and when they will be next
contacted.
The HSH is not able to offer advice or report faults on Post Office
procedures that do not relate to the Horizon computer system,
equipment or operation.
8.2.4.5
COMMERCIAL IN CONFIDENCE Page 34 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
PO advice and guidance
The calls that may be received from PO counter staff to request advice and
guidance are as follows:
Call ref
Description
POAG01
to
POAG12
The HSH is available to offer advice and guidance to Post Office
counter staff of the use of the ICL Pathway systems or applications.
The helpdesk staff have access to counter procedures, reference
systems and are trained in the use of the system. Should Post Office
staff have difficulty in using the system or the documentation, they
should contact the HSH.
POAG13
Should the Post Master have an issue with the service or equipment
provided by ICL Pathway and wishes to complain, they can contact
the HSH who must manage the complaint.
In the event of a service complaint being received, the helpdesk logs
all details regarding the complaint and refers the caller to a helpdesk
supervisor, or the helpdesk manager. The supervisor or manager
then takes any necessary corrective action.
Each complaint is recorded and investigated, and the Post Master or
complainant is contacted to discuss the matter more fully during the
course of that investigation.
8.2.4.6 PO inappropriate incidents
The calls that may be received from PO counter staff that are inappropriate for the
HSH are as follows:
Call ref Description
INAO001 Callers who ring the HSH in error and are not authorised to use the
HSH are refused access to the HSH and if possible pointed to the
correct helpdesk.
INA002 to Should a member of the counter staff contact the HSH with a problem
INAO05 that does not relate to the ICL Pathway system or operation, they
should be asked to ring the appropriate helpdesk if known.
8.2.5 Regional Helpdesk incidents
This section gives descriptions of the calls that may be received by the HSH from
POCL Regional Helpdesks.
Call ref Description
REGOO1 POCL Regional Helpdesks act as business support for the outlets
to and are contacted in the event of an outlet closing of a temporary or
REGO003 emergency basis. The POCL Regional Helpdesk informs ICL
Pathway of all such instances by logging an incident call on the HSH
quoting the post office FAD code, the caller’s name and contact
number and the nature of the closure. The HSH inform the Payment
Card Helpline of this closure and cancel any planned engineer visits
to that site. The Payment Card Helpline actions the closure as to
agreed procedures as outlined in the document Pathway Process for
POCL Operational Business Change [Ref. CS/PRD/0019].
IDN: These procedures are still awaiting agreement]
COMMERCIAL IN CONFIDENCE Page 35 of 104
ICL Pathway
POL00393875
POL00393875
ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
8.2.6 Security incidents
This section gives descriptions of the calls that may be received by the HSH relating
to security incidents.
Call ref
Description
SEC001
Post offices that have equipment stolen must follow existing Post
Office Counters Ltd procedures to report the theft, that is, contact the
Police and Post Office Counters Ltd Regional Helpdesk. ICL Pathway
must replace the stolen equipment once the incident has been
reported to the HSH by the Regional Helpdesk. If the counter and the
ICL Pathway wiring are undamaged, ICL Pathway must arrange for
the counter system to be re-equipped quickly to bring the post office
back into operation. However, work may have to be scheduled to
correct any physical damage and this must be arranged at a suitable
time and agreed with the Post Master.
SEC002
Each time a PC is powered on the Post Master must perform the Post
Office Log On (POLO) procedure. The Post Master is issued with a
PMMC card plus a spare and PIN when the equipment is installed.
This card and PIN must be kept in a secure location and used when
the equipment is powered on after being switched off as described in
the NR2 Access Control and User Administration PPD [Ref.
CS/PRO/0025].
If the card or PIN is lost, the Post Master must ring the HSH. The
helpdesk operator will ask a series of questions to verify the identity
of the caller and then pass the caller on to a supervisor. The
supervisor then assists the Post Master to generate a new PIN or
allocates a PIN to the spare card. This process involves the Post
Master following verbal instructions from the HSH Supervisor. In
extreme cases where the system cannot generate the PIN number
easily the Post Master is taken through the underlying recovery
process that involves typing a series of letters and numbers into the
Horizon system and takes approximately twenty minutes to complete.
The new PIN must be stored securely as instructed in the NR2
Access Control and User Administration PPD [Ref. CS/PRO/0025],
and in the case of a lost card the one card will be invalidated and a
replacement card is ordered for issue to the post office.
SEC003
Passwords within an office are controlled by the Office Manager or
supervisor and if a member of staff loses or forgets his or her
password the Office Manager can reset it. If the Office Manager loses
or forgets his or her password an emergency password can be issued
by the HSH using the One Shot Password service (OSP). Audit staff
also need access to the system and require use of the OSP service
to gain access. Each person authorised to use this service is pre-
registered and has to undergo a verification procedure before access
to the OSP service is permitted.
IDN: The verification procedure is still not agreed [¢P 117211
Once verified the caller has to enter the OSP service on the counter
system and is issued with a password which is valid for only one
session. (Further information on system access using one-shot
passwords is given in the NR2 Access Control and User
Administration PPD [Ref. CS/PRO/0025])
COMMERCIAL IN CONFIDENCE Page 36 of 104
ICL Pathway
POL00393875
POL00393875
ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
SEC004
The Horizon system monitors and records unsuccessful,
unauthorised attempts to access the system. These are investigated
by POCL and Pathway security.
SECO00S
If the Post Master or any Post Office Counters Ltd staff discover or
suspect that any part of the Horizon system or environment presents
a Safety risk, it must be reported immediately to the HSH. The
helpdesk must instruct the caller to switch off any electrical
equipment, or take any necessary remedial action until an engineer
can attend the affected site. When the engineer arrives on site he will
assess the situation and take appropriate action to remove the risk.
SEC007
If the Post Master or Post Office Counters Ltd representative
suspects a security breach, for example, passwords have become
known to an unauthorised person, the Horizon system has been
tampered with, or someone suspects their user information has been
used without their knowledge, the HSH must be informed
immediately. The helpdesk must immediately inform the ICL Pathway
Security Unit who will begin investigations. The caller may be
contacted during this investigation and is advised to make notes of
the circumstances surrounding the suspected security breach. ICL
Pathway may remove any system access at this point and the post
office may be prevented from using the system until authorisation is
given.
8.2.7 Planned changes
This section gives descriptions of the calls that may be received by the HSH relating
to planned changes.
8.2.8
Call ref Description
PLAOO1 Incidents contained within this section relate to planned changes to
to POCL outlets, reporting structures or products and are driven by the
PLAO12 Operational Business Change catalogue.
IDN: OBE catalogue still to be agreed, this section may change or be removed
prior to NR21
COMMERCIAL IN CONFIDENCE Page 37 of 104
ICL Pathway
POL00393875
POL00393875
ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
8.2.8.1
POCL client interface incidents
This section gives descriptions of the calls that may be received by the HSH from
systems that interface with the Pathway environment.
POCL client interface operation incidents
The calls that may be received by the HSH from ICL Pathway about the operation of
the feeder systems such as file transfer failure, data file issues and data transfer
timetable disruptions are as follows:
Call ref Description
FEEO1 to Incidents arising from the transfer of data into and out of the ICL
FEEO11 Pathway environment and systems should be registered on the HSH.
Initially, the HSH pass these incidents to ICL Pathway operations who
investigate the nature of the incident and pass the call into second
line support, if necessary.
8.2.9 Reconciliation incidents
8.2.10
The calls that may be received by the HSH about reconciliation incidents are as
follows:
Call ref Description
RECO01 Reconciliation incidents will be raised from various sources: the
to counter staff, DSS via the ITSA SHD concerning OBCS and BES,
RECO05 POCL concerning the EPOSS, APS and Reference Data services,
Payment Card Helpline for BES and Pathway Business Support for
all services.
All incidents are registered on the HSH and given a number and
priority. Incidents are categorised according to the service affected
and range from payment problems to accounting anomalies. They are
given an incident priority based on the nature of the incident.
Reconciliation incidents raised are passed directly to the ICL Pathway
Business Support Unit.
COMMERCIAL IN CONFIDENCE Page 38 of 104
ICL Pathway
POL00393875
POL00393875
ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
Pathway remote and central system incidents
This section gives descriptions of the calls that may be received by the HSH from
ICL Pathway about hardware, software or network incidents.
Call ref Description
Calls The HSH also contains details of incidents expected from within the
starting ICL Pathway environment or operation that are identified by an ICL
RHW, Pathway operator or support technician.
Rowe All these incidents are recorded and managed by the HSH using the
ROP, same processes and procedures.
CHW,
csw,
CNW and
COP
8.2.11 Pathway implementation incidents
This section gives descriptions of the calls that may be received by the HSH from
ICL Pathway about the implementation of the environment or system into the post
office, the scheduled training of staff or the migration of the post office onto the
Horizon system.
Call ref Description
IMP001 These incidents are registered on the HSH and given an incident
to number. The incident calls are then passed onto the implementation
IMP007 desk who alter schedules where possible or liase with suppliers
performing installation or migration work, to rectify the incident.
COMMERCIAL IN CONFIDENCE Page 39 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
9.1
9.2
9.2.1
9.2.2
Payment Card Helpline
Overview
Girobank are the supplier of the Payment Card Helpline (PCHL) for ICL Pathway.
This service provides a 24 hour, 365 days a year, bi-lingual (Welsh and English
language) helpdesk facility for enquiries on matters relating to payment cards. There
are two different helpdesk facilities provided within the PCHL, the first being a Card
Management Service (CMS) which deals with all enquiries regarding cards and Pick
Up Notices (PUNs). The second facility is a Payment Authorisation Service (PAS)
which deals with calls relating to the status of automated benefit payments.
The Card Management Service (CMS) Helpdesk, provides a single point of contact
for all enquiries relating to benefit payment cards and PUNs. The majority of calls
are from customers, although some are from Post Office Counters Ltd staff, DSS
Office staff and third parties.
The Payment Authorisation Service (PAS) Helpdesk, provides Post Office Counters
Ltd staff and DSS Office staff with a single point of contact for dealing with all
enquiries relating to the status of automated benefit payments. It does not deal with
enquiries from the public, with the specific exception of a customer payment error
call.
Call types are defined in the Call Enquiry Matrix (CS/FSP/0003 v2.0). Helpdesk
operation and service are detailed in the Helpdesk PPD (CS/PRO/00019).
Payment Card Helpline information
Payment Card Helpline telephone numbers
The Payment Card Helpline contact numbers are as follows
DSS customers (English)
DSS customers (Welsh) : G O :
DSS staff ; R i
Post Office Counters Ltd staff
All calls are handled by Pathway operators. The telephone equipment may
exceptionally relay pre-recorded messages to customers, for example, when an
emergency situation arises in the call centre, or call volumes exceed telephone
system limits.
The CMS Helpdesk deals with calls from DSS customers, DSS staff, Post Office
Counters Ltd staff and third parties.
The PAS Helpdesk deals with calls from DSS staff and Post Office Counters Ltd
staff. Customer and third party calls are not supported with the specific exception of
a customer payment error call (see Section 9.5.9 Payment error calls).
Payment Card Helpline service hours
The service hours for the Payment Card Helpline are as follows:
CMS Manned service 0800 hours to 2000 hours Monday to
Saturday, no manned service on Sundays and English Bank
Holidays, but with a recorded message outside manned
COMMERCIAL IN CONFIDENCE Page 40 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
service hours.
PAS Manned service 0800 hours to 2000 hours Monday to
Saturday, no manned service on Sundays and English Bank
Holidays, but with a recorded message outside manned
service hours.
9.2.3 Contacting the Payment Card Helpline
The Payment Card Helpline calls are answered and resolved at the first point of
contact (with the exception of NSI calls which are referred to an NSI authorised
agent). The helpdesk operator who receives the call is also responsible for the
resolution of the call.
9.2.3.1 PO counter Calls
In order to contact the Payment Card Helpline, Post Office Counters Ltd staff should
telephone The Pathway operator first verify the identity of the post
office (see Section 9.2.10 Caller identification).
IDN: The acceptance of risk by ICL that there Is no Payment Card Helpline helpdesk to caller
Verification procedure has not yet been agreed by POCLI
If the call relates to a card batch, the caller must provide the card batch number; if
the call relates to a DSS customer's card or payment, the caller must provide the
customer's NINO. The caller should then explain the nature of the call to the
operator. The Pathway operator may then ask further questions to assist in the
resolution of the call.
For certain calls, such as foreign encashments during system failure, the Payment
Card Helpline needs to perform the extended verification procedure (EVP) of the
customer by asking the post office clerk to ask the customer specific questions,
such as month of birth.
9.2.3.2 DSS office calls
-ln.order.to contact the Payment Card Helpline, DSS staff should telephone:
1__.GRO__I The Pathway operator will first verify the identity of the caller (see Section
9.2.10 Caller identification). The caller must then explain the nature of the call to the
operator. The Pathway operator may then ask further questions to assist in the
resolution of the call.
9.2.3.3 DSS customers’ calls
ict the Payment Card Helpline, DSS customers should telephone
's who prefer to speak in the Welsh language, should
telephone: The Pathway operator will first verify the identity of the
caller (see . 10 Caller identification). The caller should then explain the
nature of the call to the operator. The Pathway operator may then ask further
questions to assist in the resolution of the call.
IDN: The Welsh service will not be operational until national rollout but will be demonstrable
by arrangement during live trial]
9.2.3.4 Third party calls
A third party call is from a member of the public who may or may not be a registered
DSS customer in their own right but who is not calling with regard to their personal
situation as a DSS customer.
In order to contact the Payment Card Helpline, third parties must telephone
COMMERCIAL IN CONFIDENCE Page 41 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
9.2.4
9.2.5
9.2.6
9.2.7
9.2.8
9.2.9
_I The Pathway operator first establishes the reason for
. If the third party is calling on behalf of a DSS customer, then the operator
must verify the customer's identity (see Section 9.2.10 Caller identification).
Otherwise, caller verification is not necessary but the operator must in all cases ask
for and log the caller’s name, although this may not be given. The Pathway operator
then asks further questions to assist in the resolution of the call.
Call escalation
Payment Card Helpline calls are answered and resolved at the first point of contact,
as stated in Section 9.2.3 Contacting the Payment Card Helpline. However, should
the operator experience difficulty in resolving a call to the satisfaction of the caller,
the operator should seek immediate assistance from the supervisor who must seek
to resolve the issue to the caller’s satisfaction.
A manual escalation and alert procedures ensure timely escalation into ICL
Pathway, its suppliers, Post Office Counters Ltd and DSS. The escalation procedure
utilises a problem manager at a predetermined point. The problem manager is
responsible for ensuring that the correct management and resources are in place to
resolve the problem.
Contingency
For contingency purposes the helpdesk service is provided from two sites. These
sites are geographically separated by several miles, but linked by common
computer and telephony systems. Should one site become unable to operate, the
second site continues to operate independently and the agreed level of service is
maintained. In the extreme situation of neither site being able to provide the
helpdesk service, the telephone lines respond to callers with a pre-recorded
message.
IDN: The dual site service will be operational between the start of NR2 and live trial and is
under discussion]
Call redirecting
The helpdesk operator who receives the call is also responsible for the resolution of
the call. Calls are not passed on to specialists, unlike calls to the HSH. However,
should the helpdesk receive calls which are appropriate for both the Payment Card
Helpline and the HSH, then on completion of the Payment Card Helpline call, the
Payment Card Helpline should endeavour to transfer the call to the Horizon
Helpdesk, via the telephony link between the two helpdesks. If the Payment Card
Helpline receives calls for another authority's helpdesk, the helpdesk operator
should advise the caller to ring the appropriate number. Where possible the
helpdesk operator should supply the phone number of the appropriate desk.
Call recording
IDN: Call recording is under review between Pathway and the Authorities.)
Call logging
All calls are automatically logged within the helpdesk application, with a unique call
ID. This ID is visible for DSS calls and is given to all DSS callers.
Payment Card Helpline helpdesk to caller verification procedure
IDN: This procedure is still being discussed]
COMMERCIAL IN CONFIDENCE Page 42 of 104
ICL Pathway
POL00393875
POL00393875
ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
9.2.10 Caller identification
The helpdesk operator performs the following identification procedures, according to
the type of call:
9.3
9.3.1
PO counter staff calls Verifies the identity of the post office by asking questions
based on the post office FAD code, post office address and
telephone number, and then requests the caller to give their
user name.
DSS Office calls Verifies the identity of the caller by asking questions based
on the caller's user name and password.
DSS customer calls Verifies the identity of the caller by carrying out EVP on the
caller's identity.
Third party calls on Verifies the legitimacy of the caller by carrying out EVP
behalf of a DSS based on the DSS customer's identity.
customer
PO counter staff calls
The following subsections list the calls that may be received by the Payment Card
Helpline from PO counter staff.
For those calls where a customer is present, the Payment Card Helpline tells the
clerk what to say to the customer, as indicated in the call type description below.
Card/batch calls (PCDF)
The calls that may be received from PO counter staff about payment cards or
batches are as follows:
Call ref
Description
PO 1A
If a batch of cards has been identified as wrongly delivered after having
being signed for, the Payment Card Helpline should advise the caller to
follow the counter procedure for redirection, which is to insert the
unopened package (without removing or altering the original label) into
a larger package labelled for registered delivery ready for the next
collection from the post office by RML. The helpdesk should ask the
caller for the RML label code and log a note in the system.
[DN: This is still under discussion pending the POCL subcontract and RML
subcontract. The procedure may be to cancel and reorder!
PO1E
If a card, PUN or temporary token is reported as being unavailable in
the post office although it had previously been acknowledged as
present in the post office, the Payment Card Helpline should check the
status of the item and advise the caller of the item’s status.
If the item is a card and it is waiting for collection, then the helpdesk
must take the action as for a lost card, namely to stop the card and
reorder the card, and advise the caller to tell the customer that the card
is now reordered and that a new PUN will be issued.
If the item is a card with a ‘withdrawn/expired’ status, or a card, PUN or
temporary token with an ‘impounded’ status, then the helpdesk should
advise the caller of the status. No further action is required.
If the item has any other status but the caller expects the status to be
‘withdrawn/expired’ or ‘impounded’, then the helpdesk must impound
COMMERCIAL IN CONFIDENCE Page 43 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
the item and advise the caller when the action has been completed.
PO 1F If the wrong card is signed and swiped during the activation procedure,
the Payment Card Helpline must stop and reorder the signed card
They will then advise the caller to destroy the signed card by cutting in
half and issue the correct card if it is available. If the correct card is not
available, the Payment Card Helpline should advise the caller to tell the
customer to call the Payment Card Helpline (call CC 3A) to check
delivery.
PO 1G If the card package appears to have been tampered with, the Payment
Card Helpline must cancel the batch to stop the cards, re-order the
card batch, and advise the caller to destroy the batch by cutting each
card in half.
PO 1H If the bar-code is invalid, cannot be read or is missing, the Payment
Card Helpline asks the caller to give details of any one card from the
package. The helpdesk then identifies the batch identifier and status.
« Ifthe batch status is cancelled, the helpdesk must advise the caller
to destroy all the cards.
« Ifthe batch status is OK and the batch is at the correct post office,
the helpdesk should advise the caller to enter the batch identifier
manually and then proceed normally. If the caller is unable to do
this, the helpdesk should accept the batch (as for call PO 2A),
advise the caller when the action is completed and that the caller will
be transferred to the HSH to log a fault call. The helpdesk should
then transfer the call to the HSH.
« Ifthe batch status if OK but the batch is not at the correct post
office, the helpdesk must cancel and re-order the batch, and advise
the caller to destroy all the cards.
« Ifthe batch cannot be identified the helpdesk must advise the caller
to destroy all the cards.
(Note that the batch monitoring process would ensure that any such
‘lost’ batches are properly cancelled and reordered).
9.3.2 System failure: CMS calls (PCDF)
The calls that may be received from PO counter staff about PCDF during system
failure are as follows:
Callref Description
PO 2A If the acknowledgement of a batch receipt is prevented due to a system
failure, the Payment Card Helpline should request the batch identifier
and action the receipt. The helpdesk should advise the caller when the
action is completed and whether there is any anomaly requiring special
action.
PO 2B If the issue and activation of cards is prevented due to a system failure,
the Payment Card Helpline actions the activation, requesting as
appropriate data relating to the PUN (PUN bar-code) or expiring card
(PAN and Issue Number), and performing EVP. The helpdesk advises
the caller when the action is completed and whether there is any
anomaly requiring special action.
PO 2D If the recording and reporting of card, PUN or temporary token impounds
COMMERCIAL IN CONFIDENCE Page 44 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
is prevented due to a system failure, the Payment Card Helpline will
action the impound and provide the caller with receipt data. The
helpdesk advises the caller to follow counter impound procedures.
9.3.3 System failure: Encashment calls
The calls that may be received from PO counter staff about encashment during
system failure are as follows:
Callref Description
PO 3B If a nominated office encashment is prevented due to a system failure,
the Payment Card Helpline advise the clerk of the verification questions
required to be answered by the customer, provide payment details in
order that the payment may be made at the post office counter, and
update PAS. The normal encashment rules, that is, RPOI, GRI, EVP are
enforced. The helpdesk advises the caller when the action has been
completed on the PCHL system.
PO 3D If a foreign encashment is prevented due to a system failure, the
Payment Card Helpline, providing the foreign encashment count is less
than the allowable amount (that is, 2 in 26 weeks), advises the clerk the
verification questions required to be answered by the customer, provide
payment details in order that the payment may be made at the post
office counter, and update PAS. The normal encashment rules, that is,
RPOI, GRI, EVP are enforced. The helpdesk advises the caller when the
action has been completed on the PCHL system.
9.3.4
COMMERCIAL IN CONFIDENCE Page 45 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
System failure: Payment calls
The calls that may be received from PO counter staff about payment during system
failure are as follows:
Callref Description
PO 4A If there is a query regarding a hand-written receipt (following a Payment
Card encashment or a counter printer failure) the helpdesk should:
e If still within the same cash account week as the original transaction
and it is a Payment Card Helpline encashment:
confirm the authorised payment values making up the
encashment value (obtained either from PAS or the daily
Payment Card Helpline encashment reports).
e If still within the same cash account week as the original transaction
and it is an error during counter printer failure:
confirm the authorised payment values making up the
encashment value if available from PAS, otherwise advise the
post office to run the BES weekly encashment report and
check the value against the receipt.
« Ifitis an underpayment not in the same cash account week as the
original transaction:
the Payment Card Helpline records the details and advises the
caller to tell the customer that their request will be
investigated and, if found valid, that they should receive a
cheque within two weeks. The helpdesk then phones the
HSH to log the incident and faxes details to the Pathway
Business Support Unit.
If the receipt is not hand-written, the helpdesk advises the caller to refer
the customer to the BIA.
(See also call CC 10A).
IDN: Payment reconciliation correction calls are under discussion.
PO4B The Payment Card Helpline confirms whether a payment has been
encashed elsewhere to a permanent agent or alternative payee.
PO4C If a change of nominated post office is prevented due to a system
failure, the Payment Card Helpline actions the change and advise the
caller when the action is completed. If, at the same time, an urgent
payment is required but the foreign encashment count has exceeded
the allowable amount, that is, 2 in 26 weeks, the Payment Card Helpline
allows the foreign encashment to proceed as in PO 3D, provided that
RPOI and GRI are unset.
9.3.5 Complaint calls
The calls that may be received from PO counter staff about complaints regarding
the Payment Card Helpline are as follows:
Callref Description
PO 5A If service complaints are received regarding the Payment Card Helpline,
the helpdesk staff log all details regarding the complaint and pass the
details to the Helpdesk Manager. The helpdesk advises the caller that
COMMERCIAL IN CONFIDENCE Page 46 of 104
ICL Pathway
POL00393875
POL00393875
ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
their comments have been noted and will be actioned as appropriate.
The Manager then takes any necessary corrective action.
PO 5B
If service complaints are received regarding card batches, cards, PUNs
or temporary tokens, where the PUN complaint is other than lateness or
non-delivery, the helpdesk staff log all details regarding the complaint
and pass the details to the Helpdesk Manager. The helpdesk advises
the caller that their comments have been noted and will be actioned as
appropriate.
The Manager then takes any necessary corrective action.
9.3.6 Rollout-only calls
The calls that may be received from PO counter staff that are specific to rollout only
are as follows:
Call ref
Description
PO 6A
If a foreign encashment of a DSS customer's benefit at one of the
approved 1500 non-automated post offices is required, the Payment
Card Helpline first asks the clerk to confirm that the post office is
authorised to make payment card encashments. If so, and the foreign
encashment count is less than two, they advise the clerk of the
verification questions to be answered by the customer, provide payment
details in order that the payment may be made at the post office
counter, and update PAS. The normal encashment rules, for example,
RPOI, GRI, EVP are enforced. The helpdesk advises the caller when
the action has been completed on the PCHL system.
PO 6C
If a request is made to impound a card or temporary token during
foreign encashment at one of the approved 1500 non-automated post
offices, the Payment Card Helpline action the impound and advise the
caller to issue an impound receipt and follow the Post Office impound
procedures.
9.3.7 Encashment anomaly calls
The calls that may be received from PO counter staff relating to encashment
anomalies are as follows:
Call ref
Description
PO 7A
If an encashment is required for a customer who claims their nominated
post office has an emergency temporary closure and whose foreign
encashment count,that is, 2 in 26 weeks, has been exceeded, the
Payment Card Helpline processes the encashment as in a PO 3D call,
in order that the payment may be made at the post office counter
(provided that RPO! and GRI are unset), and then updates PAS.
PO 7B
If an encashment is required for a customer who has just changed their
nominated post office and is expecting encashment, but the system
indicates that no encashment is due, the Payment Card Helpline checks
if payment is due, but not apparent at the post office because the
foreign encashment count limit, that is, 2 in 26 weeks, has been
reached. This can occur because the system does not action the
change of nominated post office immediately, but overnight. If so, the
helpdesk processes the encashment as in a PO 3D call, in order that
the payment may be made at the post office counter, and than updates
COMMERCIAL IN CONFIDENCE Page 47 of 104
ICL Pathway
POL00393875
POL00393875
ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
PAS.
9.3.8 System failure: OBCS calls
The calls
that may be received from PO counter staff relating to OBCS
encashments during a period of system failure are as follows:
Call ref
Description
PO 8A
If the customer wishes to make a foreign OBCS encashment during a
period of system failure, the Payment Card Helpline asks the caller for
the Customer Reference Number, Order Book Serial Number and
Common Payment Package Number. The helpdesk then checks the
database and advises the caller:
e lf there is no stop in place, to make the encashment.
e If there is a stop in place, to not make any encashments but to
impound the book.
e lf there is a recall in place with the effective date earlier than today,
to encash one foil and impound the book.
¢ lf there is a recall in place with the effective date of today or later, to
encash foils dated prior to and including today and impound the
book.
9.3.9 PO counter staff calls on behalf of customers in exceptional
circumstances
The calls
exception:
that may be received from PO counter staff on behalf of customers in
al circumstances are as follows:
Call ref
Description
POC 1
If a PO clerk wishes to help a customer who, for example is elderly or
infirm or has a language difficulty, they may make a call on behalf of
that customer at their own discretion.
All valid calls on behalf of customers in exceptional circumstances are
treated as third party calls and must be made using the customer phone
number as described in Section 9.2.3.4 Third party calls instead of the
phone number for PO counter calls.
9.3.10 PO counter staff inappropriate calls
The calls
that may be received from PO counter staff that are considered
inappropriate to the Payment Card Helpline are as follows:
Callref Description
POI 1 to If the Payment Card Helpline receives calls that are not in the call
POI5 matrix, or which request information that the Payment Card Helpline
may not provide, the caller is advised that the call is inappropriate. For
example, a request for payment details without the card details being
provided, or a call to report hardware failure, would be inappropriate.
If a call is appropriate for both the Payment Card Helpline and the HSH,
the call is subsequently transferred electronically to the HSH; otherwise,
the caller is asked to contact the appropriate helpdesk. Refer to
Section 9.2.6 Call redirecting for more information.
COMMERCIAL IN CONFIDENCE Page 48 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
9.4 DSS staff calls
The following subsections list the calls that may be received by the Payment Card
Helpline from DSS Office staff.
9.4.1 Payment calls
The calls that may be received from DSS Staff about payment are as follows:
Callref Description
BA1A If the status or encashment details of a payment are requested, the
and Payment Card Helpline requests the DSS customer’s NINO, Authorised
BA1B Payment reference number and provide the necessary information.
BA 1C If card usage details are requested, the Payment Card Helpline provides
the necessary information.
BA 1D If an immediate payment stop is required, the Payment Card Helpline
requests the DSS customer's NINO, Authorised Payment reference
number and places a stop on the payment. The helpdesk advises the
caller when the action is completed.
9.4.2 Card/PUN calls
The calls that may be received from DSS Staff about cards or PUNs are as follows:
Callref Description
BA 2A If the status or delivery forecast of a No Fixed Abode PUN is requested
the Payment Card Helpline provides the necessary information.
BA 2B If an enquiry is made on the reasons for impoundment of a card or
PUN, the Payment Card Helpline provides the necessary information.
BA 2C If a request is made to reorder a card following investigation of
impoundment or card collection period expiry, then provided that there
is no change to customer circumstances, the Payment Card Helpline
reorders the card. The helpdesk advises the caller when the action is
completed.
BA 2E If the status or delivery forecast of a current or previous card or PUN is
requested, the Payment Card Helpline provides the necessary
information.
If the caller is querying the status of a card held by a customer who is
present with the caller, and the card is found to be unactivated, the
helpdesk should ask the caller if the customer still has their PUN:
¢ If the customer still has their PUN and there is adequate time in
which to collect the card, the helpdesk should advise the caller to tell
the customer to return to the post office with their card and PUN for
card activation.
e Ifthe customer does not have their PUN, the helpdesk should order
another PUN or card plus PUN (as appropriate). The helpdesk
should advise the caller to tell the customer that they will receive a
new PUN shortly and that they should then visit their post office for
card activation.
BA 2F If the termination of a card is requested, the Payment Card Helpline
should stop the card. The helpdesk advises the caller when the action is
COMMERCIAL IN CONFIDENCE Page 49 of 104
ICL Pathway
POL00393875
POL00393875
ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
completed.
9.4.3. Temporary token calls
The calls that may be received from DSS Staff about temporary tokens are as
follows:
Call ref
Description
BA 3A
If the termination of a temporary token is requested, the Payment Card
Helpline stops the token and advises the caller when the action is
completed.
BA 3B
If an order of an emergency supply of temporary token books is
requested, the Payment Card Helpline should create the order and
advise the caller when the action is completed.
BA 3C
If anomalies regarding the number of temporary tokens ordered and
received (for normal or emergency delivery) are reported, the Payment
Card Helpline must stop any books recorded as supplied but not
delivered. The helpdesk advises the caller that the books are stopped
and that they should be destroyed if they are subsequently found or
received. The helpdesk asks the caller if they require an emergency
order (see call BA 3B).
BA 3D
If, during a DSS Office system failure, a request is made to assign
temporary tokens to pre-existing payments for existing customers
whose personal details do not require updating, the Payment Card
Helpline actions the assignment provided that the following details are
supplied: NINO, temporary token ID and specified post office. The
helpdesk advises the caller when the action is completed.
BA 3E
If an overdue delivery of a supply of temporary token books is reported,
the Payment Card Helpline asks the caller if they want to cancel the
outstanding order and reorder, orders an emergency order, or takes no
action and awaits the next delivery.
BA 3F
If a delivery of an emergency supply of temporary token books is
reported, the Payment Card Helpline should ask the caller for the
package ID and the number of books. The helpdesk updates the order
record and advises the caller when the action is completed.
BA 3G
If a delivery of a supply of temporary token books is reported lost, stolen
or damaged subsequent to delivery, the Payment Card Helpline stops
the books and advise the caller when the action is completed. The
helpdesk asks the caller whether they require an emergency order (see
call BA 3B).
BA 3H
If a change to the provisioning parameters for the automatic supply of
temporary token books is requested, the Payment Card Helpline
amends the record for the specific DSS office and advises the caller
when the action is completed.
BA 31
If an enquiry is made on the reasons for impoundment of a temporary
token, the Payment Card Helpline provides the necessary information.
9.4.4 Complaint calls
The calls that may be received from DSS Staff about service complaints are as
follows:
COMMERCIAL IN CONFIDENCE Page 50 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
Callref Description
BA 4A If a service complaint is received regarding the Payment Card Helpline,
the helpdesk logs all details regarding the complaint and passes the
details to the Helpdesk Manager. The helpdesk advises the caller that
their comments have been noted and will be actioned as appropriate.
The Manager then take any required corrective action.
BA 4B If a service complaint is received regarding cards, PUNs, temporary
tokens or temporary token batches (where a PUN complaint is other
than lateness or non-delivery), the helpdesk logs all details regarding
the complaint and pass the details to the Helpdesk Manager. The
helpdesk advises the caller that their comments have been noted and
will be actioned as appropriate.
The Manager then take any required corrective action.
9.4.5 Rollout-only calls
The calls that may be received from DSS Staff about rollout only are as follows:
Callref Description
BA 5B If a request is made regarding change of password for DSS staff
verification, the Payment Card Helpline takes action as requested and
advises the caller when the action is completed.
9.4.6 DSS office calls on behalf of customers in exceptional circumstances
The calls that may be received from DSS Staff on behalf of customers in
exceptional circumstances are as follows:
Callref Description
BAC 1 If a DSS officer wishes to help a customer who, for example is elderly or
infirm or has a language difficulty, they may make a call on behalf of
that customer at their own discretion.
All valid calls on behalf of customers in exceptional circumstances are
treated as third party calls and must be made using the customer phone
number as described in Section 9.2.3.4 Third party calls instead of the
phone number for DSS office calls.
9.4.7
COMMERCIAL IN CONFIDENCE Page 51 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
DSS staff inappropriate calls
The calls that may be received from DSS Staff which are inappropriate to the
Payment Card Helpline are as follows:
Callref Description
BAI 1 to If a call is received by the Payment Card Helpline that is not in the call
BAI5 matrix or alternatively requests information that the helpdesk may not
provide, the caller should be informed that the call is inappropriate and
be advised on an alternative course of action, where known.
These calls include requests to amend static data (personal details and
nominated PO).
9.5 DSS customer calls
The following subsections list the calls that may be received by the Payment Card
Helpline from DSS customers.
9.5.1 Card/PUN status calls
The calls that may be received from customers about the status of cards or PUNs
are as follows:
Callref Description
CC 1A If the status or delivery forecast of a card or PUN is requested, the
and Payment Card Helpline provides the necessary information.
CC 1B Where the status check is requested because the post office states
there is no payment available but the BA states there should be, the
helpdesk should check if the card was issued unactivated, and if so:
« If the customer still has their initial PUN and there is adequate time in
which to collect the card, the helpdesk should advise them to return
to the post office with their card and PUN for card activation.
e Ifthe customer does not have their initial PUN, the helpdesk should
order another PUN, or card plus PUN (as appropriate). The helpdesk
should advise the caller that they will receive a new PUN shortly and
that they should then visit their post office for card activation.
9.5.2 PUN receipt calls
The calls that may be received from customers about the receipt of PUNs are as
follows:
Callref Description
CC 2A If a PUN is not received, the Payment Card Helpline should, in most
and circumstances, order another PUN and advise the caller that they will
CC 2B receive a new PUN shortly.
In certain circumstances, for example, change of address pending,
three PUNs already issued, another PUN must not be issued. The
Payment Card Helpline should note on the system why this course of
action has been taken. If three PUNs have already been issued the
customer should be referred to the BIA.
CC 2c If a PUN is not received and the customer also reports that the address
and is inappropriate or unsafe for receiving mail, the Payment Card Helpline
COMMERCIAL IN CONFIDENCE Page 52 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
CC 2D should not reorder the PUN, but refer the caller to the BIA and also
advise the DSS by fax.
9.5.3 Card collection calls
The calls that may be received from customers about the collection of cards are as
follows:
Callref Description
CC 3A If a card is unavailable for collection on the presentation of a PUN, the
Payment Card Helpline should initially check the status of the card. If it
is still in transit to the post office, the Payment Card Helpline should
advise the customer to collect the card in the next day or so. Otherwise,
the Payment Card Helpline should cancel the original card and arrange
the issue of a new card and PUN, and also advise the customer to
destroy the original PUN since they will receive a new PUN shortly. If
the customer expresses concern at delay in being able to obtain
payments, they should referred to the BIA.
CC 3B If the card is not collected within the collection period and has become
invalid, the Payment Card Helpline should not reorder the card, but refer
the caller to the BIA. This circumstance is for the BIA office to
investigate and if suitably reassured, reorder the card via the Payment
Card Helpline.
CC 3F If the customer calls in advance to report genuine reasons for being
unable to collect a card within its collection period, the Payment Card
Helpline should offer to extend the new card's collection date. In this
case, the helpdesk advises the caller of the collection period and
amends the system.
If this is inappropriate to the caller and/or urgent payment is required,
the helpdesk should refer the caller to the BIA to arrange for benefit
collection by a relative or friend, that is, an agent).
CC 3G If the customer is unable to collect a card because the post office is
temporarily closed, the Payment Card Helpline should check the
recorded duration of the closure and advise the customer to return later.
If appropriate, the helpdesk should offer to extend the new card’s
collection date. In this case, the helpdesk advises the caller of the
collection period and amend the system.
If the customer expresses concern at delay in being able to obtain
payments, they should referred to the BIA.
If there is no record of the post office’s closure, the helpdesk should
subsequently inform the HSH.
9.5.4 Lost/stolen/damaged PUN calls
The calls that may be received from customers about lost, stolen or damaged PUNs
are as follows:
Callref Description
CC 4A If a PUN is reported as lost, stolen or damaged, the Payment Card
and Helpline should action the issue of another PUN and advise the caller
CC 4B they will receive a new PUN shortly.
In certain circumstances, for exampple, change of address pending,
COMMERCIAL IN CONFIDENCE Page 53 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
customer no longer of interest, three PUNs already issued, another
PUN should not be issued and the Payment Card Helpline should note
on the system why this exceptional course of action has been taken.
Customers should be referred to the BIA.
CC 4C If a PUN is reported as found, subsequent to its loss being reported, the
and Payment Card Helpline must advise the caller to destroy the PUN as a
cc 4D replacement PUN will have been issued.
9.5.5 Lost/stolen/damaged card calls
The calls that may be received from customers about lost, stolen or damaged cards
are as follows:
Callref Description
CC 5A If a card is reported as lost, stolen or damaged, the Payment Card
and Helpline should update the status of the card and, in most
CC 5B circumstances, arrange the issue of a replacement card and PUN. The
helpdesk advises the caller that their old card has been stopped and
that they will receive a new PUN shortly to allow them to collect a new
card.
In certain circumstances, for example, address unsafe, change of
address pending, customer no longer of interest, stop placed by DSS, a
replacement card and PUN will not be issued and the Payment Card
Helpline should note on the system why this exceptional course of
action has been taken. Customers are referred to the BIA.
CC 5C If a card is reported as found, subsequent to its loss being reported, the
and Payment Card Helpline should advise the caller to destroy the card
CC 5D since it is now invalid, and that they will receive a new PUN shortly to
allow collection of a new card.
CC SE If a customer calls back, subsequent to a previous call reporting a lost,
stolen or damaged card, and requests that the card reorder be delayed,
for example, because of an impending address change, the Payment
Card Helpline should reorder the card and advise the caller that they will
receive a new PUN shortly to allow them to collect a new card.
In certain circumstances, for example, address unsafe, change of
address pending, customer no longer of interest, stop placed by DSS, a
replacement card and PUN must not be issued and the Payment Card
Helpline should note on the system, why this exceptional course of
action has been taken. Customers are referred to the BIA.
9.5.6 Lost/stolen/damaged temporary token calls
The calls that may be received from customers about lost, stolen or damaged
temporary tokens are as follows:
Callref Description
CC 6A If a temporary token is reported as lost, stolen or damaged, the
and Payment Card Helpline check the status of the token and stop it. The
CC 6B __helpdesk advises the caller that the token has been stopped and that
they should return to the DSS for another.
CC 6C If a temporary token is reported as found, subsequent to its loss being
and reported, the Payment Card Helpline should advise the caller to destroy
CC 6D the token since it is now invalid, and that they should revisit the DSS
COMMERCIAL IN CONFIDENCE Page 54 of 104
ICL Pathway
POL00393875
POL00393875
ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
office for another.
9.5.7 Card change calls
The calls that may be received from customers about a change of card are as
follows:
Callref Description
CC 7A If there is a request to replace the current card with a bilingual card
(‘Welsh Card”) or vice versa, the Payment Card Helpline should check
that a caller requesting a bilingual card has a Welsh address and a
caller requesting an English card has an English address, and then
order a new card. The helpdesk should advise the caller that they will
receive a PUN shortly to allow them to collect the new card.
9.5.8 Complaint calls
The calls
follows:
that may be received from customers about service complaints are as
Call ref
Description
CC 8A
If service complaints are received regarding the Payment Card Helpline,
the helpdesk should log all details regarding the complaint and pass this
to the Helpdesk Manager. The helpdesk should advise the caller that
their comments have been noted and will be actioned as appropriate.
The Manager then takes any necessary corrective action.
CC 8B
If a call is received reporting a justifiable complaint regarding the
lateness or non-delivery of a PUN, the helpdesk should assess whether
the complaint is justifiable with regards to timescale and address
accuracy. If so, the helpdesk should log all details regarding the
complaint and pass this to the Helpdesk Manager. The helpdesk should
advise the caller that their comments have been noted and will be
actioned as appropriate.
The Manager then take any necessary corrective action.
CC 8C
If service complaints are received regarding cards, PUNs or temporary
tokens (where a PUN complaint is other than a justifiable complaint
regarding the lateness or non-delivery of a PUN), the helpdesk should
log all details regarding the complaint and pass this to the Helpdesk
Manager. The helpdesk should advise the caller that their comments.
have been noted and will be actioned as appropriate.
The Manager should then take any necessary corrective action.
9.5.9 Payment error calls
The calls that may be received from customers about payment errors are as follows:
Callref Description
CC 10A If the Payment Card Helpline receives a call claiming under/
overpayments, they will first check that the payment details on the
receipt are hand-written. If so, and if it is an underpayment within the
same cash account week as the original transaction or an overpayment
(whether or not within the same cash account week), they will advise the
caller to return to the post office. If it is an underpayment outside the
same cash account week, the Payment Card Helpline should record the
COMMERCIAL IN CONFIDENCE Page 55 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
details manually and advise the caller that the request will be
investigated and that if the request is valid that they will receive a
cheque normally within two weeks. The helpdesk should then raise an
incident at the HSH and fax details to the Pathway Business Support
Unit (see also call PO 4A).
If the receipt is not hand-written, the helpdesk should refer the caller to
the BIA.
(It is possible that these calls may be made as third party calls by the
DSS on behalf of the customer.)
9.5.10 Rollout only calls
The calls that may be received from customers about rollout are as follows:
Callref Description
CC 11A __ If the Payment Card Helpline receives a call about the location of an
appropriate post office for foreign encashment, the Payment Card
Helpline should advise that card encashment is available at all main
post offices. If the customer requires specific details then the Payment
Card Helpline should advise the caller to. contact the Post Office
Counters Ltd Helpdesk on} GRO
9.5.11 DSS customer inappropriate calls
9.6
9.6.1
The calls that may be received from customers that are inappropriate for the
Payment Card Helpline are as follows:
Callref Description
CCI 1to In the case of calls being received by the Payment Card Helpline which
ccl4 are not in the call matrix or requesting information that the Payment
Card Helpline may not provide, for example, a customer enquiring on
payment entitlements, or requesting change of personal details, the
caller should be informed that the call is inappropriate for the Helpline
and advise on an alternative course of action, where known.
Cccl5 If the Payment Card Helpline receives a request for a copy of the data
that is specific to the caller, the Payment Card Helpline should advise
the caller that requests should be submitted in writing to the DSS Data
Protection Registrar and provide the address.
Third party calls
The following subsections list the calls that may be received by the Payment Card
Helpline from third parties.
Third party valid calls
Valid calls that may be received from third parties that are as follows:
Callref Description
TPC 1 If a card is reported as found, the Payment Card Helpline should
request the card details (NINO and Issue Number), record the card as
found and stop it, and advise the caller to dispose of the card by cutting
it in half and destroying. The helpdesk should immediately order a
replacement card unless the customer is no longer of interest, or a stop
COMMERCIAL IN CONFIDENCE Page 56 of 104
ICL Pathway
POL00393875
POL00393875
ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
9.6.2
has been placed by the DSS.
TPC 2
If a PUN is reported as found, the Payment Card Helpline should
request the PUN details (NINO and date), record the PUN as found and
advise the caller to dispose of the PUN by cutting it in half and
destroying. The customer should not be contacted and a replacement
should not be reordered.
TPC 3
If a temporary token is reported as found, the Payment Card Helpline
should stop the record the token as found and stop it, and advise the
caller to destroy the token.
TPC4
If a “DSS customer valid call” is made on behalf of a customer by a third
party (who may or may not be a registered customer in their own right),
the Payment Card Helpline should apply caller verification applicable to
that customer, and then proceed as with a customer call. (Note, as with
all customer calls, the helpdesk does not disclose personal details.)
COMMERCIAL IN CONFIDENCE Page 57 of 104
ICL Pathway
POL00393875
POL00393875
ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
9.7
Third party inappropriate calls
The calls that may be received from third parties that are considered inappropriate
to the Payment Card Helpline are as follows:
Call ref
Description
TPI 14
In the event of a threat being received, the Payment Card Helpline
should initiate emergency call recording. The helpdesk should allow the
caller to complete their statement and, in the case of a bomb threat,
endeavour to continue the conversation with the caller to obtain the
fullest details. The helpdesk must immediately advise the Helpdesk
Manager who should assess the seriousness of the threat and take one
or more of the following actions:
¢ Contact the Police by dialling 999
¢ Contact the appropriate authority within ICL Pathway
¢ Contact the appropriate helpdesk within Post Office Counters Ltd or
DSS
The helpdesk should advise the caller that their comments have been
noted and will be actioned as appropriate.
TPI2
In the event of a nuisance call being received, the Payment Card
Helpline should terminate the call quickly. If the caller calls repeatedly,
the helpdesk operator should advise the supervisor who should then
assess the need to contact the Police.
TPI3
If a call is received imputing benefit fraud, the Payment Card Helpline
should refer the caller to the BIA. If a call is received imputing fraud at
the post office counter, the Payment Card Helpline should advise the
caller to phone the Post Office Counters Ltd Helpline.
TPI4
If the call is identified as for another helpdesk, then the Payment Card
Helpline operator should advise the phone number of the appropriate
helpdesk.
TPIS
If a call is received from the Press, the Payment Card Helpline should
advise the caller politely that the helpdesk is unable to answer
questions from the Press and advise the caller of the phone number of
the ICL Pathway Press Office.
COMMERCIAL IN CONFIDENCE Page 58 of 104
ICL Pathway
POL00393875
POL00393875
ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
10
Horizon System Helpdesk calls
The calls that may be received by the Payment Card Helpline from the HSH are as
follows:
Call ref
Description
HDC 1
If the HSH report the emergency (unplanned) closure of a post office,
the Payment Card Helpline should amend the post office record status
with the closure status, today’s date, any optional stated alternative post
office and optional comment such as forecast reopen date. The
helpdesk should advise the caller when the action is completed.
The Payment Card Helpline action causes a suspension of the foreign
encashment count.
HDC 2
If the HSH report the temporary (planned) closure of a post office and
designate an alternative post office, the Payment Card Helpline update
the post office record with the closure status, the closure date, the
mandatory alternative post office and optional comment such as
forecast reopen date. The helpdesk advise the caller when the action is
completed.
The Payment Card Helpline action causes the transfer of payments to
the alternative post office and card cancellation/reorder for any cards in
transit or uncollected at the closed post office. The alternative post
office becomes the nominated post office for the period of closure.
If the notification takes place on the first day of closure, the foreign
encashment count is suspended on that day until the overnight transfer
of nominated post office takes effect. If the forecast closure period is
less than a week, card reorder is inhibited.
HDC 3
If the HSH report the reopening of a post office following an emergency
or temporary closure, the Payment Card Helpline update the post office
record, to enter the reopen date and optional comment. The helpdesk
advise the caller when the action is completed.
COMMERCIAL IN CONFIDENCE Page 59 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
System Management Centre
The Systems Management Centre (SMC) is responsible for the overall management
of the end-to-end Pathway solution. It has the following key objectives
1. To monitor the system effectively, to ensure the effective running of the end-to-
end operational workflow, through pro-active monitoring of system events and
either directly, or through liaison with other suppliers, ensure appropriate action
is taken on all events.
1. To ensuring all calls, either voice or generated through above events are logged
in a call logging system and managed through to resolution
1. To monitor performance of all aspects of the end-to-end system and providing
recommendations for the optimisation of performance.
1. To provide a software distribution function to all specified target systems as
specified in Appendix 1 of the Pathway/Sorbus Service Agreement SBOO1.
1. To control the hardware and software asset information.
The SMC operates 24 hours per day 365 days per year and assumes the role of the
Horizon System Helpdesk outside of the Horizon System Helpdesk normal hours of
operation.
The structure of the organisation is as shown below.
Picture - TBA
10.1 Roles And Responsibilities
10.1.1 SMC Service Manager
10.1.1.1 Business Objectives
These are as defined in the DSD Pathway Programme Director Operations Manual
(Ref ICL\CFM\DSD\Path\OM\2.0)
10.1.1.2 Responsibilities
These are as defined in the DSD Pathway Programme Director Operations
Manual (Ref ICL\CFM\DSD\Path\OM\2.0)
10.1.2 SMC Technical Consultant (Tivoli)
10.1.2.1 Business Objectives
1. To aid in the development of the SMC Organisation and the individuals therein
to provide a managed solution to Pathway Systems Management.
COMMERCIAL IN CONFIDENCE Page 60 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
To assist in defining the service level targets for Systems Management with
regard to the Tivoli solution.
To aid in the development of the Tivoli product suite to ensure such service level
targets are consistently met or exceeded thereby fulfilling our contractual
obligations.
To mentor and coach the Technical Specialists to ensure that they are motivated
and empowered to enable them to achieve their full potential
To foster good working relationship with SMC staff, internal units, external
suppliers and customers
To champion the use of quality throughout the unit to stimulate growth,
achievement and pride in the team.
To foster commercial awareness and achieve profitability
RESPONSIBILITIES
To provide input into contingency measures to ensure that arrangements are in
place to provide users with system access in an emergency.
To ensure that Requests for Change impacting Tivoli or the areas managed by
the Tivoli are accurately costed and scheduled into the Tivoli/SMC work
Programme.
To accurately manage and record progress of RFCs through the SMG so that
Customer expectations, timescales and specifications are fully me’,,.
To attend meetit-,gs with 'Customers, Suppliers, arid peers as required, and
carry out appropriate action points.
To assist in the development of procedures to ensure that the integrity and
security of SMC supported systems are maintained.
To assist in the management of the Implementation of new software.
To ensure Tivoli related processes are followed and reviewed in line with audit
requirements.
To provide input into the IIP process for Pathway SMC Technical Specialists.
To facilitate the effective provision of fully supported management systems in
line with local instructions.
To advise of new developments in the Tivoli product suite for incorporation in the
Pathway solution.
To assist in the distribution of new versions of Tivoli software as required.
To diagnose and resolve Tivoli software incidents referred by the SMC, ensuring
the effective performance of SMC is maintained and system availability targets
are achieved and exceeded.
To provide the escalation point for complex Tivoli technical issues and skills
transfers to SMC Technical Specialists as required.
To accurately maintain records of all incidents affecting Tivoli, to include
resolution details and diagnostic information when required, providing updates to
Known Error Logs as appropriate.
To analyse incidents to identify trends and requirements for the enhancement of
the Tivoli product suite.
To escalate to the Service Manager any incident which may affect the security of
COMMERCIAL IN CONFIDENCE Page 61 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
SMC Systems. See Section 9.
. To assist in developing requirements for enhancements to the Tivoli product
suite required.
To assist in the development of utilities in line with existing development
procedures.
. Actas primary interface between SMC and SMG to ensure that tools provided
meet requirements and where requirements change, raise enhancement
requests on the SMG.
. Work closely with the SMC Technical Specialists to ensure a consistent
approach when interfacing with SMG.
10.1.3 SMC Manager
10.1.3.1
1.
1.
Business Objectives
To develop the SMC Organisation and the individuals therein.
To ensure that service level targets are consistently met or exceeded thereby
fulfilling our contractual obligations.
. To ensure that all team members are motivated and empowered to enable them
to achieve their full potential
. To foster good working relationships with internal units, external suppliers and
customers
. To champion the use of quality throughout the unit to stimulate growth,
achievement and pride in the team.
. To foster commercial awareness and achieve profitability
Responsibilities
. To oversee the effective provision of fully supported SMC services in
accordance with the contracted Service Contract and Service Descriptions
agreed with ICL Pathway.
. To monitor and follow up problems referred for resolution.
. To ensure that contingency arrangements are in place to provide users with
system access in an emergency.
. To ensure that Requests for Change impacting SMC or the areas managed by
the SMC are accurately costed and scheduled into the SMC work Programme.
. To accurately manage and record progress of RFCs through the SMC group so
that Customer expectations, timescales and specifications are fully met.
. To attend meetings with Customers, Suppliers, and peers as required, and ca,ry
out appropriate action points.
. To ensure that incidents logged outside working hours are fully supported by
fully staffed shifts - as per the Contract.
To apply procedures to ensure that the integrity and security of SMC supported
systems are maintained.
. To perform the role of the SMC Quality Representative, attending quality
meetings on behalf of SMC and ensuring all staff are aware of quality initiatives.
To manage SMC on a daily basis to achieve an acceptable and consistent
quantity and quality of work.
COMMERCIAL IN CONFIDENCE Page 62 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
1.
1.
1.
To manage the Implementation of new software.
To ensure processes are followed and reviewed in line with audit requirements.
To take ultimate IIP responsibility for all Pathway SMC staff.
10.1.4 SMC Team Leader
10.1.4.1
1.
10.1.4.2
Business Objectives
To ensure that service level targets are consistently met or exceeded thereby
fulfilling our contractual obligations.
To assist in creating and maintaining good working relationships with internal
units, external suppliers and customers
To take an active role in the self development process and maximise potential of
others.
To participate in and take shared responsibility for the day to day
implementation of quality within the unit.
To ensure that all team members are motivated and empowered to enable them
to achieve their full potential
Responsibilities
Ensure that incidents referred to the group are dealt with effectively and ina
timely manner to ensure resolution within the agreed SLA timescales.
To deal effectively with incidents escalated by SMC Technicians/SMC Technical
Specialists and ensure the Management are kept abreast of the progress of
major incidents to ensure resolution within SLA timescales and to escalate
issues to higher management where appropriate, following established
processes or Requests for Change.
Effectively manage the Change Request to ensure that they are impacted,
tested and implemented to agreed timescales laid down on the requests and
ensure that all involved parties are kept abreast of any issues.
Manage the Team to ensure full and effective implementation of relevant
software within Service Targets, rollout, or other agreed timescales.
Manage staff on a day to day basis to ensure that they are well motivated ano
given correct support to achieve a consistently high qual@ of work, aiming to
meet all targets.
To actively demonstrate a willingness to continually and objectively review
current working practices and procedures and make positive suggestions for any
changes.
Carry out adhoc tasks as requested by managers within timescales set and to
required standards.
Complete Performance Appraisal Reports on staff in a fair and considered
manner and within agreed timescales.
Meet the training and development needs of staff by ensuring that they receive
the required training outlined in their individual plans.
Effectively manage the staff both to ensure that key objectives are met and
ensure the personal development of all staff. Agree 'SMART' Objectives.
Ensure that staff have periodic reviews of their performance to keep them
informed of their progress and to review their personal objectives.
COMMERCIAL IN CONFIDENCE Page 63 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
. Work as a team with other Team Leaders to ensure a consistent approach to
staff management.
Ensure that SMC Handover Logs are maintained. (3.6 & 3.7)
Manage their Team to ensure optimum staff utilisation in terms of call length
management, individual workload, and achievement of required incident
clearance rates etc.
10.1.5 SMC Technical Specialist
10.1.5.1
1.
10.1.5.2
Business Objectives
To ensure that service level targets are consistently met or exceeded thereby
fulfilling our contractual obligations.
. To assist in creating and maintaining good working relationships with internal
units, external suppliers and customers
. To take an active role in the self development process and maximise technical
potential of others.
. To participate in and take shared responsibility for the day to day
implementation of quality within the unit.
Responsibilities
. To facilitate the effective provision of fully supported management systems in
line with local instructions.
. To provide software implementations and upgrades to the managed estate,
following Change Control, testing and regression procedures as appropriate. To
assist in the distribution of new versions of software as required.
. To diagnose and resolve software and network incidents referred to the SMC,
ensuring the effective performance of SMC is maintained and system availability
targets are achieved and exceeded.
. To provide the escalation point for complex technical issues and skills transfers
to colleagues as required.
. To accurately maintain records of all incidents affecting SMC, to include
resolution details and diagnostic information when required, updating Known
Error Logs as appropriate.
. To analyse incidents to identify trends and refer hardware , software and
network problems to the appropriate domains for resolution.
To escalate to the Manager or Team Leader any incident which may affect the
security of SMC Systems. See Section 9.
. To assist in the distribution of new Versions of software as required.
. To develop utilities in line with existing development procedures.
Liaise with the SMG to ensure that tools provided meet requirements and where
requirements change, raise enhancement requests on the SMG.
. Work as a team with other Technical Specialists to ensure a consistent
approach when interfacing with SMG as per 2.5.2. 1 0 above.
COMMERCIAL IN CONFIDENCE Page 64 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
10.1.6 SMC Technician
10.1.6.1
1.
Business Objectives
To ensure that service level targets are consistently met or exceeded thereby
fulfilling our contractual obligations.
. To assist in creating and maintaining good working relationships with internal
units, external suppliers and customers
To take an active role in the self development process.
To participate in and take shared responsibility for the day to day
implementation of quality within the unit.
RESPONSIBILITIES
To diagnose and resolve hardware, software and network incidents referred to
SMC ensuring the effective performance of SMC is maintained and system
availability targets are achieved and exceeded.
To accurately maintain records of all incidents affecting SMC, to include
resolution details and diagnostic information when required.
. To analyse incidents to identify trends and refer hardware and software
problems to the appropriate domains for resolution.
To escalate to the Manager or Team Leader any incident which may affect the
security of SMC Systems.
To assist in the distribution of new versions of software.
. To develop utilities in line with existing development procedures.
10.2 Review Mechanisms - Internal
10.2.1 Meetings
1.
1.
Minutes of reviews will conform to the standard as described in para. 10.2.4. The
minutes of review mechanisms are distributed to interested parties and a copy
filed in the SMC library.
. The SMC manager defines, plans and carries out reviews within the SMC
section, the records of which demonstrates that Key Business Objectives are
being adhered to.
The regular group meetings are indicated as follows:
10.2.2 SMC Meeting
Attended by: SMC Manager/SMC Technical Team Leaders and nominated
Technical Specialists and Technicians
Frequency: Monthly
Purpose: This acts as a forum disseminating information and group
discussion.
Agenda: 1. Introductions and Apologies
2. Actions from Previous Meetings
3. Quality and Non Conformance
4. Operational Issues
5. Performance against Targets
COMMERCIAL IN CONFIDENCE Page 65 of 104
ICL Pathway ICL Pathway Customer Service: Customer
Service Operations Manual
Ref:
Version:
Date:
POL00393875
POL00393875
CS/MAN/004
0.2
29/06/98
Staffing Issues
Project Updates
Customer Care
. AOB
0. Next Meeting
SeEPND
10.2.3 Other Meetings
The type and frequency of other meetings has yet to be determined. Details of such
meetings when known will be included in the following format.
Attended byi TBA
Frequency: TBA
Purpose: TBA.
Agenda: 1. Introductions and Apologies
2. Actions from previous meetings
3. Issues
4. AOB
5. Next Meeting
10.2.4 Example Meeting Minutes
Date: 04 January 1997
Time: 09:00 Hours
Location STEO9
Subject:
Meeting Number:
Attendees:
Distribution:
Agenda: 01-
02 -
03 -
04 -
Distribution:
COMMERCIAL IN CONFIDENCE
Page 66 of 104
ICL Pathway ICL Pathway Customer Service: Customer
Service Operations Manual
POL00393875
POL00393875
Ref: CS/MAN/004
Version: 0.2
Date: 29/06/98
Attendees plus......
Action Mn/Ag/in
1.1.3. Closure Text
1.2.5 Progress Report
2.2.1 New Item Text
Mn=Meeting Number
Ag=Agenda Item
In=Item Number
10.2.5 Reports
Action Notes
ANO
ANO
ANO
Actionee Status
Closed
Ongoing
3.5.1 SMC section reports produced on a regular basis are indicated as follows:
3.5.2 Copies of all Reports to located in the local SMC library.
10.2.6 SMC Support Handover Log
Recipient: SMC Shift members
Frequency-. Daily
Function: Summary of support activities undertaken by the previous
shift. T assist in the smooth transfer of responsibilities
between shifts an ensure all current support issues are dealt
with in a co-ordinate manner.
Format: TBA
10.2.7 SMC Handover Log
Recipient: Horizon System Helpdesk Manager/SMC Technical Team
Leader
Frequency: Daily
COMMERCIAL IN CONFIDENCE
Page 67 of 104
ICL Pathway
POL00393875
POL00393875
ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version:
0.2
Date: 29/06/98
Function:
Format:
Summary of still open PowerHelp calls and other current
activities being handled by the SMC in their capacity as the
out of normal hours Horizon System Helpdesk. To assist in
the smooth transfer of responsibilities back to the Horizon
System Helpdesk from the SMC acting in their capacity as
the out of normal hours Horizon System Helpdesk
TBA
10.2.8 SMC Statistics Report
Recipient:
Frequency:
Function:
Format:
TBA
TBA
TBA
As detailed in SMC LWI (Reference: TBA)
10.2.9 SMC Management Report
10.2.10
Recipient:
Frequency:
Function:
Fo,@ m,:a,"
SMC SERVICE MANAGER
Monthly
Summary of the Performance of the unit over the last
reporting period.
Reports sl-iould follow the format as indicated at Appendix 1
of this manual.
SMC Summary Progress Report
Recipient:
Frequency’.
Function
Format:
SMC MANAGER
Monthly
This report pulls together the salient points from the SMC.
Individual Progress reports and generates a list of action
points to be completed.
As indicated in Appendix 1 of this manual
COMMERCIAL IN CONFIDENCE Page 68 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
10.2.11 SMC Individual Progress Report
10.3
10.4
10.5
10.6
Recipient: SMC TEAM LEADER
Frequency: Monthly
Function: Summary provided by each SMC Team member detailing
work undertaken in the previous reporting period, progress
on objecbves, issues requiring further action
Format: As indicated in Appendix 1 of this manual
Customer Acceptance Criteria
See SMC Customer Acceptance Criteria (Ref:SM\ACC\001)
Customer Complaints
1. All customer complaints must be notified to the SMC Manager within three hours
of receipt and a written report produced, if necessary, within one day. This
report should, if produced, be copied to the SMC Service Manager.
1. In the absence of the SMC Manager e.g. out of normal hours, customer
complaints must be notified to the relevant Team Leader for immediate action.
1. The SMC Manager and SMC Service Manager must be notified of all formal
customer complaints on the day they are made or, if out of normal office hours,
the first working day afterwards.
1. Further actions to be taken in respect of customer complaints are as indicated in
the ICL CFM DSD Pathway Operations Manual (Ref:
ICL\CFM\DSD\Path\OM\2.0)
Recognition
1. The SMC will fully support the recognition scheme described in Section 8 of the
DSD Operations Manual (Ref: ICLS\DSD\O™) .
1. Local Records of nominations for Excellence Awards will be maintained in
personnel sub files by the SMC Manager.
1. "Thank You" letters and other plaudits from customers etc. will be filed locally,
and copies both included in personnel sub files as appropriate and passed to
the individual(s) subject of the plaudit.
1. Copies of the excellence nomination forms are held by the SMC Manager for
use by any staff wishing to make a nomination, together with guidance'on their
completion.
Skills
The SMC Manager will ensure that skill level charts for SMC staff are created and
maintained:
1. to demonstrate that the type of services which are on offer to customers can be
provided from more then one source
COMMERCIAL IN CONFIDENCE Page 69 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
1.
to enable training and development plans for both individuals and the unit to be
optimised
10.7 Skills Grade Criteria
Grade 0 Not applicable.
Grade 1 Training but still consolidating training.
Grade 2 At least 6 months application of skill
Grade 3 12 Months or more application of skill.
Example of a skills chart for SMC is included as Appendix 2 of this Operations
Manual
10.8 Contingency, Security And Risk
10.8.1 Contingency Plans
See SMC Contingency Plan (Ref:SM\CGY\001)
10.8.2 Security And Risk Analysis Plans
See SMC Security and Risk Analysis Plan (Ref:SM\S&R\001)
10.9 Escalation
See SMC Escalation Management (Ref- SM\ESC\001)
10.10 Training Plan
1.
TheSMCManagerwillensurethatatrainingplaniscreatedandmaintained for each
individual member of SMC staff.
The plan will support the requirements of the SMC and underpin the findings of
the skills register.
. All training requirements will be registered with the SMC Manager who will also
create electronic records of training booked and completed.
. The provisional training plans will be held in the Staff Appraisal folders held by
the SMC Manager.
10.11Audit Reports And Corrective Actions
1.
The Pathway Services Division Quality Manager schedules all Internal Audits
within the Division. Responsibilities of the Internal Audit processes are defined
by the Quality Manager.
. The responsibilities detailed in the Quality Systems Audit Process [Ref
Path\QM\Ol] will be fully supported by the SMC.
Corrective actions will be assessed and planned within the Systems
Management Centre review mechanisms (See Section 3).
COMMERCIAL IN CONFIDENCE Page 70 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
1. Non conformance as a result of internal or external audits will be reviewed until
closure in the SMC Meeting under the Quality agenda heading.
1. Master copies of Audit Reports and Corrective Action Plans appertaining to the
SMC will be filed in folders held in the Pathway Services Division Central Library
FELO1. An additional reference (not under document control) copy will also be
lodged in the local Horizon System Helpdesk/SMC documentation facility.
10.12 Staff Appraisals
10.12.1 SMC Manager's Responsibilities
The SMC Manager will prepare an appraisal plan for SMC members together with a
scheduled appraisal review date.
Records of appraisal completion will be maintained by the SMC Manager and copies
forwarded to the Personnel Group for central filing.
Each individuals completed appraisal will be held in their Staff Appraisal File held by
the SMC Manager. A copy will also be given to the individual subject of the
appraisal
10.13 Documentation
10.13.1 Key Documents
1. The SMC Manager is responsible for ensuring that the latest versions of all
controlled documents are available at the points of need and that the obsolete
versions are withdrawn.
1. Copies of all SMC key documents are held in the Horizon System
1. Helpdesk\SMC local documentation facility. Copies will also be lodged with the
PSD Central Library FELO1.
1. SMC Controlled Documents from other Pathway Project Service Providers Index
1. The master copy of all controlled documents from other Pathway Project
1. Service Providers relating to the SMC will be held in the Pathway Services
Division Central Library FELO1. Any additional copies required for local use will
be kept in the local Horizon System Helpdesk/SMC documentation facility.
10.13.2 ICL CFM Pathway Services Division Operations Manual
The master reference copy of the Pathway Services Division Operations Manual
(Ref: ICL\CFM\DSD\Path\OM\2.0) will be held in the Pathway Services Division
Central Library FELO1. A local reference copy will be held in the Horizon System
Helpdesk/SMC Documentation facility at each Horizon System Helpdesk/SMC site
and will be marked as follows:
REFERENCE COPY ONLY-NOT UNDER CHANGE CONTROL, and dated.
The copy should not he retained beyond 6 months of dating.
10.13.3 SMC Binder Library
1. The SMC Binder library (physically held within the Horizon System
Helpdesk/SMC documentation facility) consists of all the SMC Quality
Documentation (Operations Manual(s), Work Instructions, and other additional
COMMERCIAL IN CONFIDENCE Page 71 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
internal and external reference documentation) required for local access.
1. Binders must not be removed from the SMC and must remain available to all unit
members.
11
COMMERCIAL IN CONFIDENCE Page 72 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
12
Card and PUN production
De La Rue Card Systems (DLR) provide a card and PUN production service for ICL
Pathway.
A card request is received by the CMS database from CAPs and is routed into DLR.
A card request batch which is sent to DLR contains the cardholder details in a card
file and also a PUN file which contains details to activate the card. Cards are
produced and despatched to a customer's nominated post office. PUNs are
produced only after the associated card has left the DLR premises and are
despatched directly to a customer's home address.
The interface between CMS and DLR is defined in the DLR High Level Design
document (SU/DES/0006 v3.0).
<information needed>
COMMERCIAL IN CONFIDENCE Page 73 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
Rollout: Cards/PUNS and Temporary Tokens
<information needed>
13
COMMERCIAL IN CONFIDENCE Page 74 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
POCL Card Receipt Service
<information needed>
14
COMMERCIAL IN CONFIDENCE Page 75 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
Operational Business Change
ICL Pathway provides services to implement standard changes, as defined in the
contractual change service matrix. Standard changes are those that can be
identified and prepared for in advance, and that do not require software code
changes. Many of these changes are supported by changes to reference data.
Standard changes are either related to POCL Outlets, for example, relocating an
office, or to the Products sold at POCL Outlets, for example, changing the price of
stamps.
14.1 Operational Business Change - Outlets
A Change Proposal/Request is raised to include the change service matrix as a
contractual document, together with the mechanism for using these processes to by-
pass the Change Request process for standard steady state changes.
The volume of change covered by the contract is declared in the Authorities
Schedule A06 [8]. Thereafter, all outlet changes are chargeable.
14.1.1 Change types
Outlet changes are categorised into the following types.
14.1.1.1 Delayed opening
Closed for less than one day and Pathway are not informed.
Note: The postmaster MUST complete the End of Day procedures.
14.1.1.2 Emergency closure
Minimal notice is given of closure and it can only be temporary arrangement.
The closure may last from less than one day, up to the point that an alternative
Nominated Post Office is available or the office re-opens or permanently closes.
14.1.1.3 Simple re-opening
It only applies following an emergency closure when no site visit or data change is
needed before re-opening.
14.1.1.4 Standard closure
All non-emergency closures. Notice is given. All permanent closures are standard.
14.1.1.5 Refurbishment (same counter configuration)
Office closes, Pathway remove & relocate same equipment.
14.1.1.6 Open/Relocation/ Refurbishment (new counter configuration)
Re-opening where site visit (including refurbishment) or data change required.
New opening.
Relocation: move equipment etc from one site to another, with same FAD code.
14.1.1.7 Office Details
Details about the office change and Pathway need notice to implement the change
successfully (not FAD code).
COMMERCIAL IN CONFIDENCE Page 76 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
14.1.1.8 Planned Outlet Reference Data
Data that supports changes to the information about the PO retail network.
14.1.1.9 Outlet data only
Data that supports changes to the information about the PO retail network and does
not impact Pathway, can be implemented with no manual intervention by Pathway.
14.1.2 Card & payment management
Emergency and standard closures, refurbishment and relocation all require
processes for managing benefit cards and payments during outlet closures. The
closure types are as follows.
14.1.2.1 Temporary closures:
1. Short term Any duration when there is no alternative
NPO notified to Pathway
2. Medium Term Requires 1 days notice & expected for a
- no card re-issue closure of at least 3 days
3. Medium Term Requires 3 days notice & expected for a
- with card re-issue closure of 7 days or more.
14.1.2.2 Permanent closures require 2 weeks notice.
The result of a permanent closure is the permanent transfer of all beneficiaries from
the closing office to the alternative one and the removal of all equipment from site. If
a temporary closure lasts for a significant period of time, POCL may initiate
permanent closure procedures, or a subset of those procedures, for example,
transfer the beneficiaries and remove the counter terminal but do not remove the
ISDN connection.
These timescales are not restrictive, the availability of other information, for
example, alternative NPO is the defining factor. The times are indicative and POCL
may select whichever closure type is appropriate and in line with their agreement
with DSS. Pathway will implement the change as requested. (see ref 5 for further
details of payment methods during office closure).
14.1.3
COMMERCIAL IN CONFIDENCE Page 77 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
Top Level Processes - Outlet
The table below gives the top level view of the processes for outlet change. The
four elements of each change are as follows::
1. Management
1. Notification
1. Implementation
1. Acceptance.
The services that make up each element are given, for the different change types.
The last column gives the assumptions that have been made during the creation of
these processes. Pathway can manage changes that do not meet these
assumptions as exceptions to the process. They are managed by the OBC Service
Manager as part of the service so-ordination task and may require different notice
periods.
COMMERCIAL IN CONFIDENCE Page 78 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
[ Management ] Assumptions:
vy (NB deviation from these assumptions
[E_ Notification} [Implementation _]}-p{_Acceptance_] I will be managed through the
Senice Co-ordination activity)
Emergency Closures — Helpdesk call Senice co-ordination Call closure * CANs and Authenticated helpdesk calls
Card & Payment mgt remove the need for explicit purchase orders
Equipment change
* Pathway are not notified of closures
& Simple Re-opening — Helpdesk call Senice co-ordination Call closure _—_I lasting < 1 day
Card & Payment mgt
* Pathway are told of closures and openings
Standard Closures Change Advice Form © Senvice co-ordination Sign off immediately, therefore, do not monitor closures
Card & Payment mgt
Equipment change * Estimates are based on offices
Infrastructure change having 2 counter positions
Ref Data management
* All offices are closed during
Refurbishment Change Advice Form — Service co-ordination Sign off refurbishment
= no change in Card & Payment mgt
counter configuration Infrastructure change * Adayis 8hrs of a working day
Equipment change
* POCL provide a compliant counter
Open Relocation Qhange Advise Form Senvice co-ordination Sign off where possible - including provision of
JRefurbishment Card & Payment mgt electical circuitry
- for change in Infrastructure change
counter configuration Equipment change * Only Pathway equipment is moved -
Ref Data management e.g. not scales, APPU or fixtures & fittings
Training
Office details Change Advise Form = Service co-ordination Acceptance * tba
Ref Data management
Details Change
Planned Outlet Qhange Advise Form Senice co-ordination Acceptance
Reference Data Transfer data Release to live
Change Control
Error management
Outlet Data only Transfer data Release to live
Change Control
14.1.4
COMMERCIAL IN CONFIDENCE Page 79 of 104
ICL Pathway
POL00393875
POL00393875
ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
Change Advice Note (CAN) details
The Change Advice Note from POCL to ICL Pathway that requests the
implementation of change should contain the following information. If the
information is not provided in the CAN, the assumptions made will be given in the
CAN Response Form (ICL Pathway’s acceptance of the request for change).
All
Closures
For all
site visits
- opening
only
Data
14.1.5
FAD
Reason for change
Contact name & numbers / addresses
Due date & time of completion
Automated office
Authorised signature
Duration
Payment instructions e.g. short term Suspend FE or medium
term
Alternative NPO & card re-order (medium term)
Security of equipment / Equipment removal
Confirmation of cards’ status i.e. secured, destroyed, transferred
PO Name
PO Address
Outlet phone number
Number of counters
Date and Time of access to site
New PO Name
New PO Address
New PO phone number
Staff to be trained
ISDN line install/move/removal
Configuration changes
Unique CAN Number (to be copied onto ref data file)
Contact details for data queries
Data start date
COMMERCIAL IN CONFIDENCE Page 80 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
14.1.6
Release 1c
These processes supersede the release 1c processes for outlet change [ref 7].
However the following points must be noted:
1. There is no medium term temporary closure process for card & payment
management at Release 1c.
1. Pathway can only install equipment for new openings or relocations if there is a
compliant counter, at Release 1c.
1. Reference data is sent manually from POCL to Pathway at Release 1c, only for
details about those offices involved in Release 1c, and is updated manually by
Pathway.
COMMERCIAL IN CONFIDENCE Page 81 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
Second Level Processes - Outlet
14.1.6.1 Emergency Outlet closure & simple re-opening processes
Note: It is assumed that POCL to not amend Reference Data with details of
emergency closures.
Emergency closure
Process Diagram
[Notification } p[Senice Co-ordination]
Process Step Actors Activities
PocL, Inform beneficiaries of actions to be taken
PoC Inform Atemative Post Office about closure & expected increase in business volumes
PoC Notifiy DSS of emergency closure
Dss Prepare regional offices for increase in workload
POOL RHL call HSH to inform Pathway of emergency closure & its duration
(NB all other callers reporting closures are directed to the RHL)
HSH Carry out caller authentication [method tba see ref 2]
HSH Raise Powerhelp call, confirm POCL contacts & give RHL call reference number
(HSH If office is non-automated, notify Rollout of closure)
RHL Phone HSH weekly with status report, if duration of closure is not initially known
(NB closure status may go from short term to medium term)
RHL If medium term, provide Alternative NPO and state whether cards should be re-ordered
RHL Confirm PM has secured benefit, PMMC cards & PIN at office until re-opening
RHL Confirm security of Horizon equipment with HSH, or request its removal
RHL Confirm access times if equipment removal required
HSH Arrange for engineer to visit site, if equipment is at risk
HSH Inform PCHL of short term/ medium term emergency closure & details
HSH Cancel other, pre-arranged visits to site, if necessary
HSH Notify SMC
SMC Disable counters {method tha]
TBA Manage notification of TPS, APS, MIS [method tba]
HSH Escalate, if necessary [see ref 9]
HSH Report number & type of incidents to CS OBC [method tha]
CSCBC — Manage commercial aspects of closures
(short term) PCHL Suspend Foreign Encashment count
(medium term) PCHL Re-direct payments to Alternative NPO & re-order cards if requested (not RPOls)
(if'a card re-order has been requested, the unissued cards in the original NPO will be stopped by PCHL)
(both) POCL PM/RNM secure un-issued benefit cards until office re-opens
RML Secure undelivered cards until collected, or return to PCHL after 14 days
PCHL If cards are returned by RML, [JWto confirm action]
HSHIPCHL Direct all office opening queries to POCL Helpline
HSH/PCHL Direct all customer payment queries to DSS (e.g. for RPOls)
cont/...
COMMERCIAL IN CONFIDENCE Page 82 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
cont/....
(if equipment is at risk) POOL PW RNM complete system shutdown [method tba] & secure AVIMC card & FIN
UKSS Following system shutdown: remove Pathway equipment
USS Obtain AM sign off on engineer site visit form
UKSS Conduct basic check/clean & secure equipment for re-installation
UKSS Manage inventory changes of Pathway equipment
UKSS Notify HSH that the job is complete
HSH Confirm all actions complete & clase call
(NB If this dosure becomes permanent, POOLwill invoke the Standard Closure Process)
Simple re-opening
(NB this can only follow an emergency closure and if no site visit is required )
Poo. Inform beneficiaries of re-opening
Poo. Inform Aitemative NFOof re-opening
Pool Inform DSS temporarily closed office has re-opened
Pool RH call HSH provide HSH call ref number & request re-opening activities
HSH Cany out caller authentication [method tba see ref 2]
(HH If office is non-automated, raise call & notify Rollout)
HSH Ctherwise, confirm no site visit is required (else, invoke Standard Qnening Process) & raise call
HSH Inform POHL of re-opening
HSH Notify SVC
SVC Run s/w catch up and prepare system for use & confirm with HSH
TBA Manage notification of TPS, APS, MIS [method tba]
HSH Excalate, if necessary [see ref 9]
HSH Report number & type of incidents [method tba]
Card & Payment Mgt
(short term) POHL Unsuspend FE count (there is one-day's grace for beneficiaries who do not know the office has re-opened)
(medium term) POHL Re-direct payments back to orignal NPOand re-order cards if required
(if card re-order has been requested, the unissued cardsin the Atemative NFOwill be stopped by FOHL)
Pool FWRNM collect undelivered benefit cards (if less than 14 days) for issue as normal
Pool Direct all customer payment queries to DSS.
DSS Call POHL to issue new cards when required
HSH Confirm all activities are complete & dose call
14.1.6.2
COMMERCIAL IN CONFIDENCE Page 83 of 104
ICL Pathway
POL00393875
POL00393875
ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
Standard Outlet closure process
Standard closure
(includes permanent closure)
Process Diagra
_Gxrd & Payment mat
« Equipment change
[Retification p[Senice Co-ordination]
“"Refibata management
Process Step Actor Activities
Poo. Inform beneficiaries of actions to be taken
Poo. Inform Atemative Post Office about closure 8 expected increase in business volumes
Poo. Inform DSS of temporary closures
Dss Prepare regional offices for increase in workload
Poo. POOL Authoriser sends Pathway a Change Advice Note (CAN)
cscec Impact change & send CAN Response form detailing Pathway services & assumptions
CSCC thet chaneps
csc Ensure all patties are aware of closure [method tba]
(PCHL, HSH, UKSS, SMC, SSC, CFM Networks, CFM N.I., CSRD and Rollout)
Poo. FH_to contact HSHif agreed time of visit to be changed [tba]
cscec Manage delivery of change, including variations to standard services
TBA Manage notification of APS [method tba}
csasc Escalate, if necessary [sce ref 9]
cscec Report number & type of changes for invoicing [method tha]
cscec Manage update of Dispatch Che, Auto config tool, ‘Live Notification Report’ & Active Outlets Table
(Card & Payment Mgt
(temporary closure):
- (short term) POL Suspend Foreign Encashment count
= (medium term) PCH Re-direct payments to Atemative NPO& re-order cards if requested
(ifa card re-order has been requested, the unissued cards inthe orignal NROwil be stopped by POH.)
- (both) Poo. FWRNM secure un-issued benefit cards until office re-opens
RML Secure undelivered cards until collected, or retum to PCHL after 14 days
POL If cards are retumed by RML, [WVto confirm action]
HSHPCHL Direct all office opening queries to POOL Helpline
HSHPCH. —_Direct all customer payment queries to DSS
(permanent / long term closures *)
* requires 2 weeks notioe
(NB may have started as temporary closure)
‘Send closure & altemative office details to DSS CAPS
Update payment records & send to PAS/CMS
Update beneficiary records & to order new cards & payments for At NFO
Update POHL & DLR
FIW/RNM destroy old benefit cards from permanently closed office
cont/...
COMMERCIAL IN CONFIDENCE Page 84 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
cont/...
Gite visit required)
Pook
HSH
UKSS
UKSS
- (temp closure only) POOL
(permanent only) UKSS (tha)
UKSS
= (both) uss
(reson Craree_] rower
Ref Data Management™
* for futher details see ref data change processes.
(temp & perm closures) POOL
Dss
scx
CSRORV
ccc
FAWRNM to complete system shutdown [method tba]
‘Schedule engneer to site, if permanent closure or kit at risk during temp dosure
Remove Pathway equipment, once shutdown is complete (i.e. not scales/AFPU etc)
Manage inventory changes of Pathway equipement
AWRNM secure AVIMC card & PIN
Conduct basic clean/check & secure equipment waiting for re-installation
Disable counters [method tba]
Retain RVIMC cards, or instruct postmaster to send them to Pathway FREEPOST address
Remove re-useable LAN components
Retum equipment for rework/refurbishment [method tha}
Manage cessation of ISDN
Manage system and data purging [method tba]
Chtain RWRNM sign off on engneer site visit form
Notify HSH when job is complete, to clase call
Escalate, if necessaryIsee ref 9]
Manage removal of Pathway electric circuitry & other fittings (permanent closure only)
ROP send closure details to Pathway, via PODL Authoriser (with CAN Number)
Raise Ref Data Release Note
Manage update of data in RDMC & feeds to MIS & counters
Escalate, as necessary [see ref 9]
ROP send closure data to DSS CAPS:
Send closure details to Pathway to update PAS'OVIS
Confirms POOL have signed off enginee’s site visit form
Ref Data Release Manager signs off Ref Data Release Note
Manages subrrission of ‘invoice! for call-off against blanket purchase order (method tla)
14.1.6.3
COMMERCIAL IN CONFIDENCE Page 85 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version; 0.2
Date: 29/06/98
Outlet Refurbishment process (same counter configuration)
Refurbishment
(no change in counter configuration - assumes office closure)
Process Diagram Card & Payment mat
[Netiication I} ence Oo-ordination
Infrastructure change
Process Step Actor Activities
Poo. Inform beneficiaries of actions to be taken
Poo. Inform Atemative Post Cifice of closure! re-opening during refurbishments & relocations
Poo Inform DSS of closure’ re-opening during refurbishments & relocations
Dss Prepare regonal offices for temporary increase in workload
Poo. FOOL Authoriser sends Pathway CS a Change Achice Note
cscec Impact change & send CAN Response form detailing Pathway senices & assumptions
CSCBO these Changes
cscec Ensure all parties are aware of closure (method tha)
(PCH, HSH UKSS, WIL, SMC, SSC, CFM Networks, CFM N.L., CSRD and Rollout)
Poo. RH_ to contact HSH if agreed time of visit to be changed (tha)
csc Manage delivery of change, including variations to standard senices
suc Disable counters during temporary closure (rrethod tha)
TRA Manage notification of TPS, APS, MIS (method tha)
csaec Escalate, if necessary (see CS/FRD021)
cscec Report number & type of changes for invoicing (method tba)
[Card & Payment Mgt
Temporary dosure
~ (hort term) POL ‘Suspend Foreign Encashment count
~ (medium tem) POL Re-direct payments to Atemative NPO& re-order cards if requested
(if card re-order has been requested, the unissued cards in the orignal NFOwill be stopped by PCH.)
- (both) Poo. FIWRNM secure un-issued benefit cards until office re-opens
ML ‘Secure undelivered cards until collected, or retum to POHL after 14 days
POL If cards are retumed by RML, [to confirm action}
HSHPCH. —_Direct all office opening queries to POOL Helpline
HSHPCH. —_Direct all customer payment queries to DSS
Re-opening
- (short term) POHL Unsuspend FE count (there is one-day's gace for beneficiaries who do not know the office has re-opened)
~ (medium tem) POL Re-direct payments back to orignal NFO and re-order cards if required
(if a card re-order has been requested, the unissued cards in the Atemative NFOwill be stopped by POH.)
~ (both) Poo. FWRNM collect undelivered benefit cards (if less than 14 days) for issue as normal
Poo. Direct all customer payment queries to DSS
Dss Call PCH. to issue new cards when required
cont...
COMMERCIAL IN CONFIDENCE Page 86 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
cont/...
Infrastructure Change Poo. Provide compliant counter
Refubisher Conduct survey & provide basic modifications for compliant counter
cscec if non-compliant counter, manage re-suney and quote [CP required]
Refubisher Maintain site survey plans [method tba]
[Equipment change
(Closure) HSH Raise call & schedule engneer to site
Poo. FWRNM to complete system shutdown [method tba] & secure AVIMC card & PIN
uss Gree shutdown complete, remove Pathway equipment, including LAN components if required
uss Conduct basic check/clean & secure equipment waiting for re-installation
CFM Networks Manage changes to ISDN, as required
uss Manage Pathway inventory changes, as required
(opening) Poo Confirm site is ready for re-installation (method tba)
uss Install equipment & LAN components
uss Request (\ia HSH) SMC to prepare counter software
svic Run urgent s/w catch up and prepare system for use
sic Confirm system is ready for use
Poo. ‘Swipe PVIMC card with FIN, under engineer instruction
uss ‘Test reinstallation
uss Gbtain FWRNM sign off on engineer site visit form & inform HSH install complete
HSH Inform PCH. of re-opening
HSH Escalate, as necessary [sce ref 9]
HSH Confirm all opening actions are complete & close call
sic Run non-urgent sw catch up
HSH Confirm POOL have signed off engineer's site \isit form to CS CBC [method tha]
csc Manages subrrission of ‘invoice! for call-off against blanket purchase order [method tha}
14.1.6.4
COMMERCIAL IN CONFIDENCE Page 87 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
i i Version: 0.2
Service Operations Manual Date. 29/06/98
Outlet Open/ Relocation / Refurbishment processes
Open/Relocation:/Refurbishment*
* (if FAD code changes, relocation is standard closure & new opening)
* (when refurbishment requires change in counter configuration - assumes office closes)
Process Diagram
(Seniee Goorimaten I
\
a
Process Step Actor Activities
Pook Inform beneficiaries of actions to be taken during closure/ re-opening
PocL, Inform Altemative Post Office of closure/ re-opening during refurbishments
PocL, Inform DSS of closure/ re-opening during refurbishments
Dss Notify regional offices of temporary increase in workload during closures
Pock POCL Authoriser sends Pathway CS a Change Advice Note
cs oBC impact change & send CAN Response form detailing Pathway services & assumptions
cs OBC Schedule Changes
cs cac Ensure all parties are aware of closure & co-ordinate tasks [methos tba]
(PCHL, HSH, UKSS, WTL, SMC, SSC, CFM Networks, CFM N.1., CSRD and Rollout)
Pocl, RHL to contact HSH if agreed time of visit to be changes [tba]
cs OBC Manage delivery of change, including variations to standard services
cs oBc Co-ordinate card & payment and ref data management tasks with the physical opening
(ifoffice not ready fo open on expected date, temporary closure card & payment processes should be initiated)
cs cBc Identify whether Relocation moves outlet from ‘Local’ to Remote’ categorisation
TBA f change of category, amend look-up table in MIS system.
TBA Manage notification of TPS [method tba]
cs 0BC Escalate, if necessary [see ref 9]
cS OBC Report number & type of changes for invoicing {methos tba]
TBA Confirm ISDN availability at new site
cs cac Manage update of Dispatch One, Auto config tool, ‘Live Notification Report’ & Active Outlets Table
[Card & Payment M:
Relocation Poct PM/RNM securely transfer benefit cards to new office
(if neither the old nor the new office is open during relocation, temporary closure is intiated - see refurbishment)
Closure during refurbishment
- (short term) PCHL Suspend Foreign Encashment count
= (medium term) PCHL Re-direct payments to Altemative NPO & re-order cards if requested
(if card re-order has been requested, the unissued cards in the original NPO willbe stopped by PCHL)
= (both) PocL, PM/RNM secure un-issued benefit cards until office re-opens
RML Secure undelivered cards until collected, or retum to PCHL after 14 days
PCHL If cards are returned by RML, [JW to confirm action}
HSH/PCHL —_Direct all office opening queries to POCL Helpline
HSH/PCHL —_Direct all customer payment queries to DSS
Re-opening after closure for refurbishment
- (short term) PCHL Unsuspend FE count (there is one-day's grace for beneficiaries who do not know the office has re-opened)
- (medium term) PCHL Re-direct payments back to original NPO and re-order cards if required
(ifa card re-order has been requested, the unissued cards in the Aemative NPO wil be stopped by PCHL)
- (both) POCL PM/RNM collect undelivered benefit cards (if less than 14 days) for issue as normal
POCL Direct all customer payment queries to DSS
oss Call PCHL to issue new cards when required
New opening POCL Send new office details to DSS CAPS
Dss Update records & send to PAS/CMS.
PAS/CMS Change record to show office as open. Awaiting payments from DSS
Beneficiary May request to change NPO to new office
cont/...
COMMERCIAL IN CONFIDENCE Page 88 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
cont/...
[Infrastructure Change] POOL
Refurbisher
cac
Refurbisher
Refurbisher
Refurbisher
Refurbisher
Refurbisher
[ipo ane —] Hs
UKSS
Refurb! Relocat (closure) POOL
Refurb (temp closure) POOL,
Relocat - old office Poo.
(pem closure) UKSS
CPM Networks
cscac
Refurb & Relocat- new = POOL
office (opening) & CM Networks
New Openings UKSS
Provide compliant counter
‘Conduct survey & provide basic modifications for installation, if compliant counter
If non-compliant counter, manage re-survey & quotation [requires a OP]
Configuration/network design
Capacity management
Installation planning
Management & co-ordination
Maintain site survey plans [method tba]
Raise call & schedule engineer to site
Manage inventory changes of Pathway equipment
PRN to complete system shutdown [method tba]
‘hoe shutdown complete, remove Pathway equipment, including LAN as required
‘Conduct basic check/dlean & secure equipment waiting for re-installation
PMIRNM secure PIMC card & PIN
PMIRNM securely transfer PIMC & Fin to new site
Remove re-useable LAN components
Manage cessation of ISDN
Manage system and data purging [method tha]
Confirm site is ready for re-installation (method tba)
Manage installation’ move of ISDN
der & receive new equipment, if required
Install equipment & LAN components
Request (via HSH) SMC to prepare counter software
Run urgent s/w catch up and prepare system for use
Confirm system is ready for use
‘Swipe PVIMC card with FIN, under engineer instruction
Test re-installation
Cbtain FVIRNM sign off on engineer site visit form
Notify HSH when job is complete
Escalate, if necessary [see re 9]
Run non-urgent s'w catch up
[Ref Data Management* I * forfuther details see ref data change processes
Refurb (temp closure) POOL
& New openings CS RORM
CSROT
New opening only POL
DSS
poo.
New opening POOL,
POL
HSH
cane
CSRD
cac
RDP send dlosure details to Pathway, via POOL Authoriser (with CAN Number)
Raise Ref Data Release Note
Manage update of data in RDMC & feeds to MIS & counters
RDP send new details to DSS CAPS
‘Send new details to Pathway to update PAS/OMS
Provide (or transfer between offices) counter operations manuals and training guides
Complete postmaster training in time for installation, if required
Confirm postmaster training to Pathway [method tba]
Mark office as using new staff, for information
Confirms POOL have signed off engneers site visit form
Ref Data Release Manager signs off Ref Data Release Note
Manages submission of ‘invoice' for call-off against blanket purchase order {method tba}
14.1.6.5
COMMERCIAL IN CONFIDENCE Page 89 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
Office Details Change
Details of Postcode (no relocation) / Telephone numbers / Opening times changes
Process Diag
[Nolifcation Ip [Senvice Co-ordination
Change to office Details
Process Step ctor Activities
Poo. POOL Authoriser sends Pathway CS a Change Achioe Note
csa@c Impact change & send CAN Response form detailing Pathway services & assumptions
csasc Manage delivery of change, indluding variations to standard services
csc Excalate, if necessary [see ref 9]
cac Report number & type of changes [method tba]
Postoode TA Identify if change affects contract
TA If yes, update MIS look-up table for local / remote identifiers.
TRA ‘And update contractual documentation
ering times TA Update Distpatch Qhe:
Telephone number TRA Update PAS/CMS for POHL
Ref Data Management* I * for further details see ref data change processes.
Pool ROP send details to Pathway, via POOL Authoriser (with CAN Number)
CSR Raise Ref Data Release Note
CSRD Manage update of data in RDMC & feeds
cSRD Ref Data Release Manager signs off Ref Data Release Note
14.1.6.6
COMMERCIAL IN CONFIDENCE Page 90 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
Planned Outlet Reference Data Change
Planned Outlet Reference Data Change
= This process supports other outlet change processes that require amendments to reference data
Process Diagram
[ ‘Service co-ordination
[Notification be Transfer data }[Change Control }{_ Acceptance I >[ Release to live I
Process Step Act Activities
Notification POCL Authoriser Submit CAN to CS OBC (with unique CAN No,, contact detais, & start dates)
(see outlet process for details of other actives)
cs cBC Notify CS RDT of requirement for ref data change
CS ROT Notify CS RDRM of requirement for ref data change
CS RORM Raise Ref Data Release Note with all CAN details
CSRORM/ RMF — Schedule activities
CS RORM Monitor activities against schedule, start date of data & escalate as necessary [see ref 9]
POCL RD Send Type A data over AIS
ROMC Load Type A data & retum format errors over AIS to POCL RD [incident]
POCL RD Resolve Pathway & TIP errors, send correction file & inform Authoriser
POCL Authoriser Confirm to CS RDTall data has been successfully sent to Pathway & TIP
RDMC Archive all input files & transform data
(Change Control CS ROT Create "System Label" from CAN, with unique CAN Number
CS ROT Identify all files required for each CAN change
CS ROT Check all files & raise queries with POCL Authoriser [Incident] - {requirements tba]
CS ROT Associate data and error files to correct "System Label”
& sign off Ref Data Release Note that data is ready for release
POCL Resolve error & submit correction file with new CAN & Number to CS RDT
CS ROT Associate correction file with "System Label" for orignal CAN Number
CS RDRM Release successful changes for POCL Authoriser to review, if required [requirements tba]
CS ROT Either notify POCL Authoriser change is available for review, or certify success to them [method tba]
POCL Authoriser Receive notification or certification from CS ROT
POCL Authoriser Review change, if required [requirements tba]
POCL Authoriser Sign off change & confirm to CS ROT
POCL Authoriser Reject change & report errors to CS ROT [incident]
CS ROT Sign Ref Data Rel Note to confirm POCL acceptance of change
CS ROT Raise PinICL for errors [incident]
CS RORM Confirm change is complete & free from error & sign off Ref Data Release Note
CS RORM Inform CS OBC & wait for confirmation to release
CS RORM Release change to live counters, MIS, other
TRA Non- delivery reports [method tba # possibi] - [incident]
CS RORM Inform Support of release [tba]
SMC Monitor calls for problems with release [incident]
{problems may arse from counter staff, MIS reports, POCL TP, Accounting other)
POCL PM Report address errors to RHL [incident] - {method of resolution tha}
14.1.6.7
COMMERCIAL IN CONFIDENCE
Page 91 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version:
0.2
Date: 29/06/98
Outlet Data Only Change
Outlet Data Only change
~ The use of this process has not been agreed in principle, but would support changes to POCL organisational information
that required no Pathway intervention, other than to process the data
Process Diagram
[Transfer data {Change Control I pfReleasetolive I
Process Step Actors Activities
POOL RD ‘Send Type Adata over AS
ROMC Load Type Adata & retum format errors over AS to POOL RD [incident]
POOLRD Resolve Pathway & TIP errors, send correction file
FOMC Archive all input files & transform data
CSROT software Check all files & raise queries with POOL RD [Incident] - [requirements tba}
CSPOT Notify CS RORM of change
CSRORV Release change to live counters, MIS, other
CSRORM Reoord release & notify CS CBC method th]
CSRORM Notify support
TRA Non- delivery reports [method tha if possible] - [incident]
14.2
COMMERCIAL IN CONFIDENCE Page 92 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
Operational Business Change - Product
14.2.1 Change Types
Product changes are categorised into the following types.
14.2.1.1 Product
Introduction of a new EPOSS product.
Changes to an existing EPOSS product, or changes to the way EPOSS works using
reference data, are subsets of this process. That is, the same process will be
followed to make changes, as are followed for introducing a new product, but not all
of the activities will apply.
14.2.1.2 AP Client Service
Introduction of a new Automated Payment Client Service (i.e. new AP product).
Changes to an existing AP product, or other AP information, are subsets of this
process. That is, the same process will be followed to make changes, as are
followed for introducing a new AP product, but not all of the activities will apply.
14.2.1.3 Data Only
These changes are a subset of the two above, but are singled out as they have no
impact on Pathway and can be implemented by changing the data with no manual
intervention by Pathway.
14.2.2 Top Level Processes - Product
The table below gives the top level view of the processes for product change.
The four elements of each changes are:
1. Management
1. Notification
1. Implementation
1. Acceptance
The services that make up each element are given, for the different change types.
COMMERCIAL IN CONFIDENCE Page 93 of 104
ICL Pathway
ICL Pathway Customer Service: Customer Ref:
Service Operations Manual version:
POL00393875
POL00393875
CS/MAN/004
0.2
29/06/98
[ Management ]
[—_Nefification_]}»[_Impiementation [Acceptance]
Assumptions:
New Product
Change Advice Note Service co-ordination Verification
Transfer Data Release to live
Change Control
Enrichment
Documentation
Testing
Error Management
AP Client Service
Change Advice Note ‘Service Co-ordination Accetpance
Transfer data Release to live
Change Control
Enrichment
Error Management
Testing - End-to-end
Testing - intemal
Data Only
Change Advice Note Service Co-ordination Accetpance
Transfer data Release to live
Change control
Testing
Error management
Subsets of these categories will be added in future releases of this document.
COMMERCIAL IN CONFIDENCE
Page 94 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
14.2.3 Change Advise Note (CAN) Details
The Change Advise Note from PCOL to Pathway that requests the
implementation of change should contain the following information. If the
information is not provided in the CAN, the assumptions made will be given in the
CAN Response Form (Pathway’s acceptance of the request for change).
All Reason for change
Unique CAN Number (to be copied onto ref data file)
Contact details for data queries
Data start date
Change start date
Product Primary data
To be attached:
Type B data
Menu Hierarchy / Icon change details [ref 6]
AP Client Primary data
Service
To be attached:
Type B data
Client Take on Pack
Contractual list of Client Service supported by Pathway
Client Requirements
Interface specification
For further details of Primary data and Type B data requirements see [ref 8].
14.2.4
COMMERCIAL IN CONFIDENCE Page 95 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
Second Level Processes- Product
14.2.4.1 Error Management
Throughout these processes are references to [incident]. This indicates that that
action may raise an incident as part of the Reference Data Error Management/
Reconciliation process. This process is yet to be defined.
14.2.4.2 Terminology
The following processes include the term ‘system label’, this refers to the
mechanism of labelling all the files that belong to a change (CAN Number) in the
RDMC, so they can be realised as a single unit.
14.2.4.3
COMMERCIAL IN CONFIDENCE Page 96 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
New Product Process
New Product
Process Diagram
[ Senice co-ordination
[Notification ]p>[_“Tiansfer data I>{_Enrichment__Ip{ Testing IpI Aceptance ]>[ Release to live ]
[ Change Controt ]
Process Step Actors Activities
POOL Authoriser Informal communication with CS RDTto discuss possible issues
POL Authoriser ‘Submit CAN to CS ROT
(with unique CAN Nb,, contact details, primary data, menu hierarchy icon change details [see ref 6] & start dates)
CSROT Impact CAN (incl: risk assessment) & return response to POCL Authoriser
CSROT Notify CS RORM of requirement for change
CS RORM Reise Ref Data Release Note with all CAN details and Primary Data
CSRORM/ RMF Schedule activities
CS RORM Monitor activities against schedule, start date of data & escalate as necessary [see ref 9}
POCLRD Send Type A data over AS
FOC Load Type Adata & retum format errors over AS to POCL RD [incident]
POOLRD ‘Send Type B data via agreed means to CS ROT
CSROT Load Type B data & return format errors to POOL RD [incident]
POOL RD Resolve Pathway & TIP errors, send correction file & inform Authoriser
POCLAuthoriser Confirm to CS RDTaall data has been successfully sent to Pathway & TIP & EQOO
ROMC Acchive all input files & transform data
[Change Control CSROT Qeate "System Label" from CAN, with unique CAN Number
cSRoT Identify all files required for each CAN change
CSROT ‘Check all files & raise queries with POOL Authoriser [Incident] - [requirements tba]
cSROT Associate Type A B, Cand error files to correct "System Label"
& sign off Ref Data Release Note that data is ready for release
CS RORM ‘Send Ref Data Release Note with CAN details & primary data to Enrichment team
Enrich Team (ROT) Generate Type C data from primary data {method tba]
(e.g icons, menus, cash account, other reports, internal messaging)
CS RORM When POOL data set complete: Release Type A & B data to Enrich team
Enrich Team (RDT) Complete Type Cdata using Type A& B data
Enrich Team (ROT) Sign off Ref Data Rel Note & give Type C data file to CS ROT
cSROT Load Type Cdata & return format errors to Enrichment Team [incident]
Enrich Team (ROT) Resolve data errors, create correction file, sign off & resubmit to CS ROT
ROMC Archive all input files & transform data
csRoT Manage updates to PPDs for Counter & Training documentation etc. if needed {method tba}
CSROT Inform POCL Authoriser of any changes to PPDs
csRoT Manage updates to Menu Hierarchy / Icon documents [see ref 6]
CSROT ‘Sign off Ref Data Release Note to confirm documentation changes are complete
cont/...
COMMERCIAL IN CONFIDENCE Page 97 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
cont/...
CSRERV. When enriched! release data and send Ref Data Ral Note to Testing
csor ‘Set up environment (eg set counter dlock) & test/check change freaiirerrents tha]
TA Benchmark change to check transaction times, if required frecuirererts the}
csoT Raise AiniCL for errors [incident]
cor Notify of success & sign off Ref Data Rel Note:
4th Line Supt (ROT) Identify source of errors & return to creator
POCLEnich Team =—_- Resolve error & supmit correction file with new CAN & Number to ROT
CROT Pssociate correction file wth "System Label" for original CAN Nurber
CSRERV Release successful changes for POOL Authoriser to review, if required {requirerrents tha}
(with ary available supporting test docurrertation)
CRO Either notify POOL Authoriser change is available for review, or certify success to themImethod tho]
POOL Authoriser Receive notification or certification from CS ROT
POOL Authariser Review change, if required frecuirerents ta}
POOL Authoriser ‘Sgn off change & confirm to CS ROT
POOL Authoriser Reject change & repart errors to CS ROT [incident]
CSPOT ‘Sign Ref Data Rel Note to confirm POOL acceptance of change
CRT Reise FiniC_for errors [incident]
CSRORV Confirm change is complete & free from error & sign off Ref Data Release Note
CSRORV Release change to live counters, MS, other
TRA Non- delivery reports [method the if possibie] - [incident]
CSRRV Inform Support of release {tha}
svc Monitor calls for problems with release [incident]
(probierrs may arise from courter staff, MS reports, FOOL TP, Accounting. other)
14.2.4.4
COMMERCIAL IN CONFIDENCE Page 98 of 104
ICL Pathway ICL Pathway Customer Service: Customer
Service Operations Manual
POL00393875
POL00393875
Ref: CS/MAN/004
Version: 0.2
Date: 29/06/98
AP Client Service Take-On Process
AP Client Service Take on process
Process Diagram
[ ‘Senice Co-ordination ]
Notification Ip Transfer data__Ip>[__ Enrichment _ Ip>[ Testing Ip Acceptance Ip>[ Release to live I
[ Change Control ]
Process Step Actors Activities
POCL Authoriser Informal communication with CS ROT to discuss possible issues
POCL Authoriser Submit CAN to CS ROT with CTO Pack, Contractual listing, Reats & Interface Spec
(with unique CAN No., contact details & start dates)
CSROT Confirm token’ bar codes are standard, identify non-standard connection services [method tha]
CSROT Accept CAN & sign of Contractual list of supported Client Services
CSROT Return response to POOL Authoriser
POCL Authoriser Resolve any business issues
CS ROT Notify CS RORM of requirement for change
CS RORM Raise Ref Data Release Note with all CAN details and Primary Data
CS RORM / RMF Schedule activities
CS RORM Monitor activities against schedule, start date of data & escalate as necessary [see ref 9]
POOL RD ‘Send Type A data over AIS
FOMC Load Type Adata & retum format errors over AIS to POOL RD [incident]
POCL RD Send Type B data via agreed means to CS ROT
CSROT Load Type B data & retum format errors to POOL RD [incident]
POL RD Resolve Pathway & TIP errors, send correction file & inform Authoriser
POL Authoriser Confirm to CS RDTall data has been suocessfully sent to Pathway & TIP & ECOO
ROMC Archive all input files & transform data
CSROT Qreate "System Label" from CAN, with unique CAN Number
CSROT Identify all files required for each CAN change
CS ROT Check all files & raise queries with POCL Authoriser [Incident] - requirements tha]
CSROT Associate Type A B, Cand error files to correct "System Label"
& sign off Ref Data Release Note that data is ready for release
CS RORM Send Ref Data Release Note with CAN details & primary data to Enrichment team
Enrich Team (ROT) Generate Type Cdata from primary data {method tha]
(eg. cash account, other reports, intemal messaging)
CS RORM ‘When POCL data set complete: Release Type A & B data to Enrich team
Enrich Team (ROT) Complete Type C data using Type A & B data
POL Authoriser Send Gient's Test Tokens to CS ROT [method tha}
Enrich Team (RDT) Test the Tokens with complete reference data
Enrich Team (RDT) Riise FinICL for errors [incident]
CSROT Raise problems with POCL Authoriser [Incident]
Enrich Team (ROT) Sign off Ref Data Rel Note & give Type C data file to CS ROT
CSROT Load Type Cdata & retum format errors to Enrichment Team [incident]
Enrich Team (ROT) Resolve data errors, create correction file, sign off & resubmit to CS ROT
ROMC Archive all input files & transform data
cont/...
COMMERCIAL IN CONFIDENCE
Page 99 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
cont/...
4th Line Suprt (ROT) Identify source of errors & retum to creator
POQL/Enrich Tiient Resolve error & subrrit correction file with new CAN & Nurber to ROT
CSROT Fssociate correction file with "System Label" for original CAN Nurrber
POOL Authoriser ‘Send plans to CS ROT for end-to-end testing
cSROT ‘Agree test plans with POOL Authoriser
Internal CSRORV. ‘When enriched: release data and send Ref Data Re! Note to Testing
cor ‘Set up environment (e.g. set counter clock) & test/check change [requirements tha]
TA Benchmark change to check transaction times, if required {recuirements tha]
cor Raise FinICL for errors [incident]
cso Notify of success & sign off Ref Data Rel Note
End-to-end CSROT/ OT Prepare for end-to-end testing
POOL Authoriser Manage end-to-end testing with POOL, Pathway & the Glient
CSROT/ OT Send files for End-to-end test
CSROVPOCUMGient Raise & resolve errors [incident]
POOL Authoriser ‘Sign off change & confirm to CS ROT
CSROT ‘Sign Ref Data Re! Note to confirm POOL acceptance of change
CSRORV Confirm change is complete & free from error & sign off Ref Data Release Note
CSRORV Release change to live counters, MIS, other
TA Non- delivery reports [method tha if possible - [incident]
CSRORV. Inform Support of release [ta]
SVC Monitor calls for problems with release [incident]
(problems may arise from counter staff, MS reports, FOL TP, Accounting other)
14.2.4.5
COMMERCIAL IN CONFIDENCE Page 100 of 104
POL00393875
POL00393875
ICL Pathway ICL Pathway Customer Service: Customer Ref: CS/MAN/004
Service Operations Manual Version: 0.2
Date: 29/06/98
Data Only Product Change Process
Data Only Product Change
- Data changes that use only Type A Data, where Pathway do not require advance notice of the change to implement successfully
Process Diagram
[ Senvice co-ordination ]
[Notification ]p>[_Transfer data_Ip>[ Testing IpI Acceptance IP>[_Release to live ]
[ Change Control ]
Actors Activities
POOL Authoriser Submit CAN to CS ROT
(with unique CAN No., contact details & start dates)
CSROT Impact CAN (inc!: risk assessment) & return response to POOL Authoriser
: CSROT Notify CS RORM of requirement for change
CS RORM Raise Ref Data Release Note with all CAN details
CS RORM / RMF Schedule activities
CS RORM Monitor activities against schedule, start date of data & escalate as necessary [see ref 9}
fransfer data POOL RD ‘Send Type Adata over AS
ROMC Load Type A data & retum format errors over AIS to POOL RD [incident]
POOL RD Resolve Pathway & TIP errors, send correction file & inform Authoriser
POOL Authoriser Confirm to CS ROT all data has been successfully sent to Pathway & TIP & ECOO
ROMC. Archive all input files & transform data
CSROT Create "System Label" from CAN, with unique CAN Number
CSROT Identify all files required for each CAN change
CSROT Check all files & raise queries with POOL Authoriser [Incident] - {requirements tba}
CSROT Associate Type A and error files to correct "System Label”
& sign off Ref Data Release Note that data is ready for release
5 = 7
f a I Ok 7 7 8G
8 Fi Ie IS 8 8I iB
3 g re) 8 3I
4 = Fl
4 5
CS RORM Release data and send Ref Data Rel Note to Testing, if required
cso Set up environment (e.g. set counter clock) & test/check change [requirements tha]
cso Raise FinlQL for errors [incident]
cso Notify of success & sign off Ref Data Re! Note
Poo. Resolve error & subrrit correction file with new CAN & Number to CS ROT
CSROT Associate correction file with "System Label" for original CAN Number
tance CSROT Certify success to POOL Authoriser
POOL Authoriser Receive certification from CS ROT
POOL Authoriser Sign off change & confirm to CS ROT
POOL Authoriser Reject change & report errors to CS RDT [incident]
CSROT Sign Ref Data Rel Note to confirm POOL acceptance of change
CSROT Raise FinIQL for errors [incident]
CS RORM Confirm change is complete & free from error & sign off Ref Data Release Note
CS RORM Release change to live counters, MIS, other
TRA Non- delivery reports {method tha if possi} - [incident]
CS RORM Inform Support of release [tba]
smc Monitor calls for problems with release [incident]
(problems may arise from counter staff, MIS reports, POOL TP, Accounting, other)
COMMERCIAL IN CONFIDENCE Page 101 of 104