For 3.2, LibLime proposes to add a feature to target specific items to fill hold requests. This targeting, which would be done in conjunction with use of the holds queue batch job (build_holds_queue.pl) and its report, would allocate items that are sitting on the shelf to fill specific hold requests.
The idea is that the library would run the holds queue report periodically, then use the report to pull items off the shelf in order to fill hold requests. When the report is generated, the batch job would also populate a new table (to be called hold_fill_targets) that recommends that specific items be used to fill specific hold requests. As items from the picklist are checked in, if the item is targeted to a specific hold, it would be used to fill that hold first instead of filling the request that happens to be at the top of the priority queue.
Why do that? Suppose that a bib has two items, itemA and itemB, and suppose patron1 has a title-level request on the bib, and patron2 has an item-level request on itemB. Further, suppose that both items are available, meaning that both requests could be filled.
At present, whether both requests are actually filled depends on the order in which the items are checked in. If itemA is checked in first, then patron1 gets it, and when itemB is checked in, patron2 gets it. Everybody is happy. However, if itemB is checked in first, patron1's request is filled, but patron2 is left waiting for the item.
With the new targeting feature, the batch job will allocate items to fill particular requests, thus allowing all of the available items to be used to fill as many holds as possible, in priority order. The mechanism does assume that the library's workflow is to run the batch job, then *quickly* pull the items to put on the hold shelf or transfer to other branches.
This mechanism will also be used to minimize the number of transfers by allocating items located at a branch to fill requests for that same branch.