Patron Service

• 5/20/2021 KLAS Users' Roundtable: DoD Tips & Tricks for Serving Patrons

  

  Below is the recording and chat transcript for our KLAS Users' Roundtable: Duplication on Demand Tips & Tricks for Serving Patrons that was held on Thursday, May 20, 2021. (57:24 Run Time)

  Chat Transcript

• 5/20/2021 KLAS Users' Roundtable: DoD Tips & Tricks for Serving Patrons

  

  Below is the recording and chat transcript for our KLAS Users' Roundtable: Duplication on Demand Tips & Tricks for Serving Patrons that was held on Thursday, May 20, 2021. (57:24 Run Time)

  Chat Transcript

• Duplication on Demand: What works best for you?

  

  Many KLAS libraries are already wrestling with (or soon will be) the challenges of reduced space to house their collections and / or less circulation and support staff. With these issues and other in mind, we designed KLAS' Patron Centric Cartridge functionality to provide library staff with the ability to quickly select and reproduce a specific set of books onto a cartridge for a specific patron.

  While this works well for many libraries, we know this is not the best option for ALL organizations.

  In our discussions at Keystone, we have identified at least three different duplication on-demand workflow scenarios including two patron-centric and one title-centric:

  1. A single cartridge tied to a single patron which is reloaded with books for that patron each time it is returned.
  2. Cartridges that are loaded with titles based on a single patron's preferences but are not tied to one in particular. Rather, whichever cartridge is available at the time is loaded with the patron's books.
  3. Cartridges loaded according to inventory (Examples: The Harry Potter Series, Nonfiction titles added in the last 30 days, 1 year of Southern Living)

  Some questions we have as we prepare to move forward with providing additional duplication-on-demand functionality within KLAS are:

  1. Do any of these options appeal to your organization and how it operates more than another?
  2. What considerations do you think need to be made for each?
  3. What specific challenges and / or benefits do you think you may see from operating under each?

  Please share your answers / thoughts / feedback on the "Duplication on Demand: What works best for you?" klausers.com discussion forum thread.

• Front Desk Service

  

  Do you make use of the Front Desk module?

  A recent update added the patron Contacts tab, replacing the address section of the Patron Data tab to ensure there are no discrepancies between the data stored in the Patron and Front Desk modules. We've also done some work to sync the functions available for the Service Queue and Orders tab, so everything you need is in both modules. 

  All this got me thinking about the Front Desk more generally, and how it's used.

  We created this module to (you guessed it) service a library's front desk, where staff need easy access to both quick check-in and check-out and basic patron maintenance functions. While the Front Desk module is designed for handling walk-ins, I think it's also great for those doing a mix of circulation and patron services, and who don't need or want to learn the full patron module. Part timers and volunteers may find Front Desk has everything they need, without as much of what they don't. 

  To help those only needing to help the occasional walk-in at a front desk or an outreach event, we created the Front Desk Service Manual. While it does stray outside of the Front Desk module where needed, this guide is intended to grant quick-and-easy access to the top patron service functions. I hope it will help those who need a little refresher or a touchpoint as they perform occasional customer service tasks. It is formatted to be printed and put in a binder, but also intended to be Screen Reader friendly, with the keystrokes needed for an AT user to complete tasks just as conveniently as sighted users.

  Initially targeted for a specific library with a higher need for it, I'm now putting it out for general use. Please let me know: is this missing any common tasks for front-desk, part time, or volunteer users? Do you need a Gutenberg version? Also, beyond the document itself, I'd love to hear if and how you use the Front Desk module!

  Notes for printing: 

  • If printing for a binder, ensure all two-page sections will be open spreads by printing the first page single-sided. Then print pages 2-14 double-sided.
  • If you are not a Scribe library, remove those sections from the table of contents by deleting pages 13 and 14. Then right-click anywhere in the Contents section and select "update field."

