Google Analytics SHAREit Tip - Request Status: Retry vs. Unfilled - Power Library

SHAREit Tip – Request Status: Retry vs. Unfilled

When an ILL request is not filled during its first go-around through the lending string, it will end in the status of Unfilled or Retry for the borrowing library.

Why Unfilled? When SHAREit places the request in Unfilled, it indicates the item has not and will not be filled by a potential lender.

Why Retry? When SHAREit places the request in Retry, it indicates the system thinks the item could potentially be filled in a future attempt or retry. When re-sending a request, the system populates the lender list with those libraries it thinks might still be able to supply the item.

In both cases, SHAREit bases its decision upon the lender’s selected Reason/Condition for the original Will not Supply response. Lenders have either a) taken no action and allowed the system to automatically move the request along after 4 days or b) indicated they Will Not Supply. During the course of marking the request Will not Supply, they either used the default condition/reason of Omit Reason or selected a more appropriate condition/reason befitting this particular item.

If the condition/reason was terminal in nature (e.g., item is “lost”, item is “not owned”, item is “not lendable per policy”, etc.), the request will end in Unfilled, indicating no potential lender for this item owns it or can lend it.

If the condition/reason is retry-eligible/non-terminal in nature (e.g., library is closed, item is currently checked out, item is in bindery, etc.), the request will end up in Retry. This indicates at least one potential lender could possibly send the item at a future date, so a retry could yield possible fulfillment. In this case, all lenders who could potentially fill the request during a re-attempt are retained in the lending string (all others are removed).

How do you proceed with requests in Unfilled or Retry? In both cases, review the history notes to better understand why the item was not filled. For a Retry request, it may be enough to Approve-Send it after enough time has passed. For Unfilled requests, it is best to delete the request from y