Servicedesk Operator Guide

The servicedesk operator's objective is to monitor and triage support channels to provide a good experience to our customers.

There are 3 main channels to monitor, the Servicedesk (via -admin account), and the brics-support@bristol.ac.uk and brics-technical@bristol.ac.uk inboxes. Our service hours are 9am to 5pm, Monday to Friday, excluding public holidays and University of Bristol closure days. The SLA for service desk operators is to reply to tickets within 4 working hours of the ticket being opened.

Ticket workflow

The workflow revolves around organising tickets according to level and workstream. The workflow is not mechanical and requires the operator's judgement to achieve the overall objective.

The operator is expected to be competent using the servicedesk platform, and have a working knowledge of our systems and documentation as well as general situational awareness.

• Read and understand what the ticket is about to decide the next step:
• Level 0 (documentation)
  • Self-assign and direct to documentation
  • Depending on the nature of the issue, it might be possible to close immediately
• Level 1 (trivial)
  • Self-assign or assign to another team member for quick resolution and closure
  • Proactively consider a docs change to allow similar tickets to resolve at Level 0
• Level 2 (non-trivial)
  • Contact the most appropriate workstream so they can choose someone
  • Self-assign at Level 1 and send an initial response until it can be redirected to the correct workstream/person.

In all cases set the owner, state and priority, and add tags to the ticket as needed: * Level 0/1/2 * Isambard-AI Phase 1/2, Isambard 3, BlueCrystal5 * Waiting for Customer

By the end of the operator's turn, all new tickets should be (pending) closed at Level 0/1, or escalated to Level 2. Operators do not get to pass tickets on to the next person on rota. The overviews for unassigned and untriaged tickets are very helpful for keeping on top of things.

The operator should take time to review tickets that are already open to spot any that can be closed or have gone stale.

Comments are private by default

Remember to post public comments by clicking the padlock!

Detailed ticket guidance

Level 0

Ideally, users will self-serve their own solutions via the documentation and not raise a ticket. However, users will not reliably do this and the operator will realistically spend time redirecting users. Never assume users have checked the documentation first.

Judgement is needed with closing such tickets. Sometimes, the ticket can be set to level 0 and closed immediately. Other times, the user will need time to see if the documentation solution works, and the ticket may need subsequent escalation to Level 2.

Level 1

This is the starting level for all new tickets. Tickets at this level are either in triage or trivially solved. Either way, the aim is to give a prompt initial response.

If the operator has the technical expertise to resolve and close the ticket, do so. It is OK to have a few exchanges with the user but do not let this become protracted. Don't be drawn into taking on tickets that require Level 2 expertise- this is not the operator's job when on rota.

The operator can reduce workload for themselves and others by drafting documentation to allow similar future tickets to be resolved at Level 0.

Level 2

Any tickets that cannot be quickly solved at Level 0 or 1 should be escalated at Level 2 via the appropriate workstream. Going via the workstream allows workload balancing between individuals. Use Slack to contact the workstream. The operator remains the owner until a named person takes over.

Keep the user informed whilst escalation is arranged. Once passed on, the role of the Level 1 rota operator is complete.

Level 3

The operator will not normally need to interact with Level 3 tickets. These are for when issues need to be elevated to a vendor such as HPE, NVIDIA or IT Services. Tickets requiring Level 3 escalation will usually be from Level 2 by the relevant workstream.

Silent tickets

Users will often seemingly abandon tickets they have raised. These can build up over time if they are not managed and can get in the way. The operator should proactively manage such tickets. There are two main tools:

• Use the Waiting for Customer (or supplier) tag to highlight tickets are waiting on input from someone outside BriCS
• Use the pending close status along with a public comment to give the user a set amount of time to respond before automatically closing. 1-2 working days is usually appropriate, depending on the specifics of the ticket.

Closing a ticket

It is very common that customers will not close their tickets once their problem has been solved. The operator has two options:

If it is clear that the issue has been resolved, immediately close the ticket or use pending close if it makes sense to allow the user to confirm.

If it is unclear whether the issue has been resolved, ask the user in the ticket. Deal with any response as appropriate. If no reply is received in a reasonable amount of time, treat it as a silent ticket (above).

Further information

Tone and style

We all have different writing styles and some individuality adds a human element which can reassure users. Ensure that all correspondence is polite, professional and helpful, and it is reasonable to expect similar in return. However, be confident to say 'no' to requests when appropriate.

If an interaction becomes inappropriate for whatever reason, reach out to other team members. In some cases the leadership team may need to intervene.

Platform

We are using Zammad as our service desk. Zammad comes with extensive operator documentation (which Zammad confusingly calls "user documentation").

Setting up the inboxes

As a servicedesk operator, the brics-support@bristol.ac.uk and brics-technical@bristol.ac.uk inboxes should also be monitored and emails raised to the appropriate person. These can be added to outlook by following this guide. To request access, please contact an administrator by emailing the Bristol Centre for Supercomputing mailbox.