• Front Desk Service

  

  Do you make use of the Front Desk module?

  A recent update added the patron Contacts tab, replacing the address section of the Patron Data tab to ensure there are no discrepancies between the data stored in the Patron and Front Desk modules. We've also done some work to sync the functions available for the Service Queue and Orders tab, so everything you need is in both modules. 

  All this got me thinking about the Front Desk more generally, and how it's used.

  We created this module to (you guessed it) service a library's front desk, where staff need easy access to both quick check-in and check-out and basic patron maintenance functions. While the Front Desk module is designed for handling walk-ins, I think it's also great for those doing a mix of circulation and patron services, and who don't need or want to learn the full patron module. Part timers and volunteers may find Front Desk has everything they need, without as much of what they don't. 

  To help those only needing to help the occasional walk-in at a front desk or an outreach event, we created the Front Desk Service Manual. While it does stray outside of the Front Desk module where needed, this guide is intended to grant quick-and-easy access to the top patron service functions. I hope it will help those who need a little refresher or a touchpoint as they perform occasional customer service tasks. It is formatted to be printed and put in a binder, but also intended to be Screen Reader friendly, with the keystrokes needed for an AT user to complete tasks just as conveniently as sighted users.

  Initially targeted for a specific library with a higher need for it, I'm now putting it out for general use. Please let me know: is this missing any common tasks for front-desk, part time, or volunteer users? Do you need a Gutenberg version? Also, beyond the document itself, I'd love to hear if and how you use the Front Desk module!

  Notes for printing: 

  • If printing for a binder, ensure all two-page sections will be open spreads by printing the first page single-sided. Then print pages 2-14 double-sided.
  • If you are not a Scribe library, remove those sections from the table of contents by deleting pages 13 and 14. Then right-click anywhere in the Contents section and select "update field."

