We were pleased to attend the IT Services security event on Thursday 8 November 2018, which hosted a number of interesting speakers from different IT security specialisms. The event provided a deeper awareness of IT security from an insider’s perspective and the essential work that individuals and organisations in this industry do to manage and prevent the risks we face.
UniDesk is the system we use to log and progress incidents, more commonly known here as calls. This can be used by University and non-University members alike to submit their problems and then follow their progress.
As each team member was using UniDesk slightly differently, it became clear that we needed some rules and guidelines on how we should use it consistently.
I thought it may be of use to other teams using a call management system to see what we’re doing.
Three levels of support
The way we are set up, there are essentially three levels of support:
- First line: IT service desk (a physical help desk in the library).
- Second line: Digital communications support team (Peter and Duncan).
- Third line: Rest of the digital communications team.
Below are some of the rules and guidelines that aren’t too specific to our team:
When a call is assigned to us
When the IT service desk (first line) assigns a call to us, it arrives with the status of ‘New’. In UniDesk terms this means unread and completely unactioned.
Once a member of the team has read and understood what the call is about they mark it as ‘Open’. This shows the service desk we are aware of the issue and are taking steps to resolve it.
If the issue has to wait until Friday, when the rest of our team works on support calls, then the support team will email the user to let them know about the short delay.
Calls with no response from user
If we have not heard back from a user after two weeks, we change the call status to ‘Closed – User confirmed’ and add the following to the action field: “Not received a reply from user in two weeks or more.”
Calls past their target date
If calls pass their target date, second line support will extend the call by two weeks, then let the operator know about specific call at the next daily catch-up meeting.
Whenever a call is incorrectly assigned to us we de-escalate it back to the IT service desk. This not only helps educate first line about what to assign us and what not to, but it of course guarantees that the call gets passed to the right group.
Team member on holiday or off sick
Before a team member goes on holiday, they should reassign the call to another team member; at the very least they should assign the call to the “Digital Communications” operator so that it can be picked up by second line.
If the call relies solely on the absent team member, if they have not already done so, the second line support team should send a short email to the user alerting them of the absence and an indication of when they are expected to return.
In order to keep our responses and general output consistent across the team, we use a set of standard replies.
These are pre-written email templates so all we have to do is replace certain placeholders with the details relating to that specific call. This way the user should be getting roughly the same response and level of support regardless of who is dealing with the call.
We also use standard replies in our Outlook emails when re-directing users to contact us through the IT service desk, instead of our personal email address. Preventing important requests from becoming lost in a personal email account.
Our guidelines, of course, contain a lot more information, such as the specifics of the standard reply texts and what detailing what each button in UniDesk does, but sharing that here would be wasteful. I hope you find the above useful.
Hopefully, once our team becomes fully accustomed with the rules, our UniDesk output will be almost identical in format and professionalism.
We all love to listen to music, whether that be at work or at home. And for most people, Spotify is their go-to app for music streaming. Today, I would like to share with you a helpful tip so you can get the most out of your subscription.
As you may know, listening to your own ‘local’ music can be a pain using Spotify. This guide will show you how to set-up your own music to work perfectly with Spotify.
First of all, if you don’t already have one, you’re going to need a DropBox account (use that link to get an extra 500Mb of space). The Dropbox basic plan, which is free, comes with 2Gb of space. But the paid-for version comes with 1Tb (1,000GB) of space.
Once you have created your account, you will need to install the DropBox app. This program will run on your computer, constantly monitoring a specific folder. Any files added to or removed from that folder get synchronised with any other computer you’ve installed it on.
Next, you want to move your own music library into the newly created Dropbox folder. You can also organise the files and folders within your Dropbox folder anyway you like, i.e. by artist or genre. Now you want to set your Spotify to look for your local files. To do this, open Spotify and:
- Hover over the ‘Edit’ tab at the top of the app and select ‘Preferences…’
- Scroll to the bottom of the ‘Preferences’ page and you will find a ‘Local Files’ section.
- Select the ‘Add a source’ button and then navigate to the location of your Dropbox folder.
Luckily, Spotify will automatically look for newly uploaded files. So you don’t have to worry about setting this up every time you use Spotify. Though you will have to follow these steps for every new computer that you set this up on.
Now that you’ve configured Spotify to look for any local files you have stored in Dropbox, whenever you upload a song on one computer, it will be synchronised to every computer you have connected. Making storing and listening to your own music much easier.
Earlier this month my colleague Duncan and I conducted an extensive audit of our support calls from January to July 2015. Over these six months there was exactly 600 support calls, which we split up into three main categories: advice, fix and request.
We then went further and sorted each call into a more defined sub-category; such as: WordPress, coding, content and access rights. This allowed us to see which problems were encountered the most and how we might prevent the same issues from arising in the future.
Below you can see the type of calls we received and how we categorised them:
This post will explain the training process that is undertaken when trying to access our most prized possession, TerminalFour (T4) Site Manager. This is the content management system that sits behind our University website. In T4 there are various user levels, from contributor to administrator level. I will only be covering contributor level in this post, as we currently don’t have any formal process for the other levels of access.
The old world
First of all, let me start from the beginning. In the days of old we used to run large, in-person, training that involved a member
of our team running a three hour course in a computer classroom, which any member of staff could sign-up for. This, of course, came with its disadvantages as many of the people attending had no real reason to access T4. They were either forced along by their line managers or just had a general interest in the University’s web space. This not only wasted our time but theirs too! We ended up with a very large list of users who had only accessed T4 once in a whole year and who didn’t really know what they were doing. Which resulted in poor content and inconsistencies right across the website.
The new world
We knew we needed to completely re-vamp our training processes. We needed something that didn’t take up our time and resources, but at the same time gave a useful and meaningful learning experience. We came up with the idea that the user should learn first-hand how to use T4, so to begin with they are assigned access to their very own training section in T4. Here they have to complete a number of practical exercises, which involve:
- The creation of different types of content;
- Familiarising yourself with the HTML editor;
- Uploading and using images and files.
Plus many more! They then have to complete a short quiz, which tests them on everything that is covered by the practical exercises. To pass they have to achieve at least 80%. This ensures that they actually know how to use T4 and have a certain level of technical ability.
Once the user has completed the basic contributor level training, they are granted edit access to whichever section they choose. We also still run ad hoc in-person training for the Moderator level, which grants users the ability to publish entirely new content without approval from a another T4 user. Which of course can be risky!
As time goes on, we hope to have a fully fledged content management process. This will clearly dictate what can and can’t be done by users of T4. We will also be creating the materials required to teach right up to administrator level, so the pressure is no longer on us to run time-consuming courses. Besides the T4 training, there are still a few key skills required to create engaging content, such as writing for the web. This teaches users the various differences between print content (newspapers, books etc…) and content on the web. A very important skill, in which every user should be completely familiar with.
Once all of these procedures are in place we will have a very robust and efficient content management system, where we have ultimate control and every user shares the same basic web skills.
All of our help and support requests are handled through a system called UniDesk, which logs information on who spoke to who and distributes email notifications to the relevant people. UniDesk calls these requests ‘support calls’.
Our old way of working
In the past the whole team would each spend a few hours a day, sometimes more, on support calls. Our days would be segmented into a mix of support calls and project work, so it was always a struggle to get any real development work done. If we did manage to get a break from support calls and get to work on a project, it would only be for a very brief time.
My new role within the team
Since July 2014 the digital communications team have been handling their support calls in a new and more productive manner.
In the new world I am solely responsible for the management, and in the majority of cases, the resolving of our support calls.
When a call is submitted I will first of all gain a quick understanding of what the work involves. In most instances I will then assign it to myself and resolve the problem as soon as possible. We also have a strict rule that calls shouldn’t be left as ‘New’, so after I’ve read it I will set it to ‘Open’.
Involving other team members
I sometimes have to assign a support call to another member of the team.
I may assign a call to someone else for a number of reasons:
- I have never come across the site in question and don’t have the required rights to access the admin back-end.
- A member of the team was directly involved with the support call previously and the time it would take to get me up to scratch would be much greater than he/she resolving the issue themselves.
- The work involved requires more specialist knowledge (e.g. a particular third party program).
Other members of the team dedicate an amount of time each Friday to resolve these calls. We have named this ‘Fix it Friday’. This frees up the rest of their week to work on project and development work.
All in all I believe our new way of working is much more effective and we get a lot more done! As time goes on we hope to expand our support side of the team and become even more efficient.