How many things does government do?

Easy: 1,479,025,887

GDS has produced another fascinating tool, this time providing a list and volumes of government transactional services, which it turns out are used a shade under one and a half billion times a year. Richard Sargeant has a blog post introducing the endeavour, and making clear that this initial version is an alpha release.

Counting government transactions sounds as though it should be easy, but turns out to be remarkably difficult, so producing any kind of coherent picture at all is quite an achievement. There are some risks though in the apparent precision of many of the numbers which make it tempting to rely on them more than they deserve. That has the potential to be much more than a narrowly technical issue – as I was writing this post, I had coincidentally just read an impassioned piece by Declan Gaffney on the importance of getting numbers right:

You can’t have it both ways. If the numbers are irrelevant to the issues being discussed, then they shouldn’t be in play at all: if they are relevant, they merit the same level of critical scrutiny as the moral arguments being advanced. To say ‘let’s not get hung up on the numbers’ so as to get down to the real issues is indefensible when those issues are defined in terms of what is claimed to be quantitative evidence.

The context in which that was written is very different from the context here – but there is an underlying point which is common: if we are going to use numbers, we have a responsibility to make them the best numbers they can be.

Back then to the set of government transactions, which Richard describes as being the first time that information has been brought together. As it happens, though, it has been done before, as part of an earlier attempt to make government digital. That’s not a terribly important oversight, and I mean no criticism by it, but it does mean that there are two approaches which in principle are attempting to answer the same question, and it may be instructive to compare them.

Counting transactions was the approach initially used to measure progress towards the Electronic Delivery of Government Services in 1999, with a series of reports produced which you can still find in obscure web archives. Back in 1999, there were 566 million transactions (in the Autumn 1999 report – word doc). So the first thing we can see is that transaction volumes have gone up almost three fold in the last dozen years. Which is of course nonsense, they have done no such thing, and even a fairly superficial inspection shows that different things are being counted in different ways, with inclusions and exclusions which are necessarily fairly arbitrary. That’s an important part of why the attempt to count transactions was abandoned in 2000: the approach was inherently unstable and unreliable and it was felt that it would be more meaningful and robust to count transactional services instead, which is what later reports went on to do. One reason precipitating the change, if I remember correctly, is that the advent of cattle registration meant that every cow moving from place to place would be reportable, completely swamping the overall count.

The fact that it didn’t work then is, of course, no reason for assuming that it cannot work now. Apart from anything else, the motive for doing this in the first place is very different, and the core message that one and half billion is a very large number which were better made smaller does not depend on huge precision in the counting. But that still leaves us with some important issues to reflect on.

Some numbers are proper counts with real validity, some are made up (or ‘estimated’ to put it politely).The overall estimate can’t be more reliable than its least reliable elements – so the five zeroes at the end of the 517,500,000 local government transaction are probably a fairly generous indicator of the level of precision, with the uncertainty rather swamping the ten applications for permits for burial at sea. A total presented in the way I did at the beginning of this post is completely misleading in its spurious precision (a mistake which, to be clear, Richard does not make, though it is the sum total of all the numbers in his dataset).

Even putting aside issues of arithmetical imprecision, there is a dangerous tacit assumption in this approach, that all transactions are somehow equal. They are not. Some are fairly major undertakings, some are delightfully straightforward, some may be effectively invisible to the end user because they are a by-product of something done for another purpose. So there might well be far greater value in reducing benefit claim transactions by ten minutes apiece, leaving the total number of transactions completely unchanged, than in taking the logical next step with car tax discs of abolishing them altogether. Thought about that way, a count of transactions is not, despite initial appearances, a very user focused measure. The variable we are actually interested in might be something like ‘total minutes spent on government transactions which I would really rather not be doing’. Using the former as a proxy for the latter is a bit dangerous unless we are very confident that we know how they are related.