• Getting Smart about Series

  

  This is a guest post by Sam Lundberg - Reader Advisor for the New Mexico State Library for the Blind & Print Disabled, and current President of the KLAS Development Advisory Committee.

  We’ve had a lot of interest recently from across the community for Nightly AutoSelect to be more “series smart,” and not send book 3 in a series before a patron has had book 1.  I’m among the chorus that’s been asking for this since the beginning of DoD, but I think it is worth talking about exactly how we want this to work.  There are a lot of different ways that Nightly could be series smart, each with a different impact on the patron experience.

  I’m going to lay out a few of the ways that I’ve thought of, along with advantages and possible drawbacks. I’d love to hear what others have been thinking on this subject, and I’m sure Keystone would appreciate knowing exactly what we want, rather than a vague mission to make it better.

  As a preface, I have no idea how practical any of these solutions are from a programming side.  I’ve tried to lay out specific rules that an algorithm could follow, but that doesn’t mean they would be easy, or even possible, to put in place.  Some of these rules may also bog Nightly down to a crawl, requiring more time to run each night.  This is a thought exercise to figure out exactly what we, as a community, want, rather than a menu of actual possibilities.

  Option 1 

  1a) “First in the series only”

  • When Nightly picks a title by Subject, it checks the “series sequence” field and excludes any book with a value greater than 1.

  This is basically what is accomplished by libraries that use a “Sequel” subject code.  Autoselect wouldn’t send out any sequels, which would exclude a large number of books from popular authors who write primarily or exclusively series. For context, I just ran a query and found that 321 of the 564 mystery titles we’ve added this year have a series sequence between 2 and 999.

  Since this would be based on a Nightly setting, it would be library-wide rather than patron by patron.  However, if KLAS also adds the ability to customize Nightly Functions by Serve Code, you could create an “AutoSelect No Sequels” serve code and an “AutoSelect All” serve code and select the appropriate one for each patron.

  1b) “First or next in series only”

  • When Nightly picks a title by Subject, it checks the “series sequence” field and excludes any book with a value greater than 1 UNLESS the patron has a “HasHad” for the previous book in the series..

  Like 1a, except that subsequent books in a series can be sent if the patron is caught up in that series.  This would help increase the available possible selections for series-heavy genres like Mystery.  However, there is no mechanism for a patron to catch up on a series once they have missed a book, or for new patrons to get started on a long-standing series, without a specific request or Series preference.

  ---

  Option 2

  2a) “Not this book, but this series”

  • When Nightly picks a title by Subject, it checks the “series” field and instead sends out the earliest book in that series not marked as “Has Had”.

  The idea here is that, instead of sending out book 7 in a series, Nightly would go back and send out book 1 (or book 5 if the patron had the first four books already).  This method would ensure that patrons are still able to access series books, but will always do so in order.

  However, because the book Nightly initially found isn’t being sent out, there is no “Has Had” record added to that title, so Nightly will keep finding that book and sending books from that series over and over and over.  How much of a problem this is will be very contextually dependent.  If you use “Latest First” service for Subject, the books Nightly finds will change constantly.  

  But if you use “Earliest First” and don’t update your KLAS ID Ranges often, then nightly will check the same books every time.  For instance, if your KLAS ID range starts at DB090000, Nightly will find Joanne Fluke and Stuart Woods at 90001 & 90002 respectively, so patrons with a mystery Subject preference would receive those entire series in rapid succession under this scheme.  And given the prevalence of this sort of long-standing series, patrons may receive a large number of older titles as they are bumped back 20, 30, 50 books in a series.

  2b) “Not this book, but where I left off this series”

  • When nightly picks a title by Subject, it checks the “Series” field, locates the item with the highest series sequence in that series with a “Has Had” record, and sends the next book.

  2a would fill in gaps if a patron skipped books or started with book 15. 2b wouldn’t fill in gaps, but would select the next book after the highest numbered book the patron has read.

  For example, if a patron has read books 1, 2, 4, and 8 in a series and Nightly wants to send them book 10, 2a would instead send book 3, while 2b would send out book 9.

  ---

  Option 3

  3a) “Not this book, but this series, but not too often”

  • When Nightly picks a title by Subject, it checks the “series” field and instead sends out the earliest book in this series not marked as “Has Had” UNLESS a book in this series is already in the Service Queue or a pending order, in which case Nightly will skip this title and series.

  See Option 2, except that the frequency of a series being sent is gated by the length of the service queue, rather than the frequency the queue is refilled.  If the patron’s service queue is 30 books long, you know there will be at least 30 books between each book in a series.  However, this makes more sense for long running series than for short trilogies.  I could see wanting to have different behaviors based on the length of the series, but that is getting complicated to keep track of.  Keep in mind, this only applies to Subject and possibly Author.  Books selected by Series, Request or Reserve would not have this same gating.

  3b) “Not this book, but this series, but not too often, and picking up where I left off”

  • When nightly picks a title by Subject, it checks the “Series” field and instead sends out the next book after the highest number book in the series marked as “Has Had”, or book 1 if the patron has not read any books in the series.  UNLESS a book in this series is already in the service queue or a pending order, in which case nightly will skip this title and series.

  Like 2b, this option just differentiates between filling in the gaps in a series or continuing from the highest numbered book a patron has read.

  ---

  Option 4

  4) “This book and this entire series”

  • When nightly picks a title by Subject, it checks the “Series” field and queues all unread books in that series.

  This could work well for shorter series, especially trilogies with a tight story, but would create a very hit-or-miss situation when dumping an entire 20+ book series.  As with 2b, I worry that having a cutoff point for different behaviors would create confusion and unexpected outcomes.  I think it would be possible to catalog our way out of this problem, flagging series as either a tight story or as episodic/procedural, but that isn’t something every library, including NM, could commit to.  This rule would also need to differentiate between sequence 0 books (which are often more a collection and less a series) and numbered series. 

  Practically, I don’t think this could work as the default option given the sheer quantity of long-running series, but I could see this as an alternative that specific patrons would want to opt-in to.

  ---

  Option 5

  5) “Just care about what is in the Queue now”

  • When Nightly picks a title by Subject, it checks the Service Queue for any books in the same Series.  If another book in the queue is in the same Series and has a higher Series Sequence, the new book is placed ahead of the book already in the queue, rather than at the end.

  Basically, if Nightly is trying to add book 2, and book 3 is already in the queue, book 2 is slotted just ahead of book 3, rather than at the end of the queue.  This would only address the issue of patrons being sent books out of order in immediate proximity, such as when several books in a series are added at once by the NLS.  Limited potential help but also limited potential harm.

  ---

  So what option (listed above or something else entirely) would you want?  

  A big consideration is do we want this to be patron-by-patron?  Or do we want it to be library-wide?  And what do we want to be the default behavior vs. the opt-in behavior?  Should this apply only to Subject selections, or Author as well?

  Personally, I’m in favor of option 3b “Not this book, but this series, but not too often”.  I think it addresses the core problem of books being sent out of order while avoiding any big drawbacks.  It isn’t perfect, and will be clunky for short series, but that’s what Author Preferences and Reader Advisors are for.  That said, I’m sure there are all sorts of circumstances I’m not accounting for that should be considered.

  What are your thoughts?  How, exactly, do you want Nightly to be series smart?

