Interlibrary Loan Service Integration: fit for the future

This post is a response to Daniel Payne’s article, “The something service: on calling interlibrary loans interlibrary loans” which is well worth reading. 

https://www.flickr.com/photos/certified_su/

I would say that what @lyhairian does in his final remarks is actually nail down the real issue - we have allowed this service (whatever you call it) to become its own entity that we think needs presence and external promotion. It doesn't, and UK ILL shouldn't be the uncultured monster it has become. In part I might put this down to software that has enabled it to be isolationist within the library ecosystem.

Primarily it should just be an internal support mechanism for some of the core activities of libraries, namely: supporting research; developing collections; delivering content. To contextualize that: Research Support; Collection Development; Procurement & Access. 

• Research support teams are the experts at liaising and guiding people to resources and services available to support their research.
• Procurement and access teams are the experts in acquiring content and delivering access to it to meet demand.
• Collection development teams direct the development of unique content holdings through expertly identifying and predicting future needs. They also react to previously unknown needs by responding to recommendations from staff and students.

There is a role for ILL to plug the holes in local library collections, but it should never be working in isolation from collection development and support activities themselves. No library can own everything. Equally, we are still a long way from all material of possible research value being available digitally - be that for free or by subscription. Yet Open Access (OA) marches on and we will increasingly be able to direct people to repository versions of published papers, as well as OA versions on established publisher platforms.

ILL service teams, still very much working with a mindset that deifies physical material, are a seperate cost burden that distract from greater efficiency that could be gained by integrating with these other core areas. To the customer, unfamiliar with library vernacular, the service should be little more than a boutique and bespoke solution for the vague materials that can't more easily be catered for through:  

• Better utilisation and knowledge of available and local resources 
• Intelligence driven on-demand acquisition
• Improved provision of digital access to content through whatever means available

I've written elsewhere on intelligence-driven on-demand acquisition, but from the perspective of the customer it has a significant element that we can all identify with. Through engaging with a responsively managed service we feel respected, listened to and influential. Lending a hand in developing a collection is something that the customer can derive satisfaction from, and also allows the library to more easily engage with its customer base, maintaining its relevance in an increasingly complex world. The ability to add value to a service through a responsive and engaged approach is, to me, essential to what a library offers.  

Let's make the service that shall not be named the boon of the library's core services and not a secret island of plenty for those who happen to know about it. 

But how should we express this service to our end-user? 

My answer is simple, and in the context of the above thinking - we shouldn't. The service is a request service and what we should be doing is making it as simple as possible for customers to tell us what they want. We then, within our normal core operations processes, take care of that by advising or delivering it to them. It really should be that simple. We don’t need to explain something to them in the terms of library jargon or a process; we need to provide excellence in delivering what they need.

How we would do this requires another posting. Simply put, it would involve: a decent discovery layer with quality metadata behind it; a link resolver; a single-stream access point for recommendations and requests; thought-through technical solutions; consolidation of a number of services, and a group of concerted problem solvers. Not really that much hard work to finally bring an important component of library service back into the fold and fit for the future.