Using LibAnswers in the Archives: A review and implementation report

Introduction

The implementation of LibAnswers [1] by the University of Saskatchewan represents the culmination of fundamental changes to the way reference service is delivered in University Archives & Special Collections. In 2013, there was an amalgamation of two units that shared space but were organizationally independent. Previously, e-mail reference was primarily handled by one employee from each unit, with assistance and referrals as needed. With the 2013 amalgamation, the delivery model changed to have all staff members – archivists, librarians, and senior library/archives assistants – take half-day shifts on the reference desk, which would include walk-in traffic, phone calls and e-mail.

From the outset, the need for an enquiry management system was identified, but selection and implementation took longer than anticipated. This resulted in using a central e-mail address for a few years. This ultimately helped clarify some requirements and procedural issues, but also reinforced the need for a more robust technology. Inevitably some enquiries fell through the cracks (with misunderstandings about who was handling it), and we started using a log book to keep colleagues up-to-date about unfinished enquiries.

As with the implementation of any system, successful deployment lies not only with the technology but with clear procedures as well as common understanding from the users. With LibAnswers, issues to address included:

• Protocol for handling tickets open at the end of a reference shift: what kind of questions should remain assigned to the staff member, rather than assigned back to the desk account?
• Setup and procedures for the Reference Analytics module. For example, is a reference question recorded only when a ticket is closed, or for every transaction. It may be possible to simply adopt existing procedures, but the implementation of LibAnswers provided an opportunity for review, especially since the first draft of the SAA/ACRL standard for public services metrics was recently released [2]. An additional layer for our institution was ensuring alignment with reporting requirements at the library level, which was the topic of a separate initiative unrelated to deployment of LibAnswers but conveniently timed.

At this point, we are not using the public FAQ, chat or social media features of LibAnswers. Therefore, this review focuses on the enquiry management features of LibAnswers.

Features

Most of the items on our requirements/wish list for an enquiry management system have been met by LibAnswers [3], including:

• A configurable web form for submitting enquiries.
• The ability to receive enquiries by e-mail. The system creates a ticket for any e-mail sent to one or more addresses (either assigned by the vendor or an institutional e-mail address). An added bonus is that staff members can create tickets, with the “asker” information correctly populated, by forwarding e-mail to the LibAnswers address (e.g. for reference enquiries sent to their own e-mail address). However, an extra step is needed for institutional e-mail systems such as Outlook Exchange that don’t display the e-mail address for internal users. An additional useful feature is that external users can be copied on replies, which allows, for example, the original distribution list to be maintained if a researcher has copied their enquiry to one or more colleagues.
• The ability for staff to add tickets, for enquiries needing follow-up that are received by phone or in person.
• The ability to both receive and send files. There is a limit of 5MB per file, and they are automatically deleted after three months. The main advantage of this feature is that they are sent as links rather than e-mail attachments, although in many cases the size limit is smaller than the files we need to send.

Figure 1: A reply with attachment

• An internal notes feature. A staff member can add notes only visible to staff users, and also request information/assistance from colleagues, by copying their account on the internal note.

Figure 2: Internal notes

• E-mail notification of research responses. Staff may also respond to tickets and add internal notes via e-mail, depending whether or not the ticket is assigned to them. If desired, one or more e-mail addresses can receive notification of any new tickets.
• Reference statistics. This is a configurable feature which will be discussed further below (see Reference Analytics).
• A systematic way to manage requests requiring a trip to one of our offsite locations. This is managed through queues (see below).

A few items from our initial list were not addressed, but none of these were considered core functionality.

• The ability to track instructional sessions, e.g. number of students per session. This is explained further below (see Reference Analytics).
• Automated e-mail reminders about open tickets.
• Standard clauses/canned responses. However, this feature seems to be available for the LibChat feature.

Dashboard and Ticket Management

The dashboard for LibAnswers is typical – the page from which to view open tickets, along with access to other menu items.

Figure 3: The LibAnswers dashboard

There are options for filtering the ticket list, and it’s possible to save these filters as readily available views. However, this could be more flexible. For status, the choices are “not closed”, “new”, “open”, “pending”. Our preferred default view would be all tickets that are new or open, since “pending” refers to tickets where we are waiting for a response from the researcher and don’t need immediate attention. More generally, enabling multiple selections (as is available for other fields) seems like a straightforward approach to accommodate varying use cases. Further, while it is possible to filter by tickets assigned either to a given user or to any user (not “unclaimed”), it is not possible to combine the two, even though you can select multiple users. That is, it is possible to limit the view to tickets assigned to either user A or user B, but not those that are either unclaimed or assigned to user A. This means that for the staff member on the reference desk, the default view needs to be tickets assigned to all users.

