How do students really prefer to communicate, and what should we do about it? Part 1: Email

By Ned Potter, Academic Liaison Librarian 

Tweet 

At the University of York there are audits every few years around student communication. They're conducted centrally by the University, rather than being library-specific. The most recent one was shared with the Library Marketing and Comms Group by York's Internal Communications Manager, and she's kindly given me permission to share the findings here because I think they're absolutely fascinating. They challenge some conventional wisdom, and reveal a lot.

There was a lot about email so this post is devoted to that area; there'll be a part 2 later in the week which covers social media, lecture capture, the VLE and other types of comms.

It's important to note the information was gleaned through focus groups rather than surveys in order to properly capture nuance, so it's not a giant sample size (under 100 people) and inevitably the views reflected will be representative of students engaged enough to turn up for a focus group... But personally I find the findings more useful than generic articles in the Higher Ed press about students of today.

Throughout this article I'll be using phrases like "Students prefer to do X" - the obvious caveat is that I mean "Students at York do X" but I'm not going to write that every time...

How do students communicate? The main findings around email 

1) Email remains the primary and preferred channel of communication with the University

I like this one because it confirms something I've thought for a while - that email is NOT dead. It gets a bad press and it's definitely far less cool than social media, but it still has a function. It's not that students especially love email, it's that they want US - the University and its key services - to communicate key info this way. 

2) Email mainly gets checked on phones, and this happens very frequently

Students check email primarily on their phones, sometimes moving on to a PC / laptop later (see point 3 below). 

Students check their phones for emails first thing when they wake up, last thing at night, and several times in between - many students have 'new message' alerts set up to go to their lock-screens, and will check new emails as they come in even whilst doing other things such as attending lectures.

3) Students triage messages according to 5 criteria 

Students make quick decisions on whether an email gets read there and then, binned, or deferred. They consider (in order of importance):

Relevance - title, sender, and the opening part of the message visible on their phone before they press to open the message; 

Familiarity - do they know and trust the person sending the email? Trusted senders include tutors, supervisors, departmental administrators, the Library, Careers Service, and Timetabling; 

Urgency - does it relate to something important that day or a pending deadline; 

Action - do they need to do something?  (Notice this is 4th on the list of importance...) Interestingly if they do need to do something they'll star the email and find a PC or laptop to log onto and action the email;

Time - if it looks like it can be dealt with quickly they'll read it right away and then delete, file or just mark as read. 

4) The high volume of email they receive is okay, on one condition... it MUST be targeted

Students get a huge volume of emails but they don't mind this as long as the emails are targeted. They object to irrelevant emails and perhaps more so to emails that appear to be relevant but turn out not to be - one example given was an invitation to an employers' event for the wrong subject area or year / status. The sender of that email lost the trust of the students and future emails were deleted upon arrival, unread. 

Any sense of emails happening automatically or without proper thought as to their relevance was met with dissatisfaction. A particular type of email came at the same time each day, suggesting it was automated - this too became one to delete automatically. 

Newsletters and digest emails were read, but often only the first part (too much scrolling and the email was abandoned) and these are the first to go - to be deleted unread - when there's a day with an overly high volume of emails. 

What can libraries change about the way we email students? 

The first thing is don't give up on email. Students expect communication from us to be via this medium, and it was strongly expressed that important information should come this way - key info can be shared via social media but must ALSO be shared via email because it's the one channel everyone checks. The reports of email's death have been greatly exaggerated. 

The second thing is, small details - like titles - really matter. The Library appears to be on the list of trusted senders, but in order to get read you need a decent subject line. (This didn't come up in the audit but I'd argue time of day is important too - if students get a truck load of emails between 9am and 10am, it may be better to join a shorter queue for their attention later in the day at 11am.) Also, because students primarily read email on their phone, you need a very strong opening line. Open your email client on your phone right now - how much can you read without opening a specific email? The way my phone is set-up I get to see about 40 words. So your first few words need to go straight to the heart of the matter - no long intros.

This is obvious, right? We all check emails ourselves on mobiles, we know what it's like. But how many times do we craft emails specifically with the receiver on their phone in mind? I can't speak for anyone else but in my case the answer is: not nearly often enough. 

