What do visitor counts tell us?

Why did I get into a bate about visitor figures the other day? It's largely because of the spate of recent reports and commentaries about the decline of the public library service based on these numbers. I think there is an over reliance on what is, after all, pretty rubbish data.

Visitor counts are not measures of use. They are an approximation of — sometimes a wild stab at — the number of people who entered a building. If you were to tell me that visitor counts have declined by 30% over a given period I'd take your word for it. Personal experience and observation suggests that fewer people are in some (not all) of the libraries I visit than there used to be so you may be right. And the closing of libraries and nibbling away at opening hours over the past quarter of a century won't have helped any. But I'd be extremely sceptical that you had any forensic evidence to back up your percentage.

Does it actually matter that there are fewer visits? If I can sit in my living room and reserve a book then go and visit the library to pick it up I have immediately cut down the number of visits by at least 50%. But the library has delivered the same service, and much more conveniently for me. While I'm in the library I can still avail myself of all its other services and indulge in a bit of serendipitous discovery amongst the shelves but I am not compelled to an earlier visit with the sole purpose of queuing up at the counter to ask for a reservation to be placed.

Ah but issue figures are going down as well… And? Public libraries never only issued books. Literally an infinitely greater number of people use the public PCs in the library than they did in 1964. Do we have fifty years' worth of attendance figures for story times and author visits? Do we have decades-worth of comparative data of use for quiet study? Or any and all of the other stuff? How do we know that libraries aren't having fewer but richer visits?

But we're delivering less of a service… Are you capable of delivering a better quality of service now? Did you overstretch yourselves in the past and sometimes end up shortchanging your customer service? Were you giving one minute of your time to people who needed five? Were people put off asking for help because they saw that you were busy? High throughput isn't always a measure of high quality.

But visits are down… Do we have annual totals for the number of people who walked through the door, saw the length of the queue at the counter and thought: "I'll come back later?" No, we don't.

Which is why I got in a bit of a bate about it.

Please can we stop pretending library visitor counts are performance data?

From an operations management perspective there is some use for library visitor count data:

• It's useful to have an idea of when your peak throughputs occur so that you can deploy resources accordingly.

• When you're designing new library spaces it's good to have a rough ballpark figure of throughputs for designing in capacity and customer flows.

• It's good for morale to be able to acknowledge and celebrate when you've safely handled a significant number of visitors.

From a service management perspective there is one use for library visitor count data:

• It's a salutary reminder of how little you know of your customers if the only available data are about loans and PC sessions.

Otherwise, they're not a lot of use. You see, the thing about visitor counts is that most of them are poor data and from a service delivery perspective all of them are meaningless.

Why are so many visitor counts poor data?

We'll assume that everyone's acting in good faith and nobody's playing the numbers.

If you've got an automated visitor count system and you're running your library as a stand-alone service you have the best chance of having good visitor count data. A lot depends on the way the count is done; the positioning of the counter; and the frequency of data sampling and verification.

• A badly-placed counter can miss visitors — a head count could miss all the children, for instance, or the customer flows could by-pass the counter completely. 

• Beam-interrupt counters that try to count the number of legs and divide by two have their issues. Back when we installed them at Rochdale we'd heard the urban myth about what happens when you walk past with a ladder. Having enquiring minds we tried it with a seven-rung stepladder and discovered that there was some truth in the story so long as the ladder was being carried horizontally by two toddlers, so we didn't worry about that too much. We did worry that one toddler with little legs = one interrupt = half a visitor. And that a child running into a library didn't get counted (children run into good libraries because they're exciting). People with walking sticks or wheelchairs seemed to be inconsistently recorded. So the figures were only really useful to us as rough ballpark figures.

• Things happen, so there need to be ongoing checks on the reliability of the equipment, the data and the procedures for collection and collation.

If you've got an automated visitor count system in a shared-service building it's a bit more complicated.

• The visitor count is potentially useful for the operational management of the building but not really for the library service. 

• Do you include or exclude the people who came in to renew their taxi licence or claim housing benefit or have an appointment with the nurse in the clinic? 
• If you include them how is this data useful for the management of the library service? 
• If you exclude them how do you capture the visitors who come in for a taxi licence/HB enquiry/clinical appointment then take advantage of the fact there's a library in the same building? 

• How do you exclude the people coming in for meetings with other services? 

• How do you exclude the passage of staff from the other services? 

It gets messy quickly.

And then there are manual counts…

What's wrong with manual counts? Well:

• There's the timing of them. It's unlikely that you'll have the resources to do the count all day every day. If you have, you'll find a lot of other things for them to be doing at the same time. (If you *do* have a FTE devoted exclusively to counting visitors you need your bumps feeling.) The data will be a sample. It's easier to do the sampling during the hours when the library's relatively are quiet, but what would invalidate the sample. So there will inevitably be stresses of distraction and confusion.