Taking that a step further, the situation is made more complicated still by the fact that transactions do not map to contacts. Some transactions involve multiple interactions. More subtly, looking up information is not a transaction, but if completing a transaction depends on that information, then from the user’s perspective, it’s an essential part of the journey. If we look at the transaction too narrowly, we risk falling into the trap of taking too much of a producer perspective. Even within the transaction, it may matter a lot how many stages it has, how evidence has to be provided, and how often the service design can support a single simple interaction to achieve the transactional outcome.

Sitting behind all of that, there is the question of what counts as a government transaction in the first place. GDS has attempted a definition which looks reasonable, but boils down to including any interaction which results in a change to records held by a public body, which could be interpreted very broadly indeed. If I run my company payroll and the software silently transmits relevant data to HMRC, has there been a government transaction? Is buying a bus ticket in London from a public body to be counted differently from buying one in most of the rest of the country from a commercial operator? The tool records 64.6 million library transactions a year: it’s not clear what that is counting, but it doesn’t appear to be either visitors (330 million) or books borrowed (300 million). To add to the slight sense of murkiness, some of the transactions counted in the tool are for the UK, some for GB and some for England.

The point of all that is not that counting transactions is a doomed endeavour or that the GDS tool is not useful. On the contrary, it has the potential to be so useful that it is important to improve on the first version (with one simple but hugely valuable improvement being a description for each line item of what has actually been counted and the provenance of the data).

The more difficult, but more important, conclusion I draw is that we need to be really careful in thinking about transaction volumes. It is essential that we understand transactions and how people interact with them if we are to improve the services of which they form a part. Transaction are not needs, so aren’t the right starting point for improving service design. But making transactions smaller, simpler, and fewer is a powerful way of improving the overall service. We all have a strong interest in understanding the landscape of transactions better and the GDS tool is an important and welcome contribution to that understanding.

Service design is not the same as system design

Good services depends on good systems. But good systems do not guarantee good services. The distinction is all too often overlooked, not least by designers of systems and services.

The London congestion charge is a fascinating case study of a superbly engineered system supporting a service which has some important deficiencies. I was told a couple of years ago by somebody who was on the development team that the service they built was defined by the statement:

Every car which enters central London and does not pay £5 by midnight should be charged £40.

I love the economy and precision of that statement. And there is no arguing but that the system does exactly that (albeit now with rather higher prices). But it completely misses out that the thing they built is a service. There is no customer in that statement, and so no customer relationship. The congestion charge is seen as a penalty capable of partial mitigation rather than a fee, the payment of which should first be facilitated and only then if necessary pursued. As I observed when I first ranted on the subject of the congestion charge:

HMRC has very deliberately chosen to assume that most customers want to be compliant.  It follows from that assumption that if people become non-compliant, they need encouragement and help rather than punishment.  Of course HMRC can turn nasty if it needs to, and if it puts its mind to it, it can turn very nasty indeed, but that’s not where they start from. TfL assumes from the outset that non-compliance is an attempt at evasion and its first response is to impose punishment.

There is no obvious reason why TfL could not instead send polite reminders that a payment is due and keep the penalty charges for those whose further inaction suggests an intent to avoid paying.  But something quite subtle about how they saw the problem they were trying to solve has sent them down altogether the wrong path.

What’s particularly odd about that is that in other ways, the congestion charging service was quite innovative – paying by SMS, for example, hardly rates a mention now, but was then the result of impressive creative thinking and customer insight. I find that useful, but only because the developer of a third party app has made it simple, and it speaks volumes that it should take a third party to produce the most straightforward way of completing what should be a trivially straightforward transaction.

Now, years later, there seems to have been a change of heart. From 4 January, TfL is introducing ‘Auto Pay’, with an equally admirable concise and precise description:

We’ll automatically record the number of charging days a vehicle travels within the charging zone each month and bill your debit or credit card each month.

That’s a milestone worth celebrating (and in my case at least, worth signing up for), but it’s the hook for this post rather than the point of it. Despite possible appearances to the contrary, the point is not to knock TfL or the congestion charging scheme. It is to recognise that it is easy to mark success by the achievement of technical completeness, while missing something subtle but critical about quality of service.

