Recently I’ve been looking at some exciting new changes which might be in the pipeline for the IT helpdesk, namely replacing our old and somewhat rickety system with a new, shiny SAAS one.
Aside from the savings of £14 bazillion pounds a month this will make (which I may have exaggerated, but it will save us money) and the fact it’s a simply better service, not to mention the way it’s web based with mobile clients so support techs can use it anywhere, its support of elegant automated workflow processing, better information capture and integration with everything else we use; it’s a very social piece of software.
We’ve currently got it working in such a way so that if you send us a problem over Twitter we can seamlessly pull it into the system, deal with it, and respond. You need never know what’s happening behind the scenes, all you know is that we’re handling your problem. However, what we need to know is more than just your Twitter handle – we need to know your full name, your student ID number, which course you’re on and various other things so that we can actually solve the problem. There’s also the fact that anybody can email the helpdesk from any account which produces this same problem. We know exactly who you are if you use your student email account, but we struggle to know who xx_bubble_princess_xx_28463 is.
We could reply to every single instance of this asking for a student’s ID number so that we can look them up on the system, but this is inelegant and provides no actual proof of the connection between the person at the other end and the ID number other than their word. Clearly this is not the situation that we want to be in, but forcing students to communicate with the helpdesk exclusively through their student email account isn’t much help, especially when the problem they’re experiencing is down to logging in or email access.
Instead what’s needed is a way of positively associating the two before we get into the situation. In short, we need to collect (and validate) the other email addresses and Twitter account names which a student goes by. This is a relatively simple affair (log the student in to validate their student ID, then send validation links to emails and use Twitter’s OAuth sign-in to validate accounts) but it immediately generates massive benefits in more than just the field of support. Not only can we now automatically push these details into our new helpdesk so it knows exactly who is on the other end of most queries without needing extra steps, but we’ve also got validated alternative contact routes for every student. Furthermore, we can begin to actively engage students over social media routes by following them (again automatically) on Twitter, spotting and responding to problems and more. We can even begin to use the email addresses to tap into a student’s public information on Facebook, giving us yet another angle on what a student is doing; or to see where students check in on FourSquare.
Of course, it’s up to the student whether they want to share their details with us, but it might lead to some interesting cases whereby a student complains that the University is monitoring them when in fact all we’re doing is tapping into the information that the student has released to the public.
I’ll leave the ethics of it up to the academics and the committees, but to me it seems that we need to collect the information to provide a world-class support service to our students regardless of how they want to contact us. Big Brother can come later.