Then there's the seasonal variations. And do you want to base your annual count on that week when you've arranged for the workmen to come in to fix the heating? And so on.

You could take the sensible view that you're not going to extrapolate the figures, you're just going to do a year-on-year comparison of counts conducted the same way at the same point in the calendar every year. Which is useful if the figures are purely for internal use or published as trends rather than absolute data.

If that absolute data's used to compare and contrast with another library authority it becomes a lot less useful as you're comparing apples with pears:

• The methodology may be different. 
• There may be good local reasons for differences in the  seasonal variation — half term holidays at schools being obvious examples. 
• There  may be differences in the library calendar — the reading festival may be that week, or it could be the breathing space after last week's reading festival. Back in the nineties our managers were concerned that visitor counts could be distorted by events in the library so, ironically, the two weeks of the visitor count were the only ones with no events in the library, no class visits, no author visits, etc.

• Then there's the counting. A manual visitor count is easy when the library's quiet. When it's busy you're too busy dealing with your customers to count the visitors. You can try and do a catch-up later but that's always going to be an approximation based on memory and chance observation. And your finger may slip on the clicker you're using for the count. Or you could be one of those people who sometimes have four bars in their five-bar gates.

So there are issues with the visitor count data.

Why is this data meaningless?

A person has come into the building. And…? The visitor to the buildings isn't necessarily a user of the library or a customer of the service, any more than the chap who gets off the train at Waverley Station is necessarily a Scotsman.

There were forty visitors to the library

• Three people borrowed some books
• Three people used the computers
• One came to read the electricity meter
• One came to sort out the radiator that hasn’t been working
• One came to deliver a parcel
• One came to use the loo
• A drunk came in to make a row and throw his shoe through the window
• A policeman came in to take a statement about it
• A building manager came in to inspect the damage
• A joiner came in to board up the window
• A glazier came in to replace the window
• A cat ran in, pursued by:
• A dog, pursued by:
• The dog’s owner, pursued by:
• Three children who followed to see the fun
• We don’t know what the rest did.

A visitor comes into the library.

• What did they do? 
• What did you do? 
• Was it any good? 
• Where the right resources available at the right time for the right people? 
• Did the visitor engage with the service at all? 

The visitor count tells you none of this. So how can it be any sort of reflection of the performance of your service? You can't use data about people you don't know have engaged with your service to measure its performance because the only information you have is about the people, you don't have any about the service delivery.

Attendance figures are important to sporting venues because attendance generates income. They don't determine the trophies that team collect in the course of a season. Nor do you see schools with banners proclaiming: "According to OFSTED more people walked through our front door than any other primary school in Loamshire!"

Visitor counts are not performance data. Performance is about the delivery of outcomes, not throughputs.

Learning from experience