That is something which should concern all of us involved with the design and delivery of public services. I am trying to find a simple way to express this as a contrast between a system led approach to design and a service based approach. It’s work in progress, because it is too long and lacks the elegant pithiness of the one liners quoted above, but in its current form, it goes something like this.

The traditional approach was to start by designing the systems and processes to deliver the outputs we wanted, and only then to design the front end experience (in the broadest sense, this isn’t just about IT). That meant that the front end was compromised from the outset, but it didn’t matter because the only people who had to use it were staff who had no choice because that was their job and who could be sent on lengthy training courses.

Now we need to start by defining the user experience and outcome we want the system to support, and only then design the tools and processes needed to deliver that support. There is any number of reasons for doing that, but there are two which matter particularly. One is that we want and will increasingly need customers to be users. We can’t send them on training courses; they can walk away or, worse still, find expensive and inefficient ways of making contact if they don’t like the look of what we offer. The other is that unless we do it that way round, there is no way of knowing that the resulting service is as efficient and effective as it can be.

I would have been proud to have been part of the team which delivered the congestion charge: it’s a remarkable achievement.  But I would have been more proud to have been there and said that it wasn’t being designed to be good enough.

Petty annoyances

The links below have two things in common.  They don’t work. And they should.

http://hmrc.gov.uk

http://met.police.uk

http://parliament.uk

http://civilservice.gov.uk

http://hmg.gov.uk/ (though for so grand an address, the results to be found are sadly inconsequential)

Distinguishing a web server from gopher, telnet and the host of other application protocols which jostled for supremacy as they emerged from the primordial swamp of the early internet was important once.  But now it’s not. Now it’s just irritating.

And in a slightly different category, there is really no need to make people remember your preferred hyphenation style.  So this one doesn’t work either.  And it should.

http://hmtreasury.gov.uk/

I am not alone in these thoughts. And other people have been annoyed enough to think about a solution for routing round the damage, though there is no sign that it progressed beyond the original idea. But the time has surely come just to make this right.

Overheard: service design opportunities

To the post office this morning. Twice: once to queue up to post some parcels and once to queue up somewhere else to collect one.

At the post office, the woman in front of me wanted a form to convert her Portuguese driving licence into a British one.  Easily done. And she wanted some advice: her mother had recently arrived from Portugal, had found a job, but was having difficulty opening a bank account. Could the post office help? Yes, of course, delighted to. What evidence of identity would be needed? A passport. No problem. And a bank statement or a utility bill. Oh dear.

Then to the sorting office to pick up the parcel. The woman in front of me handed over the card that had been left. The postman went to look for it but came back empty handed. It seemed that the package had not yet come back from the delivery round.  But, pointed out the woman, the card said she should wait two hours before attempting to collect it and two hours had passed. Well, said the postman, sometimes it could be quicker than that. But sometimes it took longer. Such was life. The woman was perplexed. What was the point of putting the waiting time if it was meaningless? Well, it was a guesstimate, it wasn’t to be relied on. Oh dear.

Pass the parcel

I am sitting at home waiting for a parcel, the unloved and unglamorous side effect of internet living.

I know it left Sheffield last night. I know it got sorted in Birmingham. I know it got to Croydon. I know it’s on a van on its way to me. The only thing I don’t know is the one thing I want to know: when is it going to get here?

That’s partly because there is something genuinely unknowable about this: predicting where a van touring the back streets of south London is going to be at any point of a journey stretching over many hours is a mug’s game, even assuming that the drivers solve the travelling salesman problem in their heads each time they drive out of the depot.

But I suspect that there is another reason too: the reason I am interested in parcel tracking is not the reason the delivery company is interested in tracking. I want to know to know as precisely as possible when it’s going to get here and don’t very much care where it’s been along the way. The delivery company wants to keep track of it along the route, knowing where it is and who is responsible for it at each stage, but it doesn’t matter to them precisely when it arrives within a particular delivery window. Not very surprisingly, their logistics systems are good at answering the questions they are interested in and not very good at answering the questions I am interested in.

