But if the patron can't/won't pick up the hold then it's wasted labor on the part of staff anyway. Theoretically this would only be used if a person had been on a lengthy hold list and wasn't aware of how close to the top they were, so it wouldn't be an item that was retrieved, just an item that was continuing to route around to fulfill it's hold list. Plus it would still be taking up space on the hold shelf if the patron neglects to cancel it and just allows it to expire, which is what many of our patrons seem to do.

This is nice from a patron service standpoint but I know some of our member libraries would object given space constraints on their hold shelves not to mention the wasted labor on the part of staff retrieving the item and likely sending it through delivery.

I can certainly see the value for other libraries but this would really need to be an optional feature that organizations like us could opt out of.

The item would move onto the next patron in the queue, and the original patron would be reinserted into the hold list according to their original hold placement. Libby requires you to tell it to redeliver after a certain amount of days of your choosing. The function 'not wanted before x date' in Sierra could work here. When the hold is reinserted it would have that not wanted before date.

How do you see this working? Would the prematurely received item move on to the next patron in the queue or somehow be placed in limbo? Would the patron need to manually disable the postponement?