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.