Aeon in Focus - Duplicate/Problem Request Feedback
As a continuation of the conversation begun during the Aeon in Focus webinar on 12/12/18, we are seeking feedback from the Aeon community regarding duplicate/problem request functionality.
Main questions:
- How should we match requests?
- What options should be used to mark requests as duplicate or "next"?
- What additional statuses or workflow steps are needed?
Feedback from webinar:
- preferred fields to match on: call number + box (ItemVolume or other field), barcode, ArchivesSpace ID
- would be useful to check items against active queues (i.e. In Item Retrieval, Item on Hold, Item Checked Out, Awaiting Item Reshelving and anything in an equivalent state code)
- need way to see what the matching requests are directly on the duplicate or problem record (a tab, for example, that displays matching requests)
- visual indicator (like a flag) that would indicate a request is a duplicate
- could use new queue like "Item In Use" to indicate that item already on hold or checked out to a patron has been requested by another or multiple patrons
Please add additional questions or comments below. As the development process continues for this feature, we will update this post or ask additional questions. Thank you in advance for your feedback!
Comments
I think we are kind of in the same mode of thinking that Marilyn is:
We're also not entirely sure what they best way to go would be to indicate a problem request. I'm leaning more towards the "flags" idea. Conceivable, a transaction could have more than one problem, so a very visible indicator could be useful. For example, a collection could have an access restriction, and be off site, in use, etc.
In the spirit of mock ups - here is one that I threw together:
Of course, it wouldn't have to be like this, but the main idea is that the flags are highly visible. Perhaps they just have a colored background? Just being able to draw attention to issues, though, has been a big request of our users.
-Matt
We would really like to have a tab that would display "matching requests" either for any request or just for requests that our outstanding (where outstanding would defined in the same way it is for the outstanding requests table in the web interface). We've created the attached mock-ups of what the tab would look like. It's helpful to be able to check "matching requests" at multiple points in the process and not just when the request is submitted, so having the tab present at all times or at least until the item requested is going back to the shelf would be helpful.
We'd like the field (or fields) that Aeon uses to match requests to be configurable by institution or, even better, by Site. For example, we have some Sites that rely heavily on call numbers to identify items, and others where a large portion of the collection doesn't have meaningful call numbers. If an addon-type approach is taken to create the matching requests tab, the fields to match on could even be in the individual user's config settings for the addon.
We have differences of opinion about the utility of the routing rules. It can be helpful to have an immediate indicator (i.e. one that doesn't require opening up the request) that a request may be a problem or have a match, but we also have a proliferation of problem queues that can be a challenge to manage. Another idea we had was to automatically flag newly submitted requests as potential problems instead of routing them to a problem request queue. The flag would be visible on the queue grids, so you could easily see which requests might be a problem. If a request were only automatically flagged when it was created, staff could simply remove the flag if they determine that there is no real conflict and continue to process the request as usual.
Matching requests using unique identifiers like barcodes would be the best option for books. Additional fields that would be helpful for archival collections as well as books would be title, box number, call number, and volume number. Title comes in handy for unprocessed collections and uncataloged books.
Requests for items already paged could be marked by being routed to a "next" queue called Already Paged, Existing, etc.
It would be helpful to know what transactions matched so we can identify where an item is, who it's on hold for, if it's waiting to be reshelved, and so on.
Requests that automatically route to the "next" queue could be cancelled if they happen to be for the same patron or processed as they would be for any new request with the addition of steps unique to each institution for how they "page" items already pulled under another transaction number.
Additional fields to match on: User name; Item Issue
Yes a Flag to group the possible duplicates
The tab of duplicates in the request record seems the most convenient location for that information and would be very helpful. Even if it just linked TNs or maybe has a link to open up a grid view of what the System found so staff could see all the duplicates and have the list-sorting capabilities in a larger window view rather than the smaller request window.
It would also be helpful if the System searching duplicates took into account mis-typed manual or catalog requests so it searches, for example, box1 as well as box 1 from a single collection
Hi Ayat and Iris,
Thank you both for your feedback! We are working on doing some further research into this functionality. I'll keep you posted here and or comment if we have additional questions. Please let us know if you have any other thoughts!
Best,
Katie
This would be wonderful for us as well! I spend considerable time trouble-shooting duplicate requests. Not just duplicate for the same patron but already on hold (or some other "active" status) for another. We have the added difficulty that our storage facility's software ignores requests for barcodes that are already out. To that end, I would appreciate it if the matching flag displayed in the list view (new requests, etc.) so that I could see that this issue is present without having to open every request. Not sure what this would look like (and I don't have a lovely mock-up) but would really aid us as we are a high-volume SC!
It would be great to help identify matching requests using a highly visible flag or tab at the top of the transaction. We run into this issue a lot with materials that are requested by researchers but are currently pulled for instruction/activities. We want to identify the duplicates quickly and take clear action on them. So for example, we currently make a note in Aeon or on the call slip to indicate that the item is on hold elsewhere, but those are a bit cumbersome and can be overlooked. If we can automate that process, it would be easier for reading room staff. Since we have times when one item is requested by several users, having a tab with all the match requests is an exciting idea. That way, if several students from a class are requesting the same box(es), we can convert their request(s) to an activity an place the item(s) on a group cart. Love the suggest mock-up views!
Please sign in to leave a comment.