Pull The Other One

After a couple of forays into the worlds of wildlife and motorway driving, I return briefly to the subject of food and drink, largely because once you have been afflicted with seeing everyday situations from a systems perspective, the pub is a rich resource of good ‘case studies’ to blog about. Honest. I’m a researcher!

Today’s example is a pretty straightforward lesson about system design and how to optimise it to meet the customer’s or service user’s requirements. It’s as relevant to policing as it is to landlords. What strikes me though, is how often the basic principles I’m about to outline are completely disregarded. Hey, if you’re looking for reduced costs, greater efficiencies and happier customers (or service users), what follows is a no-brainer…

Pulling pints

Yesterday I went for a bite to eat and a pint at a town centre pub. Nothing unusual about that, you might think, but what was unusual was the bizarre method this place relies on to serve drinks. Normally you would just ask for what you wanted (in my case the usual small lemonade – ahem) then the bar staff would pour it and pass it to you. Not here. Once a drink has been ordered, customers must leave the bar area and sit at a table, then wait for another member of staff to pick up their drink and bring it to them.

Now, I’m all for table service if that’s what you want, but I cannot understand the logic in basically refusing to hand that refreshing glass of lemonade straight across the bar to the thirsty customer. Of course what happened as the place got busier was that lines of drinks were building up behind the bar, as the staff responsible for delivery duties struggled to keep up with demand. This demand would be hugely reduced if those customers who simply wanted to get their own drinks were allowed to do so. It would also mean that others who do prefer table service experience a faster service, as a proportion of the existing drinks queue would no longer be present, thereby affording the process additional capacity with which to handle demand.

As it happened, the system design resulted in delays and frustration for people like me who could see my drink stuck way down the line in this daft inflexible process. Ultimately it also costs the business, as customers like me are unable to put away pints (I mean lemonade) at the rate I want.

The traditional method of simply passing the drink to the customer at the time of ordering works best because of the systems notion of pull. Essentially, this theory is no more complex than designing the front end of your system to meet demand from the perspective of the customer or service user. The customer is always right, as they say, so give them what they want if you can. Let them pull what they require from your system – don’t push at them what you think they want. If they want table service, great, the option is there, but why make it the only option?

Such an inflexible method of serving drinks is incapable of handling predictable demand and leads to unnecessary stages in the process (i.e. staff having to ferry drinks from bar to table), bottlenecks (i.e. drinks queuing behind the bar until someone is free to deliver them), impaired and uneven flow (i.e. having to unnecessarily wait for your drink for varying amounts of time), higher cost to the business (less drinks sold, more staff capacity required to operate under this model) and potentially frustrated customers.

Notably, none of this occurs because those operating within this system are bad or lazy individuals. (This is a really important point).

So… what are the lessons to be gleaned from this traumatic episode and how do they relate to policing or other non-pub-based systems? Well in summary:

1. Systems should always be designed to meet purpose from the customer’s or service user’s perspective. Pull, don’t push.

2. One-size-fits-all ‘solutions’ do not work. They are incapable of absorbing the variety present amongst demand.

3. Inflexible operating models generate waste, higher costs and dissatisfied end users.

4. No matter how hard they try, workers can only perform to the extent that the system design permits. (Deming’s 94% / 6% rule).

Doctor, Doctor!

Next, let’s have a look at how these principles transfer into public services…

Recently, a friend of mine underwent some medical tests and subsequently received a letter instructing her to book an appointment with Dr Smith to discuss the results. She duly phoned the GP’s surgery and the conversation went like this:

Patient: “Can I book an appointment sometime next week with Dr Smith please?”
Receptionist: “Sorry, we have no advance appointments for Dr Smith. You can book an appointment with Dr Jones if you want though”.
Patient: “I really need to see Dr Smith, as she’s the one who sent me for the tests and knows my medical history”.
Receptionist: “Well Dr Smith is the duty doctor next Wednesday so perhaps you could try then”.
Patient: “Yes, that’ll be great. Can I book an appointment next Wednesday then please?”
Receptionist: “No, you will have to phone up at 8am next Wednesday morning when we open”.

The result of this inflexible system is that the patient may or may not get to see Dr Smith. It all depends whether she will be one of the lucky ones who manages to get through the stampede for appointments that occurs every morning at 8am.

None of this is the receptionist’s fault of course – it’s the system again. In this case, the root cause of this madness is the 48 hour target for GP’s appointments. The situation is an example of another rigid front end that works against the service user, generating waste, uneven flow and huge frustration.

A much better option would be to allow the patient to pull what they require from the system. Deregulating the appointments process and removing the target would stop the mad rush for appointments, resulting in much more even flow and a front end more capable of absorbing variety. It would also let those responsible for managing the system know if there is sufficient capacity to meet predictable demand…

Different setting, same problems.

Dear Diary…

Finally, we come to policing.

Using that four-point checklist from earlier, let’s see how the principles can help create a more responsive police operating model…

Let’s say that the fabled Mrs Miggins calls the police to report some anti-social behaviour. Now, a systems-orientated model would first have us consider what purpose is; i.e. what response / outcome would Mrs Miggins like to see? It could be something as straightforward as ‘stop the bad thing from happening’. This then acts as the cue to determine what the appropriate response would be. Probably something as straightforward as ‘deploy an officer to speak to those involved and take steps to prevent a reoccurrence’. Easy.

In essence, Mrs Miggins has communicated what purpose looks like from her perspective and the police have responded in a manner that meets it. Pull in action. This is efficient, effective and reduces failure demand.

Now, what if the operating model had insufficient resources to respond in this manner? Well, the operator might have to book a diary appointment. This means that Mrs Miggins could receive a visit sometime later that day, or maybe even the next day (or later). Of course, by then the problem isn’t happening anymore, meaning that the officer can’t deal with it as effectively. It also increases the likelihood of a reoccurrence, thereby generating failure demand.

When a member of the public genuinely wants a visit at a time other than when they called the police, diary appointments are fine. They are not fine, however, when they are the only option given to the caller (think enforced table service or rigid GP appointments – same principle).

The solution? Well, there’s no better alternative to dealing with today’s problem today. If this means redesigning the front end of the operating model so as to absorb variety and handle predictable demand, then it should be done. It’s cheaper in the long run anyway. A larger, multifunctional initial response capability is much more able to achieve purpose from the service user’s perspective, as opposed to fragmented operating models that rely on rigid protocols, tight remits, handovers and departmental silos. Therefore, design your system so that the service user can pull what they require from it.

The result? Better service delivery, lower costs, reduced failure demand. What’s not to like?

Now, where’s my drink? 😉