In recent months, a number of folk have raised questions about reporting around the usage of Self-Service terminals. There seem to be a couple of issues; What (to report on, regardless of means) and How (at a technical level). In this post I’ll attempt to set out some ideas on both.

What to report (and how to use the reports)

As ever with management reporting, the best place to start is what outcomes are considered desirable, and what management actions the recipient can actually take to achieve that desired end. The desirable outcomes are in this case fairly intuitive: to increase efficiency whilst maintaining staff morale and retaining borrowers. Actions that management can take might include:

1. Make changes to Self-Service Terminal siting
2. Make changes to staff planning (e.g. more staff on when manual transactions high, fewer when self-service transactions predominate)
3. Make a change to opening hours (e.g. if it is found that the use of self service holds up later in the evening)
4. Make a business case for more self-service terminals
5. Take steps to re-activate customers who may have been scared off by the introduction of self-service.
6. Reassure staff
7. Organise staff training in the use of staff pads (workstations) or in encouraging borrowers to switch from manual to self-service transactions
8. Run experiments (e.g. assigning a staff member or volunteer to hover around a group of self service terminals at peak times to help Borrowers get over the initial techno-fear)
9. Organise undergraduate education
10. etc. etc. Please do add other ideas as comments

Many of these actions can be supported by monitoring transaction volumes by site and by terminal in a given time period. There are many ways that these data could be displayed. Here are some examples:

This first example gives an overall feel for the extent of Self Service Terminal utilisation by site

• Site A shows a healthy pattern : Staff Pad (Staff Workstation) and Manual transactions are low
• Site B does not have a Staff Pad (or if it does, it isn’t being used). Also it either has insufficient terminals, or the terminals are being underutilised
• Site C is quite out of balance. The self service terminals are little used

This example shows the number of loan transactions by hour of day through the day. It might feed into staff planning.

• The peak in Self Service transactions around 3:00 coincides with few staff issues at that hour . This might bear further investigation. Are the staff busy on other tasks? Have afternoon lectures just finished or a local school just come out?
• It also looks like this site is open for self-service issues longer than for staff issues. The slight rise in self-service issues around 19:00 (7:00 pm) suggests that if the site was open until (say) 9:00 p.m. then issues might continue.
• Note too that I’ve added a drill filter on the Site of Loan to this example (top left). If you select a site in the drop down, the chart redisplays with just the data for that site. (This is of course not available when viewing the report in Excel or PDF).

This example shows the utilisation of individual terminals, staff pads and human operators by hour of day. You might want to add a drill filter on the site if the number of terminals is large.

• It is pretty clear that most of the terminals are under utilised. The issues at terminals A, C, E & G together add up to only a few percent of the issues at terminal B.
• Those issues that do occur at the less-used terminals all seem to occur in the morning: they are hardly used at all after 2:00.
• It would be worth asking staff to monitor Terminal B between 1:00 and 3:00 to see if there are frequent queues at it. If so, it may be worth putting a notice on it like “There are more self-service machines located…”

These examples are not exhaustive. For example, Borrowers who lapsed around the time that terminals were introduced and who never used self-service terminals might be candidates for a marketing effort emphasising that help is available to learn how to use the new terminals, and that the old issue procedure are also still available.

How to do it

Again, there are a number of ways of generating reports like these. There is one key issue however – in order to get data down at the level of the individual terminal, it is essential that each terminal and staff pad have it’s own unique operator ID, and that these operators are set up in Talis Alto. Any Operator IDs that are not set up within Talis Alto will not show up in the Talis Decisions reports, even if they are configured correctly in Talis Bridge  At the end I provide an alternative partial solution if these are not set up correctly.

The three examples above were all individual report tabs within one Talis Decisions document. This was done using Web Intelligence in Talis Decisions XI Release 2. All three reports were based on the same single query. The core of such a query might look like this:

You can embellish the query with item and/or borrower details, but the query will take longer to run, as for each loan a look-up will be required on the linked item and/or borrower data.

It is usually essential to restrict the date range for a query like this. If the query is run with no date filter, or for a very long period, the query may take a very long time to run and might not complete at all. If despite restricting the date range to (say) a week, the query still takes a long time to refresh, it would be worth raising the issue with your account manager, because this may indicate an issue with your Talis Decisions set up.

You will note above that there is reference to a Terminal Type. This is not data extracted by the query; it is a variable that uses data from the query. The basic principle is to say that if the Operator ID is in one range (or one set of values), it is a self-service terminal. If the Operator ID matches another set of values, it must be a staff pad etc. The variable is defined in this way:

The variable formula used in this illustration is

=If(Match([Operator];"T*");"Self Service";If (Match([Operator];"ST*");"Staff Pad";"Manual"))

This example assumes for illustration that:

1. all the self service terminals are configured so that the operator starts with a “T”, that
2. all the staff pads are configured with an operator that starts  “ST” and
3. anything else is assumed to be manual.

You would of course have to amend this formula to suit the terminal configuration in your library.

If your terminals are not configured with unique operator IDs, or if the operator IDs are not known to Talis Alto, then an alternative which will give you some information is a query like this:

The Loan Activity Breakdown returns values such as

• Child project loan
• Housebound
• Manual discharge
• Parent project loan
• Public renew
• Seen issue, renew or discharge
• Self-issue
• Unseen renew

The exact values may vary from library to library, but the underlying codes are the same: all SIP2 transactions (apart from Talis Message) will have a LOAN.ACTION_ID = “CLIS” which will probably be labelled “Self-issue”.

What Can’t be done currently

Only successful Self-service transactions are recorded in Alto. If a user tries fruitlessly to self issue an item, fails, gives up and goes away in frustration without telling anyone then Alto will not have a record of it. The Talis Bridge logs do contain data on failed transactions and it would in principle be possible to extend Talis Decisions and Talis Bridge to allow reporting on failures.

Is this something that you feel is important? If so, please help direct the Talis Decisions and Talis Bridge roadmaps by commenting on this post enabling us to gauge demand..

Any other comments/suggestions based on your needs or experiences with self-service reporting would also be most welcome.