What seems like many moons ago I wrote two blog posts on setting up a new chat service at Bath Spa University. You can find them here and here.
Since then I moved to a new role at the University of Southampton and in doing so took on another chat service, one which was also still in relative infancy. I was tasked with making the existing chat a sustainable service in light of restructures and an evolving library service. Hard in any organisation but difficult in one as large as University of Southampton libraries. Very difficult in light of the fact that chat was popular, incredibly popular, compared to most other libraries I know of.
We are still moving through this process of change and while I have struggled with the task at times one thing I am certain of is that with chat we are offering a valued service that picks up questions that might otherwise never have been answered, or even asked.
During this time I have been approached several times by other libraries interested in setting up a chat service and have always been happy to share what I have learnt. I often point them towards my original blog posts and recently realised I should probably add a more updated version. So here it is. Lessons learnt after over two years of working with online chat services. (Part 1)
First off technology. I covered this in much detail during my first blog posts. Obviously things have changed. Some services have disappeared. Some have sprung up. Libraryh3lp, the chat service I’m most familiar with is still out there and has recently had a refresh with new features. It’s also the one we use at Southampton. We see glitches with it, odd behaviour and delays in chats appearing that no one can explain but generally it does the job. If we were a smaller service with only a few users I suspect we wouldn’t even notice these bugs but with multiple staff logged on and sometimes fifty chats a day we do indeed see problems arise, even if our users never realise. I still recommend Libraryh3lp to anyone wanting to start a chat service because generally there isn’t much between most of the library focused chat services. Libraryh3lp stands out in that it is cheap and in the two years I have been using it have always provided prompt and helpful responses to any questions submitted to their support team. Aside from our unexplained glitches the area it still lacks is in-depth reporting, making it difficult to gain anything other than basic reports. On the plus side the refresh did give us the ‘conference room’ an area on the staff side of webchat where the team can ‘chat’ to each other when logged on. If I was talking to my boss I’d say that it had enabled peer-to-peer support. In reality it has allowed a sense of community to grow between teams that are based across multiple sites, mainly supported by the swapping of envy inducing cake stories.
So with hindsight I would say that the technology is the least of your problems. The only thing you need for sure is permission to make edits to your website, a helpful IT support team and someone within your library service with a little bit of web knowledge. Yes, your chat box may not be the prettiest of things but actually getting things working is only the start of the battle.
The next issue I’ll look at is opening hours and staffing. I won’t go into the intricacies of our new staff rota, the difficulties of maintaining this across sites and teams and the challenges of engaging staff for whom chat is a new or relatively small part of their roles. Wherever you pull your staff resource from you need to bear one important thing in mind. If you are going to advertise chat between set times than you will save yourself a lot of bother further down the line if you consider it in the same way you would a new service desk. So that means not just considering a rota, but also, cover for breaks and absences, both planned and unplanned, and someone to manage all of this. Chat may never be big enough to be someone’s entire job but it will need resource just like any other forward facing service. It may be ok to rely on the good will of a few enthusiastic and willing team members but sooner or later you are going to find that this isn’t sustainable, normally around the same time you are under pressure for other reasons.
If you don’t think you have the resource to advertise opening times then I’ve always believed it’s perfectly acceptable to provide a service ad hoc, as long as you manage expectations and make it clear that chat will be available on an ‘as possible’ basis. It may not be ideal but the nature of a chat service does mean that it’s very much a ‘here and now’ service. People like chat, but won’t necessarily miss what they’ve never had. What you don’t want to do is offer a service which you may have to reduce or withdraw.
It could be that you have a team who log on when possible, or you could use one of the newer features we are seeing in chats – the ability to instigate a chat with a user browsing specific webpages. You often see these sorts of chats appearing when browsing commercial websites and they do offer an interesting way of offering a proactive chat service without the need to advertise ‘opening hours.’ We quite liked the idea of this but felt that given we do offer advertised hours and have an established and well used chat service we would need more resource to go down this route as an additional feature.
In Part Two I’m going to explore training and common problems we see in handling chats. Hopefully you’ll find it useful!