RETRY – Interlibrary Loan

To try or not to try ….

Interlibrary loan staffs have always had a somewhat confused, if not difficult, relationship with the ILL status of Retry.    stack-of-books-small-file-size

A common question I hear from libraries is, “What is the difference between Retry and Unfilled?”   The difference is subtle but important.

Retry means that the Borrower’s request has been submitted to all lenders in the Lender List and could not be filled by any of them, at this time.  This might be because the item was checked out or otherwise temporarily unavailable at the Lender’s library.  Depending on the REASON given by the Lender when the request was set to; Will Not Supply, the request may go to Retry to alert the Borrower that there is still a chance the request could be filled later if it is resubmitted.  The actions available on a Retry request are Approve–Send, Delete, or Cancel.  Any potential lenders that applied a reason resulting in a Retry, are retained in the Lender list to be re-tried again.

Unfilled means that the Borrower’s request has been submitted to all lenders in the Lender List and has not been, and will not be, filled by any lender.  The actions available on an Unfilled request are the same as those available on a Retry request (Approve–Send, Delete or Cancel).  The difference is that an Unfilled request will contain an empty Lender List; so, to apply an Approve-Send action, the Borrowing Library will need to add at least one Lender library to the list.

Some SHAREit consortia encourage their library staffs to never use RETRY.   Those consortia would say that RETRY invites libraries to simply resend the request without thinking – throwing it into an interminable loop.  The problem is that some Borrowing library staff don’t fully evaluate requests that have landed back in Retry, and instead just automatically re-send the request, without looking at History notes or Lender notes or without evaluating the likelihood of it being filled.

shareit-largeSHAREit automatically places a request in Retry or Unfilled, based on the Lender’s selected Reason/Condition for the Will not Supply response.   When changing a request to Will Not Supply, Lenders can select an appropriate Reason/Condition.  If the Reason/Condition is “terminal” in nature (e.g., item is “lost”, item is “not owned”, etc.), the request will end in Unfilled, indicating no potential lender for this item owns it or can lend it.

If at least one library has indicated a Reason/Condition that is “non-terminal” in nature (e.g. item is “in use, on loan,” item is “at bindery,” etc.), the request will end up in Retry.  In this case, all lenders that indicated they could potentially fill the request later, are retained in the lending string while those indicating “terminal” reasons are removed.

Another reason that Retry can be troublesome, is because it is not always evident to the Lender, which Will Not Supply reasons will land the request in Retry vs. those that will cause the request to go to Unfilled.

To address this problem, SHAREit is planning to add hints to the Will Not Supply Reason/Condition dropdown list to indicate which reasons will trigger a Retry rather than an Unfilled response.

How should a library proceed with requests in Unfilled or Retry? In both cases, they should carefully review the History notes and the Lender notes to better understand why the item was not filled.  For a Retry request, it may be enough to Approve-Send after enough time has passed. For Unfilled requests, it is usually best to delete the request.  If the item is still needed and there are additional did-you-know-graphic-small-file-sizepotential lenders, a new request can be started.

Some consortia have indicated to me that they would like to eliminate the status of RETRY altogether, and have all those requests go directly to Unfilled instead.  The thought is that by eliminating Retry, it might cause the libraries to at least think first and evaluate whether the unfilled request should be re-sent to one or more libraries.

A dilemma that I have as the Resource Sharing Product Manager, is to decide when to enhance the product to adjust to libraries’ local wishes and workarounds, and when to help libraries understand how the product can save them time through training and design decisions.

Save

Save

Be the first to comment

Leave a Reply