This is a preliminary practical approach from the standpoint of User Services Group to explain what can and maybe could be done in this task.
Firstly a list of tasks is given followed by a list of questions to be resolved and finally ‘an image for the future’. The Duty Manager is henceforth denoted by MoD.
The MoD is responsible for:
Check reply quality and content of at least all non-simple Helpdesk cases and spot check on simple ones. These cases are specifically contained in the domain of the Helpdesk. Escalated cases to local-support cannot be easily verified but a means needs to be found if technical replies are to be verified. Work needs to be done with the Remedy team such that problems and replies can be followed more easily.
Help with replying to phone calls and mails received at the Helpdesk. Here it is important to be at hand to help understand difficult questions and occasionally deal with difficult users. Monitor the way in which some replies are formulated in Remedy.
Contact service providers as required for, changes, interrupts and failures. The definitive list ( mentioned in the ‘to be resolved’ category ) of service providers assumes that these persons are responsible for service problems and to the MoD for resolution. These persons should contact the manager as do the operations staff in case of failure and updates involving the status displays.
Co-ordinate news for users for problems mentioned above. A ‘targeted’ zephyr message, news or maybe even phone calls to ensure users are aware of failures of any sort. A copy of mail to service providers is received from Operators when there is an alarm ( see also ‘to be resolved’ category ).
Prepare a report for C5 of problems that need to be tackled by divisional management. This report should highlight anything involved in improving the service quality from the Division. Should a satisfactory result not be forthcoming we would expect this to be escalated to the DMM. This report should be coupled with statistical information of the week’s work ( see also ‘to be resolved’ category ).
Maintain a service status board and web page for user information. The board should contain information on actual problems and forthcoming changes. The latter should at least be mirrored on the web page and tvscreen.
Co-ordinate qa creation for new problems with members of US/UA. Although not a specific task of the MoD he/she should ensure that when qas are missing a new one is created ( or one edited ) by members of the UA section with help from the service provider. It is felt useful for consistency purposes that as few persons as possible be editors within UA. These persons should form a small group and especially differentiate between qas and faqs ( these will be used on the web UA web page for information ). This work also involves integrating new problems in the knowledge database.
Escalated problems should be followed to their conclusion ensuring that the sla is adhered to correctly. Problems escalated within IT should be followed rigidly whereas those sent to local support cannot be quality controlled. To this end, problems reported to Nicole or Roger can be passed to the weekly contract management meeting they attend on Thursdays. A solution through the Remedy system would be an ideal way to resolve this; UA will use their regular meetings with the Remedy team to try to advance on this issue.
The whole problem resolution process should be documented. Once fully aware of all the implications this should be presented to the Division as a template for the present and a design for the future.
Suggest ways whereby the Helpdesk receives less calls. It is imperative that call reduction is a major goal to reduce staff requirements and reduce problem intake.
Problems to be resolved
Before the implementation of such a scheme the following need to be addressed:
Length of time of MoD on shift. Here there have been suggestions of periods of work from half a day to a week. A trial period in July of a one-week shift will be assessed. Principle drawbacks are the work already scheduled, leading to absences from the task and the amount of work resulting from the week’s work.
List of services and contact persons. There are several lists of this sort already in existence so a thorough review needs to be undertaken and rules laid down for the follow up of problems reported to each service.
News and zephyr message consistency. Each MoD should act in a consistent manner with regard to notifying users. Again a document already exists which needs to be reviewed with regard to the new proposals. Special attention should be given to methods ( maybe with zephyr ) of targeting specific user groups affected by problems.
Total volume of replies that can be checked. See next section for details.
Numbers of persons needed for the task and how to train new staff. It is clear that members of UA fit the task easier than most. For future development the MoD should also be composed of service providers from other Groups. Most suited members are those with broad knowledge of many services and good ability to communicate; these qualities should be transferable to new staff with different areas of knowledge who can bring new ideas and visions of support to the Helpdesk as a whole.
The level of statistical information needed. We must ensure this is targeted towards a meaningful list of statistics, however purely numerical, as quality cannot be measured by these means.
Mechanism to assign a person to follow problems from beginning to solution. Presently there is no method for one person to be assigned as responsible for a problem. This is being followed up with the Remedy team.
Time estimates for repairs and user expectation. If a time estimate is given it must be upheld or at least the user contacted. Many of these times will revolve around interventions by the support contract, a list of the slas for general and local supports are useful guidelines.
History and future stages of development.
In the past reply quality has never been controlled and the Helpdesk contract staff have been left in an important area rather too much on their own. The new configuration can add confidence to their work but at present only within the helpdesk domain. It is the considered opinion of UA section that we can quality control most of the non-trivial helpdesk replies by the means mentioned above. With barriers removed for problem tracking and follow up we can certainly reply to and inspect most non-trivial problems. What is essential to clarify is that to move forward to include non-Helpdesk questions extra staff need to be employed to cover the quantity and global mass of questions.
For the present and short-term future this document should be regarded as Stage 1 where the quality, speed, consistency and accuracy of replies from the Helpdesk should be monitored.
Replies to problems both in and outside the Helpdesk domain remain the work of the user relation’s team, this will continue.
We can consider Stage 2 as tackling problem replies from the Division as a whole where new expertise for documentation and writing skills would be needed and the quantity of questions filtered by the Helpdesk would rise considerably. These criteria lead to extra costs, more staff and extra technical facilities like call center telephone systems, automatics password changing and quota increases etc.
We consider to first complete Stage 1 to ensure quality replies through US at which point we will be better prepared to prepare and manage Stage 2.
Action
list:
1. Provide a method to follow problems by owner. Facilitate random check on replies given by local support. ( FIO/US Meetings, responsible RW/NC ) ongoing after 4.7.02, next meeting 13.08.02
2. List of service providers contacts and backups from the Division. ( out of DMM, responsible LP ) target mid August.
3. Targeted message delivery, e-mail, zephyr, news etc. Investigate possibilities. ( out of IT Division, responsible MD ) target end August.
4. Service status board web-page. Action LP/RW, target end August.
5. QA task force of 3 to 4 persons from US/UA. Action BP, start August.
6. Length of MoD shifts. Trial periods until end August and agree at Monday analyst meeting. Action RW, target end-August.
7. Statistical information needed for Group and also for C5 reporting. Evaluate requirements. Action RW, target end September.