There’s one more thing which is interesting about all this: I am receiving a service, but I am not the customer

The customer is the company which sold me the stuff which is now either just round the corner or somewhere the other side of London. They can influence the delivery company’s behaviour by their purchasing and contracting decisions. Presumably one factor they take into account is any complaints they get about delivery issues, but unless the delivery company screws up pretty comprehensively, that is unlikely to weigh very heavily.

So what I get to see is some of the internal tracking information the company has anyway. That doesn’t cost them much to implement but gives the appearance of being an added service. I have no means of giving signals to delivery companies which encourage them either to create better quality information or even to let me see or use information they might already have but either haven’t worked out that I might be interested in or haven’t bothered to make available.  I am not sure what that might be – I can’t know what I don’t know – but some combination of GPS tracking of the van and position in sequence (if mine is delivery 50, then knowing whether the most recent delivery is 1 or 49 tells me quite a lot) might give me a much clearer sense of what is going on – and much greater confidence that something actually is going on.

There is, of course, a public service moral to this fable.  Making the data you have available is a good thing. It’s also relatively easy, so there is no reason not to do it. Building services which make use of that data is also a good thing. But even those two together don’t necessarily produce the optimum result, because the data may not have been what was most wanted or needed in the first place. And even with the extraordinary creativity of the people who have been turning open data into applications, there are still not enough ways for service users to act as customers, and still not enough being done to compensate for that by involving them much more directly in the process.

And I am still waiting for my parcel.

Getting better by doing less

The idea of service minimalism is a very attractive one.  Perfection –  in service design as in other things – is achieved not when there is nothing left to add, but when there is nothing left to take away.

I have written before about government being most successful when it is least intrusive and also about the idea that The Best Service is No Service – which is essentially that a great deal of customer contact to any service provider is a symptom of weaknesses in service design or delivery, and that understanding the reasons for contact from the customer’s point of view and in the customer’s language is a route to better customer service and greater operational efficiency.

It’s back in my mind because Bill Price, one of the authors of The Best Service is No Service was in town this week, discussing his approach with a small group of public service delivery people.  I am not going to summarise the arguments of the book – my previous post on this listed the seven core principles on which it is based – but instead I am going to record a slightly random list of points which struck me from the discussion.

The core of Bill’s experience – and the source of many of his examples – is the three years he spent as vice-president of global customer service at Amazon in the formative years from 1999.  That is a huge strength, but does mean that the rest of us who have delivery models not quite as tightly focused as Amazon’s need to aim off a bit.

The starting point for a lot of this is using customer contact as a means of understanding what is working – or not working – in the wider organisation and then doing something about it.  As Bill put it in an interview when he was still at Amazon,

You can have a great overall culture, with real empathy for the customer and passion for fixing the problems. You can have individual reps who say, ‘this customer is really upset, and I have to deal with it.’ I think we do that. What’s missing almost everywhere else is, even if you have the empathy and the passion and you address the customer’s problem, you haven’t really given good customer service in total. You haven’t done that until you have eliminated the problem that caused her to call in the first place.

Typically, contact centres need to respond to demand for contact from customers, but have no influence on the causes of the demand or any ability to communicate problems, still less to get them fixed.  Those parts of the organisation which are generating the demand, meanwhile, may have no inkling of the impact that their activity or inactivity is having on customer contact.  More importantly, they will have no means of using the pattern of contact as a tool for diagnosing the causes of contact.  Amazon went from 360 reason codes which contact centre operators were supposed to record against incoming customer contact to a much shorter list which used customers’ own language and which was simple enough for operators to memorise.  The central question turned out to be, ‘where’s my stuff?’.  That might look obvious for an organisation which is essentially a web site sitting on top of a logistics operation, but it has much wider application – ‘what’s going on, and why hasn’t it happened yet?’ is behind an awful lot of contact.