When you're doing any sort of serious developmental work, whether it's solving a problem or exploiting a new opportunity, you have to start by defining your preferred outcome then look at all the possible options for getting you there. One of the things that constantly dismayed me when working in public libraries was just how limited "all the possible" usually was, and that these limitations were often imposed as a matter of principle rather than practice. Often summed up with a look of complacent contentment and the mantra: "Ah well, you see, they don't work the same as libraries." I still bump into this thinking quite regularly on the lists and social media, often as a dogmatic statement along the lines of "Libraries have got nothing to learn from…" This is, of course, the veriest nonsense: libraries can learn a great deal from other business operations, if only the reasons why adopting a particular policy or process would be a bad idea in a public library context (and that aren't "Ah well, you see, they don't work the same as libraries.")

The other reason why it is nonsense is that although a business operation may be very different to yours some of the operational functionality requirements may be very similar, or the same. There's no particular philosophical or ethical difference between opening the public doors to a library first thing in the morning and opening the public doors of a shop, for instance.

The exciting thing about not imposing any constraints on where ideas can come from is that you can often find alternatives to the organisation's "default setting" that are cheaper and more effective to apply.

The responsibilities in my last job included a transport management system called Tranman. Very generally speaking it was used to manage the council's fleet of vehicles and the jobs done in the vehicle workshop. Some of the jobs done in the workshop were part of the routine maintenance work included in the service level agreements with the council departments using the vehicles. A lot weren't: repairs necessitated by accidents or driver abuse were chargeable extras and the workshop also did a lot of private repair work, services and MOTs as part of the operation's income generation. Extremely different to the business operation and purpose of the public libraries I was also supporting.

They had a problem. A lot of the jobs were taking ages to complete and invoice on the system because they were missing information about the parts that were issued to them. Even worse, some jobs had been completed and invoiced without including the rechargeable costs of the parts. This was playing hob with their cash flow and making the accountants cross. So we had a look at it and basically the situation was:

• There was a manual process involving somebody trying to catch up with a pile of paperwork at the end of the month
• There was a technical solution which could automate the stock issue but wasn't being used

What was needed was for the parts to be issued to the jobs in as close to real time as possible and that wasn't going to be done manually from the paperwork.

We had a long, hard look at the technical solution. None of us were big fans. It was hard work to get set up and running and, frankly, was over-engineered for its purpose. On paper it looked great:

• A piece of software on the stores manager's PC generated barcoded labels for each part, the barcode including the appropriate part number and bin, together with a human-readable description.
• The parts bins were labelled up accordingly.
• When a part was to be issued to a job the store man entered the job number into a PDA, read the appropriate barcode and entered the number of items being issued.
• The PDA was then plugged into a console attached to the store manager's PC and the data uploaded into Tranman.

In reality it wasn't so hot:

• The barcoded labels soon got scruffy and unusable.
• We could make the barcodes on the labels as big as we wanted but the descriptive text was always tiny and difficult to read, especially in some of the darker corners of the store room.
• The keys on the PDA were very small (6mm across), which was difficult enough for me with my never-done-a-stroke-of-hard-labour-in-his-life delicate fingers and not a lot of fun for workers who'd spent years bashing their finger ends on bits of metal on cold Winter's days. The incidence of input error was high.
• Uploading the data was a bit hit and miss at first: it took quite a while for us to iron out the problems and making sure the solutions were properly packaged into the virtual application. (I for one was praying nothing happened to that PC as I wasn't confident we wouldn't have at least a few of these problems again with a new deployment of the software.)
• It wasn't easy to see where and when something went wrong. The lack of transparency meant that you couldn't do any quality control to make sure that the right parts actually were being issued to the right job.

Something had to be done. 

We looked at various somethings: we spent far too long trying to sort out better barcode labels; then we had a fruitless quest for a more user-friendly PDA that could do the job. Over the next few months, in between a pile of other pieces of work we were doing with this system, we tweaked this process as best we could but in the end it felt more like we were working through levels in an arcade game rather than getting anywhere with improving the process and addressing the cash flow problem. By this stage I was thoroughly fed up and went and had a sulk in my tent. On reflection it was apparent that all we had been doing was following the same ploughed rut over and over again. 

We'd let our problem-solving be dictated by the "solution" rather than either the problem or the desired outcome.

So I looked again. And wondered why the issuing of parts to a job in a vehicle workshop was very much different to the issuing of library books to a borrower…

The solution I came up with was cheap, not especially elegant but did the job and could be seen to do the job. There were two elements:

• A standard barcode reader, same as you'd see in a shop or library
• A folder containing sheets of labels including all the information needing to be entered into the job record:
• The description of the part in a large, readable font
• The part number as a barcode (using the "3 of 9" font)
• The bin number as a barcode
• The store location as a barcode

The process was:

• The request comes in for the part for the job
• The stores man gets the part then opens the job record in Tranman
• The part number, bin number and location are input by reading the barcodes from the appropriate sheet
• The only manual input is the number of parts
• The parts are issued to the workshop

For out-of-hours working the process was:

• The request for the part is recorded on a paper job sheet
• The fitter working on the job gets the part
• Next working day the stores man issues the part in Tranman as above

Getting a working test sheet turned out to be a bit of a problem because initially I was doing it in MS Word and the formatting it imposed was disabling the begin and end codes of the barcode (an asterisk *). Jacking it in and doing the job in Wordpad gave us some test sheets we could use to demonstrate proof of concept. I used Crystal Reports for the final print out of all the parts.

Sadly, this is as far as I got with it by the time I was leaving. We'd checked that each step should work as expected but we'd not given the process much hammer and inevitably there'd be some snagging to do. One thing I'd have liked to have done, given the time, would be to modify the Crystal Report so that the first few pages were limited to the high-volume items, to save the stores men having to routinely wade through so many pages.

So that's how I applied a bit of standard public library functionality to a problem in a completely other environment.

So what are the takeaways from this?

• Don't mistake differences in business operation with differences in operational functionality. In this case, issuing an item in real time is issuing an item in real time.

• If your problem-solving energies are being devoted to the solution perhaps you've got the wrong solution.

• To solve a problem you have to know what problem you're solving and the outcome you desire of the solution.

Specification: the importance of purpose

If I were to ask you what you could do with a stick like as not you'd quickly come up with half a dozen entirely practicable ideas. You could use it to prod cans off supermarket shelves or prop up a flower stem, You could poke a wasps' nest or hit a golf ball across the lawn. You could stir concrete or poke holes in doughnuts with it. And so on until bedtime.

But what if I asked you what a stick could do? You'd probably need to think a bit about that. Especially if I asked what a stick could do that wasn't really what you could do with a stick. It could stay where it was or it could rot or, if it were fresh off the tree, it might take root and grow. There aren't many other options as spring immediately to mind.

Like any technology, the usefulness or not of the stick is dependent on the purpose to which it is actually applied. This is why whenever we're looking at any new equipment or application the "What would you want to do with it?" question is infinitely more important than "What does it do?" It may be capable of doing very many splendid things but until somebody actually puts it to work these are only a potential usefulness. And very often the use a technology is put to isn't the one intended by the person who built it (screwdrivers weren't designed for levering the lids off tins of paint, they just happen to be very useful for doing so).

When you're building a specification or statement of user requirements you need to be mindful of the difference between describing what something will be and describing what something will do. Specifications too often describe — and prescribe — processes without describing their preferred outcomes. Which is perverse because if the object isn't to specify a physical object or deploy some sort of brand you want as much freedom of interpretation as possible. In design thinking terms you're defining the problem not building the prototype.

The purpose of specification is to define the problem to be solved. If you use the specification to define the prototype then you could be missing out on better potential solutions. Like Henry Ford might or might not have said: "If I had asked people what they wanted, they would have said faster horses."

Public library technology requirements

Ken Chad's put together a schematic derived from the initial discussions that have been going on about a new generation of core specification(s) for library management systems. You can see a copy here. The more I think about this the more I think that what we really need is a standard methodology rather than a standard specification. When I get a bit of space and time I need to revisit this thinking.

Change management: I'm asking you questions because I'm trying to help you get it right

If you were to say to me: "You have to make the following changes to your library management system," my response would be: "Perhaps. But not yet." This isn't me being precious or obstructive; this is me doing my job. There are times when the brown stuff is hitting the fan and you have to do something in a hurry but most of the time it isn't; and even when it is you need to go back and check your workings-out when the fuss has died down.

If you're working in an ITIL environment — and I am — the assumption has to be that you do what the customer asks, so long as it doesn't screw up the integrity of the system that you're managing. So I'd need to ask you a series of questions to make sure that it doesn't. It's important to point out that under ITIL it doesn't matter whether or not the requested change plays Hob with the business; so long as the system remains intact my job would be done. So, for instance, if you were to ask me to set the library loan period to two hours, with a £100 per hour overdue rate I'd be perfectly entitled to raise my eyebrows and ask: "Are you sure?" but the default position is that the change would be made. The customer is always right, within the confines of their rôle and competencies. (I'm not being "neoliberal" here: "customer" in this context has a particular definition.)

That's the principle of the thing. In reality it's a bit more complicated because we want to avoid the dialogue: "It doesn't work." "It does work, it just doesn't do what you wanted it to do." This is a dismal and unproductive conversation which could do serious damage to the working relationship so we make the effort to avoid it. So I'll ask a few more questions:

"What do you want to do?"
It's astonishing how often this question causes a problem. If you don't know what you want to do, how will you know when you've done it? How will you know if the proposed change will address the issue to hand? And if it is the solution to a problem, is it the best solution? You'd be surprised how often the first applied solution to come along becomes accepted as an essential compnent of the process, regardless of the impact on the efficiency or effectiveness of the business. Just because you know how to pick a lock within two minutes just with the aid of a hair pin doesn't mean you'd necessarily want to throw your front door key away.

"Who does this affect and are they OK with it?"
Systems and services don't live in hermetically-sealed bubbles. At least have a think about who's involved and/or do an outline impact analysis on the back of a fag packet. And do make sure that anyone affected by the change knows about it and what it means to them. If the impacts are big and scary enough you may need to sketch out a communication strategy for them.

"What happens if it goes wrong?"
Give the risks a degree of respect. Don't assume nothing could go wrong or they'll come and bite you on the bum. Make sure you know what could happen if it goes wrong; what the impact would be; and that you have a Plan B, a safety net and/or the capacity to go back to where you started from.

"What do you mean by...?"
Make sure you're talking about the same thing with the same meaning. "Better," "Improved" and "Modernise" are words that should be deprecated in this conversation: what do they mean in the working context? For instance, a set of catalogue records may be more complete, with every tag full of data; or may exhibit a purer adherence to current cataloguing standards; or may be Dewey classified to fifteen decimals, but is it actually better? For whom? You may need to sketch out a quality description document for changes to key data or even a quality plan if you're talking about large-scale fundamental changes.

"How will you know if it's worked?"
Because we want to avoid that dark and dismal dialogue, right?