Thirdly, segment your audience and target them with relevant emails - never include a group in a mass email unless they are directly relevant and would benefit from the info. If an email isn't essential to anyone, does it even need to be sent at all? There are too many emails that are sent out not just to the relevant people but to a smattering of less relevant people too. Every time we do that we diminish our value as communicators - our currency - and get closer to joining the dreaded auto-delete list. 

And related to that, reduce automation because it suggests we're not trying hard enough to avoid wasting their time. It's very hard to think carefully whether or not to send an email if it's automated. I've always said we shouldn't send newsletters out at the same time each week or month - it should be because we have a critical mass of useful things to tell our audience, not because 'it's the time we send out the newsletter'. So anything automated should at least be reviewed to make sure it's still serving a worthwhile purpose and not alienating our users. 

In Part 2 of this post we'll look at the (surprising?) popularity of the VLE, the love-affair with lecture capture, and where social media fits in with formal communication. 

The CRM at York: what it's for, how it works, and what it looks like

By Michelle Blake, Head of the Relationship Management Team

From time to time I get asked about our Customer Relationship Management system which we use at York. I thought it would be useful to share what we’ve done and why with the community (using some of the questions I get asked as the basis for this blog post). My colleague Steph Jesper, who built the system (based on Google Apps suite of tools) will follow this post up with one in December about how she actually built the system itself.  

The different components of the CRM

Background

In 2014 as part of the reorganisation of the Relationship Management Team we wanted to implement a Customer Relationship Management (CRM) system in order to ensure that all staff knew what activity was taking place across the team. This was important as we were moving from quite a traditional liaison team model (based on clusters, like faculties) to a functional approach based around 3 teams - Academic Liaison, Research Support and Teaching and Learning. Staff were concerned about not knowing what was happening as meetings would be required with departments from each of the different teams.

We started by trialling a commercial product which integrated with Google (as we’re a Google institution) but it did not meet our user requirements and success criteria.  Due to limited budgets for such a system we decided to build our own system using Google Apps. A member of our Teaching and Learning team led the development of the CRM over Summer 2014, ensuring that it integrated team priorities such as our action plans so that as much as possible everything was in one place.

What the CRM does

The screen which greets anyone adding an entry to the CRM

In summary our CRM allows staff to provide summaries of meetings, phone calls and other interactions they have with departments in order to help with information flow and ensuring that all members of the team are aware of what is happening. This provides several functions:

• If a member of staff is off sick other members of the team know what is happening;
• The CRM provides automated alerts based on flexible criteria e.g. an Academic Liaison Librarian (ALL) can set up an alert for a particular department (then if someone from Research Support meets with their department they will find out automatically - and vice versa);
• ALLs can update their action plans directly in the CRM - saving time;
• Managers and other staff can look to see what activity is happening and taking place in the team;
• The information within the CRM can be used to directly help make changes to services or processes e.g. Subscriptions Review process was reviewed with information being fed into one system making the analysis much quicker and easier.

Over the last year we've expanded use of the CRM across the Library, primarily to staff in professional roles in Customer Services and Collections Services as well as the Senior Management team. They mainly use it for keeping up-to-date purposes rather than adding lots of entries themselves (e.g. our collections staff knowing what discussions are taking place about reading lists or new courses). Feedback has been great and it makes it far easier for everyone to see the work which RMT do - which can otherwise at times be quite invisible (relationship building often is, as it often takes a lot of time).

Our CRM is focused on interactions with academics and student bodies but not students themselves. This is intentional as we want value-added transactions that are useful for people to know about so we don't add everything e.g. we don't add things like academics asking for a book to be ordered but would add something about a discussion to change the skills session that we deliver. What we would call day-to-day transactions are instead in the subject emails (we have subject emails for each department rather than individual/personal accounts as we have so many part time staff particularly in our liaison team). We have quite a different team ethos at York than a lot of other HE libraries - it's very much a team effort and people aren't just responsible for departments where they are the named contact (although these ones are obviously the focus for them, they are expected to ensure the service is consistent across all departments and to pick up emails etc. when people are on leave, for part time staff etc).