Figure 4: Dashboard filtering options

There is a reasonable amount of flexibility in updating ticket information. For example, the researcher name and contact information can be edited; the subject line can be changed; and tickets can be split or merged, to deal with new topics added to an existing thread or duplicate threads, respectively. It is also possible to browse all the tickets from a given researcher.

Via the “answers” menu item, tickets can also be browsed and searched.

Reference Analytics module

The Reference Analytics module provides a way to collect basic reference statistics. There are 10 fields with room for up to 20 values each. The READ scale is also available as an optional, built-in element [4]. An important caveat is that it is difficult to changes things after the initial setup. Fields can be added, but not removed; and the order of fields cannot be changed. One side-effect of this is that it makes it more difficult to collect extra statistics for a short period, since the extra fields would need to be left there with a note. It is also not possible to configure the layout of the screen or hide elements not required. Another limitation of this module is that the only field type available is single select; text or numeric fields cannot be defined. In our case, this has required continuing to use a different system to track instructional sessions.

Figure 5: Reference Analytics data entry form

The built-in reports are quite robust, with the ability to filter on any field, and you can generate cross-tab reports for any two fields. Every transaction is also date and time stamped (with the ability to back-date), and there are built-in reports using that data. The full dataset can be exported as CSV. However, a limitation of the cross-tabs feature is the inability to apply additional criteria based on user-defined fields.

Figure 6: Report options

It is also possible to use the Reference Analytics module on its own (without the enquiry management component). This is being adopted by other branches of our library, and has the advantage of all branches including University Archives & Special Collections contributing to the same dataset. However, it is not possible to configure the fields available to particular users; in our case there is a field only University Archives & Special Collections uses. While it would be possible to use a separate dataset, we decided to keep a single dataset and indicate through the field label that one field is only for University Archives & Special Collections.

The Reference Analytics form is integrated into the main ticket form, and users can be prompted to add analytics either with every response or upon closing a ticket. Analytics can also be added without creating a ticket, which is useful for quick reference or directional questions.

Springshare does have a much more robust and configurable analytics package (LibAnalytics), but it is not currently integrated with LibAnswers.

Queues

Currently, we are only using queues to track retrieval and other requests from our offsite locations. Tickets can be transferred between queues, with the dashboard filtered to view a given queue; and users are given permissions on one or more queues. The queues framework also allows for extensibility of a LibAnswers deployment within an institution, which is likely the more common use case. For example, the archives reference desk and the main library reference desk can have separate queues, with enquiries going to separate e-mail addresses. Indeed, in setting up our instance, we took some care to ensure that changes wouldn’t be needed later to accommodate other units/branches starting to use the enquiry management or public FAQ features. There are also other configuration options including the question form, the text for a number of elements of the system, and style sheets.

Other features

As mentioned earlier, our institution is not currently using the public FAQ feature, so it is not a focus of the review, but it is worth highlighting. Public answers can be either be created as “canned” answers or on the fly. In the latter case, a response to a patron can be used as a public answer. While it can be edited before it goes live, we intend to use this feature with caution, to try to avoid misleading answers; for example, a question is often focused on only one aspect of a topic. We have also come across examples of LibAnswers sites where the name of a researcher, and occasionally even contact information, has not been edited out of the public answer.

The system also has an IM/chat feature called LibChat. This is available as a standalone product, but ships with LibAnswers as an integrated module. There is also an integration with social media, released in July 2016 – currently for Twitter, Facebook and Pinterest.

Conclusion

At time of final submission, our instance of LibAnswers has been in production for about four months. On the whole, it has been a successful implementation. In addition to improving communications for a reference desk staffed by eight people, over time we will develop a large, searchable knowledge base. Growing pains have largely related to procedural issues rather than technological: for example, needing to clarify guidelines for recording reference statistics. The interface is reasonably self-explanatory, with quick orientation sessions generally being enough to get staff comfortable with the system. Integration with LibAnalytics, or a more configurable Reference Analytics, would likely be the most useful enhancement. From a workflow perspective, having statistics collection integrated into the enquiry management has made it much easier to ensure those statistics are being collected, so using a different system would not be a priority. While many library implementations seem to focus on the public FAQs, LibAnswers is a product that can be readily adopted for an archival reference service with its more in-depth research needs.