• Improving Foreign Language Service

  

  As you may have heard, PIMMS recently added a large number of new Patron Language codes. This will be great for getting data and statistics on non-English-speaking patrons... but it also provides an opportunity for much better patron service!

  

  Like many opportunities, though, there's a bit of challenge too. In KLAS, Patron Language (aka PatLang) is not like Subject or Author preferences. There is no Nightly Program that goes through, finds books in a patron’s preferred language or languages, and assigns them or adds them to a Service Queue. Instead, Language is one of the options for every other program to check against.

  Most Libraries have Nightly set up so that Requests and Reserves ignore language, but Subject and Author have to match. This allows any patron to request a book in a language they don’t usually receive, but ensures that automatic selections will be in their preferred language (or languages).

  This also means for patrons who speak a language other than English or Spanish, there will be few-to-no books available by AutoSelect. NLS is working to fill out the foreign language collection, but for now, Nightly will find few (if any) Mystery books for a patron speaking only Cantonese, and few (if any) Romances for a patron who only speaks Polish.

  So how do you ensure that your Cantonese- and Polish- (and Everything Else)-speaking patrons get books?

  First, they need to have the specific language(s) they speak on their profile. If they have a Patron Language of just “Other,” NLS won’t know what languages are most needed, and you won’t be able to match up that patron with any books in your catalog. That patron will only ever get Requests and Reserves (potentially including Series, depending on your Nightly configuration).

  Second, you need to make sure they have a preference setup to find books matching their language. At this time, our recommendation is to have Subject headings for each of your Patron Languages other than English and Spanish.

  This allow you to add the subject “Cantonese Books” to all titles in Cantonese and give your patron a preference for any/all of those books. This is much more efficient than needing to either give your patron preferences for every subject you might get a Cantonese title in or manually doing a book search and adding requests for the patron every time a new batch of Marrakesh titles are added.

  Additionally, a patron with both English and Polish as Language preferences and both Romance and Polish Language Books as subject headings will receive a mix of Romance books in English and whatever's available in Polish. 

  Hopefully the foreign language collection will eventually be large enough you can send foreign language titles by actual subject preferences. But, for now, this approach will ensure patrons get what you have. Plus, NLS will get the statistics on what languages are most needed, steering their collection development to the benefit of your patrons—a very win-win scenario.

  Please let us know if you have questions, any time you need more Patron Language options added to your list, or if you need help setting up Subject headings for specific languages. 