There are various ways then of understanding the pattern of contact.  One I have found helpful is in the diagram below – looking at value and irritation both from the customer’s point of view and the organisation’s.  Apart from anything else, it challenges the tacit assumption that waste, or avoidable, contact is something defined in terms of the single dimension of organisational value, an assumption to which I suspect public sector organisations may be particularly prone.

bestservicegrid

That of course depends on knowing which is which.  Bill talked about aiming for an 80% success rate for web transactions. Leaving aside the point that 80% success sounds considerably better than 20% failure, he asserted that most organisations just don’t know whether they are achieving that, because they don’t measure contact success – an assertion which nobody in the room dissented from. More importantly still, a recurrent message is that the irritation is not caused by customer contact; contact is caused by irritation.  That means that waste, irritation, or avoidable contact can only be reduced or eliminated by identifying and removing whatever is causing the irritation in the first place.  Rigorous root cause analysis is the first part of that, but eventually organisations may need to change their entire structures to allow them to focus on what really matters to customers – and Bill strongly argued for charging back the costs of contact to the part of the organisation whose actions or inactions were its cause.

The book itself has many characteristics typical of modern American popular management books:  it is easy to read, well illustrated with telling anecdotes, and longer than it needs to be.  But it’s a much better example of the genre than most, and the core idea is an important and powerful one.  I am not sure that I agree with all of it, but I do know it has made me think.

The gathering clouds, with aspect dark

There are two things I understand about cloud computing.

The first is that it works as an insurance policy. My house might burn down, my computers all get stolen, my hard disks fail simultaneously, and still I will not have lost any of the data I care most about because quietly every night Jungle Disk looks to see what’s new and sends it off to one of Amazon’s servers – now just over 65Gb.  I don’t know where, and I don’t care:  I am just confident that they are better able to look after data than I am.

The second is that it acts as a universal access service.  If my applications and data are in the cloud, I can reach them anywhere and so, if I choose to let you, can you.  For me, this blog is at least as much one of those as it is a communication device:  it’s a way of being able to find the things I half remember finding interesting long enough ago to have forgotten the other half.  It went public somewhat later when I needed the help of google, which is another feature of the cloud – tools and people can interact to get things done in ways which would be more difficult or impossible in less connected ways.  As Ars Techica recently put it:

I’m not just doing the same thing that I previously did but in a browser window—I’m actually having a computing experience that I couldn’t previously have sans cloud.

All of that can generate some powerful enthusiasm.  Dan Harrison started a recent blog post by saying ‘I love the cloud’ then rhapsodised his way to conclude ‘It’s a wonderful world, and you should embrace its wonderfully warm fluffiness with open arms’, with a string of useful examples in between.

But there is a third thing which I don’t understand about cloud computing: what does it mean for government – or for that matter any large organisation?

Digital Britain is enthusiastic:

Cloud Computing is a model of shared network-delivered services, both public and private, in which the user sees only the service or application, and need not worry about the implementation or infrastructure. The cloud offers the ability to treat IT as a ubiquitous, on-demand service and to flexibly consume as much or as little as is needed. Cloud services are quickly and easily provisioned online and feature granular service catalogues and user-based pricing.

Traditionally, large organisations didn’t insure.  If you have a thousand buildings and a normal risk profile, it’s cheaper to pay to rebuild the one that burns down than to pay a thousand insurance premiums.  Insurance is, essentially risk pooling plus overhead. If you are big enough to do your own risk pooling, you don’t need to pay for the overhead.  In this context, risk pooling means things such as having not just a data centre, but a back up as well, not just having a power supply at each of the data centres, but a back up as well, not just a data connection but…  For this purpose, I am not sure that it’s terribly important whether you have your own or rent capacity from a specialised provider.  What’s more important in the hunt for the cloud is that there is nothing remotely new about it.

