How does your library manage requests? Item-level requests versus Title-level requests?

Good day all,

I have a few questions as to how libraries manage requests. Your responses will help confirm current backlog prioritization.

1. How does your library manage requests?
a.) Title/instance level only
b.) Item level only
c.) Both

2. If you selected c.), can you provide details as to your current workflow for managing item and title/instance level requests?

3. If you selected c,) what % of your requests are title/instance level versus item level?

Thank you for the responses

Regards,

Khalilah

Khalilah Gambrell
Folio Product Owner, Users Management, eHoldings, and Accessibility

Having worked with setting up Aleph, Voyager & Alma, these older systems have always supported c) both title/instance level and item level holds/requests. These Ex LIbris implementations would support and allow the individual library to apply their local policy.

As a public library patron, the Minuteman Library Network (in Massachusetts) uses Innovative Sierra and allows only title-level requests. I would posit that the average librarian/reader does not care which copy of the popular book is provided (as long as it is the fastest copy to my hands).

As a former circulation librarian in several different academic libraries, item level holds for books can be challenging if a specific copy is held by a faculty member who may not play by the average patron rules for hold/request.

The one place where item specific holds is useful is for bound runs of journals/serials. Being able to request a specific item/volume/issue shortcuts the process. Of course, a title level request can quickly overcome that if there is a free text/additional information field allowed within the hold/request form.

My experience (as a user, a librarian & ILS/LSP implementor) is that allowing title level holds is the more common policy (except for bound journal runs in academic libraries).

Hope that’s helpful.

Marc Keepper
FOLIO Training Manager, EBSCO

Item level requests are critical for multi volume sets and titles with multiple types of items attached (book, CD, kits).

Free text fields reduce that criticality, but I appreciate the follow up.

Khalilah & Tania: Do we have metrics from different types of libraries on the ratio of book-to-multi-volume requests?

Will title level & item level both be available in FOLIO from Day 1? Or is there a prioritized release planned? Or is that being considered/evaluated even as we discuss?

Thanks, Marc

The existence of free text fields hasn’t so far reduced the error rate when filling a title-level request for one volume of a multi volume set. Humans really don’t pay enough attention to them. My cite? I help support a state-wide ILL system.

The current priority order for designing and implementing requests is Item first, title after.

I agree state-wide ILL systems are an absolutely valid use case. I also agree that human patrons don’t necessarily use the free text field as we might hope.

I would still ask for numbers. Are we designing & prioritizing for the 10% of requests (or 5% or 18% or 1%) which are part of a multi-volume requests?

I worked with Princeton’s library - they have Voyager and only allow recalls, not requests, which are on the item level. They are considering not allowing any recalls, because of the difficultly of that faculty loan, and because there are usually many other ways to get the material - in their case Borrow Direct, etc.

We have been using title level requesting in ALEPH. It dose allow selection of a item if it is a multi-volume set. However we have had a number of issues with title level request and see some of the advantages with item level request

In Hamburg we have OCLC-PICA LBS and our libraries would love to support both types of requests. Since title level requests currently do not properly support locations, many libraries stick to item requests though.

Thanks, Patty. Did that “no requests” hold true if/when the item was in remote storage, like a Harvard Depository model or the ReCAP project? In the ReCAP use case for Princeton, how was the remote storage request handled?

We (University System of Maryland & Affiliated Institutions) do title level requests in Aleph with the ability to specify an item in a multi-volume set as Steve B. mentioned. I’m pretty confident we would want to maintain this functionality in a new system. The lack of title-level requests was seen as a pretty significant issue back in the day when we were looking at some other systems that I won’t name.

Ideally, both request types would be available to the user. Title-level requests reduce decision-making for the user and potentially gets them an item faster than if they chose an individual item (i.e. a checked out item gets returned while an ‘available’ item turns out to be missing). Item-level requests put more control in the user’s hands (for better or worse).

At the University of Chicago we only process item level requests, and would in fact possibly need a way to disable title level requesting. That having been said, title level requesting is certainly on the roadmap for FOLIO, in my understanding. And in terms of development, it would seem to me that many aspects of item level requests (the ability, ultimately, to place a specific item on hold for a specific patron) are necessary elements of both item level and title level requesting, and thus will have to be developed at the outset regardless.

We have recently moved away from allowing patrons to recall items at all–patron requests are handled via ILLIAD, and a copy is obtained via ILL (assuming no local copy is available) or recalled by staff if it can’t be obtained quickly via ILL. We increasingly rely on our ILL partners for requesting items that are otherwise unavailable.

We don’t provide a paging service, so title level requests for available items aren’t currently an issue for us.

In terms of any library that operates its own high density storage facility, item level requests are ultimately a necessity.

Thr Princeton team handled availability and requesting through their discovery/web platform. A checked-out on-campus item would show as unavailable and a link would open to re-direct to Borrow Direct or ILL. Items that were stored remotely and were available in the facility could be requested, but the button opened a form that allowed the borrowing of a physical item or the request of an EDD. The middleware would place the item-level hold in the Voyager system using ESIP, so when the item came on campus it could be checked in and the hold would be trapped for the patron. From the time of the request, the item would be made “unavailable” and no holds were allowed. (The middleware does not support a hold queue.)

At Duke we are currently only using Item level requests. We’d love have both, since managing request queues for high-demand titles with only item level requests is a pain in the neck and doesn’t serve patrons particularly well.
But we are unable to manage recalls, multi-volume requests or requests from our off-site storage facility with title level requesting.

So we’d love to have both, but if we can only have one it needs to be item level.

At Cornell (Voyager shop), 95% of our requests are item-level requests. In our Blacklight catalog, the system requires you to choose a copy (“any” is not an option). Staff, working in the Circ client, are able to choose Title-level, which is useful, so I would not want to take that option away. But item-level is certainly the option I would want if forced to choose.

I would also add that sometimes patrons really do want a particular copy. We currently manage our special collections requests through AEON, but if we weren’t we would want patrons to request a particular copy (and they are required to do this through AEON).

Jessica

Hi Khalilah.

The option is the letter C.

In my experience, both giving technical support for Aleph and ALMA in Latino/America, the hold request by item is the most requested.
the title request option is commonly used when all items are loaned and to facilitate that the user can receive the first item returned should enable the hold request for the title/instance.

José Alexander Soto

Apologies if this is beyond the scope of this post, but the Consortia SIG talked about item/title requests in a bit more detail, and I wanted to pass on some highlights.

• In terms of use of title vs. item requests, some consortia in the SIG offer both types of requests; if only one is offered, title-level seems to be more common
• In one interesting case (PALNI), title-level requests are placed and rather than having routing rules determine which library should fill the request, the request shows up on pick lists for libraries that have a matching item. (The data is real-time, so as soon as someone fills the request, it’s no longer a valid request for the other libraries, which avoids the potential for sending multiple items for a single request.)
• In a consortial setting, for either type of request, it’s important for the system to take into account loan rules when picking an item (title-level requests) or allowing a patron to choose an item (item-level requests). Some consortium patrons may be restricted from requesting certain items (by collection, material type, etc.).
• For title-level requests, it seems like in all cases the first level of priority should be for an item available from the home library (rather than shipping an item from another library when a copy is available locally).
• For either type of request, patrons should be able to set their default pickup location (and override it on a case-by-case basis). By default this should probably be a “home library” to start.
• Many libraries have local routing processes once an item arrives from another institution (e.g. departmental delivery, delivery to satellite locations, etc.). These are typically not managed by the ILS; it would be nice if they could be.