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!
