Requests (UXPROD-790)

[UXPROD-4056] Requests: Rush requests Created: 09/Feb/23  Updated: 04/Jan/24

Status: Draft
Project: UX Product
Components: None
Affects versions: None
Fix versions: Umbrellaleaf (R2 2025)
Parent: Requests

Type: New Feature Priority: P3
Reporter: Stephanie Buck Assignee: Anne Ekblad
Resolution: Unresolved Votes: 0
Labels: LC6, loc, requests
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to UXPROD-4119 Private requests (Congressional loans) In Progress
relates to UXPROD-4657 Mediated requests phase 1 (Base app./... In Progress
Release: Not Scheduled
Epic Link: Requests
Front End Estimate: Large < 10 days
Front End Estimator: Khalilah Gambrell
Back End Estimate: Large < 10 days
Back End Estimator: Khalilah Gambrell
Estimation Notes and Assumptions: Depends on approach. If using Tags should not take too much development.
Development Team: Vega
PO Rank: 0
Rank: Cornell (Full Sum 2021): R3

 Description   

Current situation or problem: Certain requests come in as needing to be filled quickly (specifically for particular people or groups)  and staff need to know how to identify this type of request as a Rush request. 

  • Congressional borrowers are the only borrowers who can have Rush requests, and not all Congressional requests are a Rush
    • Rush is designated when Congressional borrower indicates request needs to be filled urgently
  • Other institutions may allow rush for certain patron groups, or want to do it only for certain individuals
  • Rush requests are not very frequent but when they occur they are the top priority 

In scope

  • A way to flag / identify Rush requests so staff members see they need be filled as quickly as possible
  • Request App.-focused feature - used for swift pulling and retrieval

Out of scope

  • Possibly out of scope = Transit slip - Currently, communication about a Rush designation for requests for items in offsite locations is handled through staff email correspondence

Use case(s)

Patron A has special access to collections. When Patron A requests an item it needs to be retrieved as quickly as possible

Proposed solution/stories

  • Solution Idea A:
    • Use a tag for "rush"
    • Pass the tag along with the barcode to remote storage system so they can prioritize those items
    • For onsite stuff:
      • Add "request tags" token to pick slips. They'd put the token in bold at the top of the pick slip which would work pretty well, unless there are other tags associated with the request. This is one drawback of the Tags approach.
      • Would be nice if the page request pick slips could be filtered or sorted to only show the ones with a certain tag. Otherwise the service point staff will have to manually look through the pick slips and pull out the ones with "Rush" at the top and get those first.
    • Downsides:
      • Tag token on pick slip can be kludgey when you really just want to show "Rush", not all tags
      • Concerns about tag permissions not being granular enough (administration wants the ability to control who can create new tags vs apply existing which we don't yet have)
      • Offsite staff (or system) would have to sift through all the tags to find rush in all it's permutations 
    • Questions:
      • **Could we potentially program the discovery integration so that the tag is automatically applied for requests from certain patron groups? Automatic flagging of certain requests as rush is a nice-to-have
    • Tag as filter, print rush pick slips first ( UXPROD-4047 Closed )
  • Solution Idea B:
    • Add a simple checkbox to the request form for "Rush"
    • Add column to requests search results for Rush which can be sorted
    • Add filter for Rush so you could filter
    • Automatically sort pickslips with Rush flag at top (or make this an optional setting)
    • **Could also add a setting that allowed requests from certain patron groups to be set as Rush by default
    • Make rush request attribute rather than tag
      • enable or don't setting
    • Question:
      • How does this work via OPAC? (maybe patron group?) - Internal staff are the only ones that can designate a request as Rush. A patron can submit via discovery but will have to call/contact to ask that it be a rush.
  • Potential solution:
    • When placed through OPAC, comment added as Rush, specific time, asap - box marked rush
    • Viewed by technicians - could this play into solution?

Links to additional info

This is the old Rush recall feature the community wanted (though it was never prioritized): UXPROD-1409 Draft

Notes

  • Not all Congressional Loans (CL) are Rush
  • LC takes location of item into consideration - the farther away an item is housed the longer it takes to retrieve

Questions

  1. If all requests are retrieved or noted otherwise within an hour, is "Rush" the designation required?
    • Yes, specifically for off-site requests
      • need to be able to sort by rushes in FOLIO before printing pick lists
    • Yes, record keeping - what's been identified by patron as a need for rush 
  2. How do we permission rush to just congressional patron groups?
    • Proxy & direct (select patron group)


 Comments   
Comment by Erin Nettifee [ 14/Feb/23 ]

Stephanie Buck - should we close UXPROD-1049 Closed if we're not going to work on requirements there?

Comment by Stephanie Buck [ 14/Feb/23 ]

It looks like that feature was closed as Done in 2018. Did you mean to link to UXPROD-1409 Draft ? If they end up to be the same requirements and work, I'll close one of them. I'm still working through everything to figure out if they are. 

Comment by Erin Nettifee [ 15/Feb/23 ]

Yes, sorry - I meant 1409.

Comment by Thomas Trutt [ 09/Mar/23 ]

All our patrons would mark their requests as rush..  

I like the idea of being able to tie this to a patron group, perhaps via the requests policy in the circulation rules. That way you could also pinpoint specific collections or item types. IE All faculty requests from OLIN fro 'Books' are marked as rush.

Q: would this also affect loan periods? ie 'Rush' recalls have a 7-day recall period instead of 14-days? I would make the argument yes as it could be used by groups like reserves staff.

Comment by Anne Ekblad [ 18/Jul/23 ]

Following impact and workaround discussions with Library of Congress that included LC staff, EBSCO Product Owners and EBSCO FOLIO LC Implementation Lead Steven Backs, this feature was lowered in priority to an LC4. It is not expected for Go Live, and the projected release is now TBD.

Generated at Fri Feb 09 00:36:55 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.