CC/PS - Add RS Queue on long overdue checkin

Generate an RSQueue message if a book is returned more than a year overdue. Essentially, instead of putting the person into nightly and sending another book out, want to flag the account. And approach to dealing with books that are being returned because the person is deceased, and sending out another book isn't quite what they want to do.

It has been noted that adding an RS reason does not do anything to stop service for a patron in and of itself (unless the patron is on a staff assisted service type).

1. If an item is returned that is extremely overdue, they wan the patron's record blocked from any further circulation. Creating an RSReason does not accomplish that -- reserves can still be filled for the patron on checkin of items from other patrons, serials can still be sent, machines can still be sent, etc. Adding a library-defined block, however, would accomplish exactly what the library wants. And it can work regardless of whether they have k7-PS installed or not (i.e. Resource centers, academic libraries, special libraries, etc. could take advantage of this.) A control file would be added to determine whether the block is added or not.

2. The period of time for which an item should be considered "extremely overdue" should be library-definable, and in fact it currently IS. The blocks functionality has a definition of that.

3. The patron needs to be flagged so that someone will review it. THIS is where the RSReason record will come in handy. Of course this is the only part of the process that would be specific to libraries running k7-PS. The other libraries could use the "Blocked Patrons Report" to find the patrons that have a specific block.

All of this can be implemented with existing schema and functionality in less than half a day of work.

An alternative approach that comes to mind for libraries using k7-PS would need a schema change. But it would be something like this:

1. At checkin of an item extremely overdue, a control file would be added that would state that RSReason records of a specific type should be added. (The RSReason type would be a new field.)

2. The blocks functionality would be changed so that a control file would allow the library to specify RSReason types that should block a patron if the patron possesses a record with that type. By using a block, all functionality for the patron is stopped.

This has the advantage over the first option in that deleting the RSReason will also cause the block to disappear. (The first option would result in libraries to have to delete the block AND the RSReason record.) The disadvantage is that the non-k7-PS running libraries gain nothing by this change.

Here in Oregon we do 6 month audits of overdue books and try several methods of contacting the patron before a book would ever get, for example, 1 year overdue. By the time we have exhausted our efforts the patron's account is blocked and the overdue books are marked lost, so this feature in this specific iteration would just duplicate efforts already made for us. Plus we don't use the RSQueue because we don't have time.

However, the idea that scanning a book can generate an automatic action within KLAS (i.e. blocking an account, but for a different reason) is very appealing. You made it sound like that type of automation can be done without a major upgrade, and can be customized to each library. Is that the case, or did I read the post wrong? Because if it can be done on a case-by-case basis, I'm sure we can think of quite a few ways this type of automation can be useful.

With a small staff, we find the RS Que quite time consuming. Configuring the System-Owned blocks to take on more of a role in blocking delinquent patrons sounds more appealing. I understand the System-Owned Block criteria can be changed by contacting Keystone staff. Where can we view our current criteria and what are the available settings?

Hi all,

In NC we use RS Queue daily. We serve over 11,000 patrons and ship out over 2000 items a day (also receiving over 2000 items a day). Everyone's circumstances are different. We use the RSQueue because we are a large library and have a need to use it. A typical day in our library has the system generating an average of 70+ reasons per the 5 RAs we have on staff. 50% of our patrons are on nightly service and 50% are on other forms of service. Even the one's on Nightly get put on a queue from time to time when they can't be fully served.

One of the reasons we would like to see this feature added is so that we have a chance to catch patrons who may not be responsive to our already failed attempts to reach out to them in getting items back that are over a year due. This basically covers those who may fall between the cracks. If for some reason a patron has a large reserve list (which tends to happen with some folks) or has series reserves or some other automatic trigger we'd like to be able to catch those patrons who have had particular items out for over a year and stop KLAS from sending them anything else until we've had a chance to take action.

Just NC's 2-cents on this matter.