As a bit of an aside, I remember the relish in the voices of two big system veterans as they discussed, not many years ago at all, the challenge of moving one of the government’s Very Big Databases from one data centre to another.  The solution?  Hire a lorry, put the tapes on it, drive the lorry where it needed to go. Hire another lorry, put another copy of the tapes on it, drive it on a different route to where it needed to go.  The only role of clouds in that story is their potential to slow down the lorries.

No doubt there is room for greater scale efficiencies in the government’s use of data centres than has yet been achieved – even governments probably aren’t big enough to pull off Google’s latest trick of having a data centre with no air conditioning that they can simply turn off when the weather gets too warm because they have enough redundancy elsewhere in their network, and there are certainly arguments that government as a whole will do better with more of a shared services approach to the procurement and use of such services.  Even then  it’s a safe bet that the competitive market for VME hosting doesn’t closely resemble the large scale standard box model favoured by cloud suppliers.  As far as I can work out, it is broadly this that is meant by the idea of a g-cloud.  To quote from the same section of Digital Britain:

31.    The strategy study has established a route-map towards the creation of a G-Cloud, as part of the rationalisation of data centres used by Government and the wider public sector.This would both allow Government to benefit from the core attributes of Cloud Computing e.g. enhanced user experience, flexible pricing, elastic scaling, rapid provisioning, advanced virtualisation while also maintaining the appropriate levels of security, accountability and control required for most Government systems, and lead to substantial savings in costs.

32.    The G-Cloud delivery model would also help make other parts of the Government IT marketplace more cost-effective, flexible and competitive. It would support and encourage the adoption of higher levels of standardisation and sharing of IT services across departments. It would allow Government to provide more cost-effectively for peaks and surges in demand for e-Government services; and it would reduce the barriers to entry to the Government marketplace for application and other IT vendors, including SMEs, who would be able to provide services running on standardised, secure infrastructure without having to incur the costs of establishing and accrediting their own infrastructure (in the same way as companies such as 37Signals have used public cloud facilities).

That is, I think, quite an important change in purchasing and contracting terms.  Cory Doctorow made the point in a recent Guardian column that

If you’re supplying a service to the public, having a cloud’s worth of on-demand storage and hosting is great news. Many companies, such as Twitter, have found that it’s more cost-effective to buy barrel-loads of storage, bandwidth and computation from distant hosting companies than it would be to buy their own servers and racks at a data-centre.

That sounds like a shift which happened a while back in other industries.  The classic example is tyre manufactuers, who stopped selling tyres to airlines quite a few years ago:  what they sell now is landings.  The same presumably applies to another trick of the cloud, not only do you not need have your own servers, still less your own data centres, but the capacity you do want can be created and disposed of on the fly.

So where does that all leave us?  As so often, I think there is risk of confusion because there are different questions (and answers) about the back end and the front end, and it’s often not clear which is being talked about at any given moment.

As far as the back end is concerned, I can see the attractions in changing the nature of the purchasing model in order to make what is bought still less tangible.  But once your unit of purchase is in data centres (or rather data centre capacity), I suspect that the impact of that may be less than it would be for smaller organisations.

At the front end the issues are different.  Paul Canning has written about the adoption of  Google apps by public sector organisations.  The focus there still seems to be on cost efficiency:  are Google apps cheaper to run at scale than Microsoft Office?  (on which I suspect that if they are, and if that starts to get significant traction, the relative prices will change pretty quickly)

But that still leaves the power of doing things in the cloud which are different and better than what can be done in the more traditional model.  For end users and for the non-IT transformational power of the latest generation of tools, that is the central question.  And on that, I am unsure what the g-cloud really is or what it will offer.

So I am left with the uncertainty I started with:  what does cloud computing mean for government?

Customer service standards

I walk in, slightly tentatively. It’s not altogether clear quite where I should be. I stand in what looks like the right area.  Nobody takes any notice of me. There are one or two members of staff talking to other customers. There is a woman whose job seems to consist of walking around importantly with a clipboard while avoiding any eye contact with customers. Eventually I manage to intercept her and state my business. She is polite and efficient and points out the completely different place I should have been standing with only the slightest of body language subtexts that I am a fool for not having known that.