• Improving Foreign Language Service – Part II

  

  During our latest New Features Webinar, we had a question about getting the complete list of all languages recognized by PIMMS. Here are some things to know about that list:

  • The list that PIMMS adopted is based on the ISO 639-2 Bibliographic list, a standard list maintained by the Library of Congress. There are 487 languages on this list.
  • This list is designed to represent all the languages that you might expect to find a book written in, but it is not necessarily a list of all spoken languages.
  • The code values in the ISO-639-2 list are used in MARC records to indicate the language(s) of a title.
  • The code values that PIMMS accepts are numeric codes, instead of the alpha values that represent the standard they are attempting to match.

  There are also some things to consider regarding language codes in KLAS:

  • The list of Patron Language codes (PatLang) are mapped to the numeric PIMMS codes.
  • The list of Language Codes for title records (LangCode) are mapped to coincide with incoming MARC data.
  • The local codes for Patron Languages and Language Codes for title records need to match for Nightly and Book Search exclusion checks.
  • The list of values in a drop down are sorted by Code Value instead of description.
  • The more values you have in a list of codes, the more difficult it gets for your staff to use.
  • Changes to a Code list are not applied retroactively; clean up needs to be made on all affected records.

  In short: there are a ton of language possibilities out there. However, when you balance out the needs of your patrons, your collection, and your staff, the only languages you really want to have in KLAS are the ones you need right now.

  You can certainly add more languages than you have now without causing headaches—and we’re happy to help you do it! Languages that your patrons speak, that appear in the collection, and/or that you want to track interest in should definitely be added to your code lists.

  Just know that too many languages can make things complicated, and too many changes later on can be a pain.

  If you want the long version, read on for more details.

  Difficulties of a Long List

  Having “too many” options in a drop-down field introduces some really interesting ways to mess up data entry. For example, while the full list of PIMMS languages was briefly available, one patron was given “Middle English” as their default Language! The more options there are, the easier it is to accidentally select the wrong one, either by misreading or mis-clicking.

  In addition to the unwieldiness of such long list and the ease of selecting an unintended entry, these lists sort by code not full description. This means you should take care with how you setup the codes, or the list will not be in a straightforward, alphabetical order.  Once you get more than 30 or so entries in a combo-box, having a logical sort order becomes very important! For example, browse through the list of states on the Contact tab. The state codes are well-known—but they don’t sort the same as the names of the states. If you weren’t already familiar with them, could you easily use this field? What if the states weren’t in order at all?

  Getting back to the list of languages that you are managing in your database – another thing to keep in mind is the way a language might be referred to by a patron vs its official name or designation. Many libraries have had Cambodian in their Patron language list for years as C or CAM but the Marc value is khm for Khmer. Serbo-Croatian was previously used for what are now distinguished as four different languages whose official codes are based on the spelling of the language in that language – hence HRV for Croatian. The MARC code is PER for Persian but the language is frequently referred to as Farsi.  

  Will those codes help your staff browse to the right part of the list? It’s important to understand how patrons might ask for materials in these languages, and choose local codes and descriptions such that your staff can match what a patron is saying to the proper selection.

  Fortunately, the Code Files allow you to use a local code for the Patron and Catalog modules while still mapping to PIMMS and to the codes used on MARC records. Think about the local codes you may want to use, and how can use them to enforce a reasonable sort order.

  Remember: selecting logical, well-sorted codes, and then selecting the right one from the list every time will be easier the shorter you keep the list.

  Changes to Code Files are not retroactive

  Code Files can be tricky to deal with, especially in cases where you are dealing with large numbers of records, mapping between modules, and mapping with both PIMMS and MARC records. If you’re up to it, you can add to your PatLang codes, but we recommend you leave the LangCode file to us—and don’t go hog wild changing the codes.

  Here’s why:

  Code Files aren’t like Headings. Headings are linked on each record; when you update a Heading, the changes appear on each record. Codes get stored on each record instead, and the Code File simply defines what that code means. If you change a Description, that’s fine! But if you change a Code, all the records with the old code still have the old code. Records with the old code won’t be able to find it in the Code File to define it, triggering error messages and generally breaking things.

  Plus, for this Code File, mapping must be maintained between the Patron and Catalog modules. Doing so means Nightly can match the patrons’ preferred Language to the Language on title records.

  So, if you want to change one of your language codes:

  1. Add the new Code to the PatLang Code File, setting the CMLS Lang Code to match the code you want to update.
  2. Find all of the patrons with the original Code on their record, updating each of them to use the new Code instead.
  3. Only delete the original Code from the PatLang Code File once it’s no longer associated with any
  4. Repeat the process in the LangCode file, with the catalog records, making sure to maintain the CodeXref (MARC record mapping).

  Or... better yet, have us do it.

  Any time you need a language added to the list, or if you want to adjust the local codes in use for sorting the list, please send the details to Customer Support at , and we’ll take it from there.

  Policy Changes are also not retroactive – About Bilingual Titles

  While you’re thinking about all this, here’s one last thing to keep in mind:

  In the past NLS issued MARC records for bilanguage titles with a combined code, such as E/S or S/E for books with both Spanish and English parts. That policy changed! According to NLS, these books are now given a language code reflecting the “primary” language of the title, even if one or more additional languages are included. For example, “Drivetime German” which is marked as E/G in a number of databases, is primarily in English (with some German) according to NLS. Meanwhile, “eTicket Ingles” is a Spanish title (which also has English).

  New MARC records arrive cataloged this way. It’s up to you whether you want to update their records to reflect the bilingual nature of the titles, or want to update your back catalog to use the approach of cataloging the primary language.

  For more information about this, or advice on how to apply changes in the direction of your choice please let us know!