What did we want to achieve?

There were a few things we wanted to achieve but first and foremost was ensuring all the team knew what was going on across departments so they didn't turn up to meetings etc. not knowing their colleague had been there the week before doing something else. It's also a useful way for people to stay up-to-date about their own area e.g. a liaison librarian can set up an alert to be notified every time someone sees someone in their department, say Chemistry. So if a colleague in Research Support went to talk to the department or had a meeting with an individual, they would add this to the CRM and it would automatically email the liaison librarian telling them about the interaction. It means staff don't have to remember to tell everyone who they talked to. You can also set up alerts based on keywords e.g. Open Access or categories we use e.g. Student skills. Again this means that staff in Research Support or Teaching and Learning can then keep up to date with what activity/conversations are happening in departments.

It's important to say here that the CRM isn't a replacement for talking to colleagues and there is a clear expectation that if, for example, a liaison librarian talked about research support and suggested they attend an upcoming meeting, that they would then go talk to them in person about this.

Automatic summaries of interactions

From a manager point of view, it’s possible to view all activity taking place across departments without having to ask. It’s possible for managers like myself to then make connections in a way that individual team members often can't because they aren't seeing everything (and there is no expectation they should) e.g. suggesting that people are doing similar work or they should talk to so and so (which may not be obvious to them). Sometimes this might be making connections outside of Information Services too e.g. with our colleagues in the Academic Support Office.

It also means if staff leave/go on holiday etc we can easily see what's been happening in the department. We had a new member of staff start in our liaison team in December 2015 and she was able to look at what activity had been happening rather than us relying on someone remembering everything that had happened.

It also acts as the central repository for our annual department action plans. This is important for the liaison librarians as they can easily update the work they're doing on action plans with the CRM.

All of these things it does brilliantly.

Reporting

In addition, I wanted to be able to do some smart reporting. This is something we are only just starting to play with (mainly because of time/resource issues). However, it's already proving useful e.g. we can get data about who is seeing who and what about (which areas are most popular) and we will be able to track this over time to see if it changes; which departments do we have both most interactions with (this isn't necessarily good or bad but rather having this information means we can then contextualise it e.g. lots of interactions might be bad because of some issue they have with us but likewise if we're never seeing the department that's probably not good either!). Also do we see a lot of staff in the department or is it just one or two (I would argue you want a decent amount of penetration within the department so you aren’t getting a skewed view of it). It also means we can look across departments and start conversations about why the activity is so different - this is really interesting and means staff can learn from each other. Currently we have only started looking at reports like this with the liaison team but we are keen to also investigate how we can better use the data with both the Teaching and Learning and Research Support teams.

A potential way to visualise the data in future

Do you have any advice for a Library at the beginning of this process?

Really think through all the systems you have, what you'll use it for, how the categories will work (define them and make sure people use them consistently). We have an enquiry management system (LibAnswers), departmental (rather than personal) email addresses, a system for 1:1 student appointments (Target Connect) and the CRM. We are clear (and have gone back to rationalise) what each one is for and how they interrelate to each other - always checking they are all still needed. We have put guidance together about how we intend it to be used etc. and we revisit this usually annually.

Make sure you use the data that it gives you and show the staff inputting that you're using it. The CRM took a while for people to really put everything in because this wasn't happening to start with (primarily to do with staffing and time); however, once people saw it was being looked at/used they got much better at inputting what they were doing.

Amazingly our system came at no additional cost to the institution (or Information Services) which meant that we had little/no opposition in implementing it. It used tools we already had (Google Apps) and is easy for the team to use - including while on the move.

Who else is doing this?

I am aware there are other institutions who are using CRMs, either their institutional CRM or an in-house system. If you’d like to share what you’re doing, I’m sure the community would love to hear about it.

Can I see it?

Last year I presented on our CRM at both the Northumbria conference (July 2015) with my colleague Steph (who built the system itself) and at the first Relationship Management conference (November 2015). I've put the screenshot examples from that presentation throughout this post.