Here there is a row of desks, two of them occupied, each with a conversation which looks as though it has been going on for a long time and neither with any sense that it might come to an end in the foreseeable future. At one of the desks there is an entire family; eventually the mother takes the restive toddler and the baby away leaving the father to maintain the vigil.

After a while a third member of staff appears, bringing another customer to one of the unoccupied desks. Their business is soon concluded, and I see my chance. The member of staff has spotted the risk too and immediately embarks on a clearly well practised route from where he is to the other side of where I am while at all times staying a sufficient distance from me that he does not have to acknowledge my existence. He fiddles with something in a drawer for a bit, before reversing his crabwise route and wondering if he can help me.

I explain what I want. It turns out that he can help, and he starts looking up details on his computer. He scribbles a reference number on a slip of paper in impressively short order. But then it turns out that that is the limit of his role. I now need to take the slip of paper to the other side of the building and give it to somebody in a different department who will be able actually to do what I need. All helpful now that he has a way of passing me on to somebody else, he even offers to take me to the right place and show me where to wait.

Another row of desks, only one of which is occupied. One customer at the desk, one ahead of me waiting. There are reasonably comfortable chairs:  this doesn’t look too bad.  A few minutes pass, then a woman I hadn’t noticed who had been sitting at a desk half-hidden behind a pillar got up, looked at the two of us waiting, hesitated briefly, then pulled a small trolley from behind her desk and marched into the middle distance.

After only another few minutes, the customer at the desk gets up and leaves, to be replaced by the man waiting ahead of me. Their conversation is long and intricate. Ten minutes go by. Then another ten. The important woman with the clipboard comes past and asks me if I am waiting to be seen. She apologises that there are not more staff available. There should apparently be at least one more and possibly two. She might possibly go to see where they have got to.

By this stage the conversation at the desk looks as though it may be approaching its denouement. A home visit seems to be needed and is being arranged:  the end must surely be imminent. But this turns out to be trickier than you might think. There is a big folder of papers which is the source of some critical information, but with nothing to guide the inquiring reader to the right place, so despite presumably doing this many times a day, the member of staff has to flick backwards and forwards for quite a while before finding the page she needs. This information, whatever it is, needs to be reconciled with a laminated map. With folder in one hand and map in the other, details – apparently extensive details – need to be entered into the computer. This takes almost ten minutes by itself and is almost completed when finally a second member of staff appears who is keen – or at least willing – to help me.

I explain what I need and proffer the slip of paper I acquired some lifetimes earlier.

‘What’s the significance of this second number?’ she asks me.

‘I have no idea’, I say, ‘That’s what your colleague wrote down  for me.’

She is momentarily perplexed. But soon she is able to transcribe the information from the slip of paper on to her computer which the first man had transcribed from his computer onto the slip of paper. Progress is being made.  It seems that my case is a relatively simple one, and all is done in just a few minutes more.


So, an everyday story of flabby public services, where the absence of effective demand signals, reinforced by the indifference of staff cushioned from reality of life by their index-linked pensions and the knowledge that nobody has any choice but to deal with them? A perfect tabloid story, because it fits and reinforces the stereotype so completely. I had plenty of time to think while waiting, and the thought which came most strongly to mind was the bad old days of Europe behind the iron curtain where it could take four queues to buy a single item.

Well, no. This was John Lewis (or Peter Jones to be precise), the comfort shop of the middle classes, where I was struggling to get them to measure and fit a curtain track.

And the moral of this story?  Well maybe none:  generalising from a single experience is generally a bad idea. Maybe that the temptation succumbed to by many to assume that the private sector is successfully focused on effective customer service, while the public sector drowns in muddled and ineffective processes, is one which should be resisted.

Or maybe just that sometimes a rant can be therapeutic.