• Order up!

  

  I have another 7.7 preview for you today!

  As part of our continuing efforts to support the high-volume duplication service model, we have been working on another new tab for the Patron Module: the Orders tab.

  Right now, both the cartridge itself and each of the titles loaded on it are listed individually on the Items tab, and it can be difficult to tell which titles were on which cartridge, or to tell which were pre-existing cartridges vs which were duplicated for the patron. Well, in KLAS version 7.7 and onwards, they will continue to be listed there, allowing you to continue using the tab you are already familiar with to quickly check whether a patron has had a certain title, what was the last thing sent, and so on.

  However, when you need more detailed information or to see which titles were on which cartridge... now, you'll have the Orders tab.

  For right now, this is a Read-Only tab, meaning that nothing can be changed or modified from this screen. However, you will be able to browse each duplication order sent to that patron in the top browse, and view all of the Titles from a specific order (and only the Titles from that order) in the bottom browse.

  Using this tab, you'll be able to easily answer patron questions like "I accidentally sent the wrong one back! What was on the last cartridge you sent me?" or "Oh, what was that book I read right after the new Nora Roberts? It was the last one on the cartridge and I forgot to write the name down..." and even "Why did you send me that awful book?"

  Here's a preview of what it looks like right now:

  

  And there's more! While we think this will be a useful starting point, we have more development planned for the Orders tab, including:

  More filtering options - such as Circ Status (Assigned, Out, Returned), date sent, and date returned

  Functions - such as resend order (great for those "I didn't mean to send that one back!" patrons)

  So what do you think? Is there something you'd like to find on this tab that isn't there yet? Any functions you want us to build in? Let us know!

• Patron Holds

  Welcome to the Key Notes blog, where we will be bringing you weekly posts on conference planning, happenings at Keystone, or how better to put KLAS to work for you!

  We’re kicking things off with a discussion on putting patrons “On Hold.” KLAS offers a number of different ways to halt or pause service to a patron, including:

  • Main Status types
  • Media Status types
  • Blocks

  Each of these options works a little differently, offers different benefits, and may work better for some situations than for others. Bear in mind—NONE of these will affect a patron’s BARD account, as there is currently no direct communication between KLAS and the NLS BARD servers.

  Are there situations where you like to use one method over another?
  How do you like to document the reasons or end dates for patron holds?
  Do you have questions or need some help navigating the best workflow for a particular situation?

  Review your options below, then visit the Patron Holds forum thread and join the discussion!

  Options for putting patrons "On Hold"

  Each library or system will develop their own standard procedures. This information is only intended to help you understand your options and to suggest possibilities.

  1. Patron Main Status:

  Change this status to ensure that nothing goes out to a patron until / unless the status is changed back to ACTIVE, and to facilitate the process of removing inactive records after a reasonable period.

  • The lifecycle of a patron record should generally be:
    ACTIVE > SUSPENDED > WITHDRAWN > DELETED
  • INACTIVE should not be used for the Patron Main Status.
  • Once a patron is marked WITHDRAWN, all materials checked out to the patron are marked Lost (including equipment).

  2. Patron Profile and Media Status:

  Change one or more Patron Media Status to stop materials in that medium from going out to the patron, and / or update the Cir Status and Dir Status to stop magazines in that medium.

  • Set the desired media to INACTIVE to block materials from being sent. The status can be set back to ACTIVE at any time to resume service.
  • Dir Status is the status for Direct Magazines—magazines circulated by NLS directly to patrons. Update the subscriptions for these magazines from the Subscriptions tab so information can be sent through PIMMS.
  • Cir Status is the status for Circulating Magazines. Update the status here to block magazines circulated by your library.
  • Other profile adjustments can be made to the NSCutoff, Next Serve Date, or ServeCode, depending on the exact results you want.

  3. Blocks:

  Create a block to stop both books and circulating magazines from being sent from your library. Set an expiration date to make the block temporary without needing to go back and manually reverse changes to a patron’s account.

  • Is not communicated to NLS and does not affect Direct Magazines.
  • Some libraries allow new types of blocks to be created directly in the tab, or you can create a standard “Hold” block type to be used as-needed.

  
  Read this “QuickTip” Tutorial for more information and instructions for each option:

Join the discussion in the Patron Holds forum thread!

Why Enter Has-Hads?

For KLAS-to-KLAS patron transfers, a patron’s reading history (HasHads or HHs) automatically transfer with the rest of the record. Thanks to PIMMS, more and more libraries will be able to automatically transfer records, even if one of the libraries uses WebReads or another system. Eventually, even BARD HHs will be automatically imported into the system right away.

In the meantime, however, at least some out-of-system patron transfers will come with a paper or .pdf list of HHs to enter manually, and BARD HHs are only created when the BARD Circulation Stats are manually uploaded. So: should you spend valuable staff time adding these HHs?

Here’s some information to help you make that choice:

How to do it

---

For transfer patrons: In the Patron Module, open the patron record in question, then press Alt + H on your keyboard or use the menu to select Functions > Items > Add Has Had.

In the Add Has Had window, you will be able to enter KLAS IDs exactly as you do in Quick Requests.

For BARD downloads: Use the Administration page in BARD to download the statistics for your branch for each month. You will need to save the .cscv files; do not open them, as this will re-format the information and keep it from loading properly.

In the Patron Module, use the menu to select Tools > Load BARD Circs. Browse to find the saved stats file, and either Load Now or select Load via Batch Manager. Depending on the size of the file, it may take a while to load.

For help addressing BARD load errors, once the batch has loaded, use Export – Load Errors and save the file. Send it to Ks7 and we will help you identify patron errors and load missing catalog records.

What does it affect?

---

Nightly Autoselect: For most libraries, the Nightly processes are set up not to re-send HasHads based on author or subject. Generally, your patrons should only receive books they have had before if they specifically request them.

Series: If a patron requests a series, KLAS will prompt you to ask whether HHs in that series should be sent again or if they patron wants to pick up right where they’ve left off previously. If the HHs are on file, it puts this choice right in the patron’s hands (or in the hands of the contact person or RA helping them). If they were never added, the patron will receive “repeat” books whether they wanted them or not.

Book Search: When RAs use Book Search, the results page lists any exclusions the patron has against that title, including HHs. Again, having this information on-screen empowers your RAs and your Patrons.

Request List: If a patron downloads a title from BARD after it was added to their request list, KLAS will automatically remove the request or reserve. This is great for patrons who request a book, then change their minds and download it instead, or for patron who have a series preference, but download the latest book before your library gets a hardcopy.

The Bottom Line

---

HasHads are an important part of the Patron record and having an accurate history for a patron improves service.

It does take time to enter this information, especially if you are far behind on your BARD stats or if a patron comes in with an extensive reading history. That said, having full and accurate HasHad records improves automatic picks, provides valuable information to your RAs, and helps answer patron questions (What was that book I read three years ago? I think the love interest was a doctor. . . )

So, chime in: Do you enter all of your HasHads? What about just recent HasHads, that are otherwise more likely to be assigned by Nightly?
Has leaving them off ever caused trouble for you?

Head over to the Entering HasHads forum thread and let us know!