Treat your customer as valuable

Hospital
Treating your customer as valuable could be the first step to understanding what your customer values.
 
Shopping Carts
Shopping Carts

I went shopping in my local supermarket. It was eventful for the number of things that went wrong for me, all of which could have been prevented with some foresight and some real-world gemba.

 
It was early in the morning so I had chance to see the store operate with fewer customers. This also meant that I could move around the store quicker than usual. So from that perceptive, the shopping expedition was a success….at least until the checkout process.
 
For a large supermarket, there were no checkout assistants at that time in the morning. Instead, there was a bay of 4 self-service checkouts. That’s not too bad, I find them very useful when I have a handful of items. However on this occasion I had a full trolley and had no choice but to use the self-service checkouts. The first issue with this is that there is very little space to put items once you’ve scanned them. To keep scanning more items, I had to swap out each bag once I’d filled it. Every time I did this, the machine told me off. This meant that a checkout supervisor had to come across and tell the machine to ignore the missing bag. That dance occurred several times since the trolley was full.
 
I valued the speed and efficiency of being able to pick my items at my convenience. I didn’t mind whether I scanned the items or whether they were scanned by a checkout assistant. However I did mind the lack of planning for catering for shoppers who had more than a basket. And I minded being reprimanded by a machine for solving a problem that it was creating. I’m confident enough that I have zero issues with being reprimanded by a machine; it’s just a set of algorithms encoded by another human. In this case, a human that didn’t foresee the machine being attached to a tiny tray and being used by a shopper with a trolley. But I did mind the rigmarole that it created.
 
Discharge
Discharge

I had a brief stay in hospital a few years ago. Everything ran smoothly until I was discharged. From my perspective, I was still a patient regardless of the official status. I was in hospital, feeling lousy and weak after 5 days of little to no food or drink and due to continue with medication for a further 7 days. Nothing major, but enough that I was allocated a hospital bed (if you’re familiar with the UK’s NHS, that’s a good measure of a condition). I was discharged in the morning, roughly 9:30am and was due the following dose of medication at 10:30am. Unfortunately, medication after discharge isn’t dispensed by the ward staff, it comes from the hospital pharmacist. I spent 3 hours waiting for the hospital discharge to deliver my medication to the ward so I could go home. That meant I couldn’t arrange transport since I didn’t know when I could leave. More importantly to me, the medication I was due at 10:30am didn’t arrive until the afternoon. During this time I occupied a hospital bed, although I think I would have been moved to a day room had the ward been full to capacity.

 
 
 

Analysis

At that time, NHS hospitals in the UK had a 28 day return policy, in that they were fined for patients who were readmitted for the same condition within 28 days of discharge. That goes some way to ensuring that discharges are medically appropriate. Unfortunately it doesn’t go to check that the discharge process itself is appropriate. It’s still focussed on the condition that the person was originally admitted for, rather than the smoothness of the discharge process. It’s as if the patient is no longer a patient once medically discharged, assuming they will be safe in their environment (e.g. home). The actual situation is somewhat more intricate than that but the effect on the discharged patient isn’t any different. To them, they’re still in hospital, still expecting the rest of the hospital services to be working to achieve the full discharge (not just the medical discharge).
 
Similarly, for the supermarket. The main experience was great but marred by the part of the process where I actually get the goods I pay for.
 
In neither of those cases did I feel fully valued. In the case of the hospital, I can forgive easily. However, from the perspective of efficiency, there’s a lot to be said for getting me out of the hospital as quickly as possible, so as to free up resources for others who need them. The more time I spent in the hospital following the medical discharge, the more failure demand I created (simply by being there, not that I created it on purpose). And the more risk of something happening while I was on the hospital grounds.
 
This leads onto the peak-end rule where we attribute a large portion of our memory of the experience based on the peak and the end of the customer journey. So no matter how good a service you provide to your customers, they’ll remember how it ends.
 

Look at the Evidence – the Spike and Delay Pattern in Social Care

signature
A number of years ago, I was transforming a city’s social care directorate and, as part of that transformation, we aimed to reduce the time it took to do anything when interacting with the service. The transformation was based on a more fundamental need to free up workers to be able to do the work they were meant to do rather than having to fight the fires caused by delays and resulting failure demand. I instigated a methodical approach for identifying which cycles to focus on first. As the team progressed through the cycles, I noticed a pattern; it’s the spike of activity followed by a lengthy delay as discussed in a previous article.
As we looked in particular at a few cycles of spike followed by a delay, I routinely advised the team to question the need for that common feature of bureaucracy: the signature.

Why require a signature?

In the case of social care, signatures are often required from service users or their representatives. This can be as proof that the content of a form is accurate or as a record of the service user providing consent (either for data to be shared from the form or for the authority to request data from other agencies).
These signatures create the spike-delay pattern in which a short spike of activity is followed by a lengthy delay while the authority sends the form to the customers and waits for the return of a signed copy. Part of that delay is caused by the postal service in both directions. Part will be the time it takes the service user to open the letter, read the form, make amendments, find an envelop and stamp and then go to the post box. Considering the high percentage of infirm service users compared to the general population, that sequence of activities can take a long time. Then we have the additional wait time caused by processing the response as it arrives into the authority.

First approach

So, my first instinct is to remove the need for a signature and thereby remove the need for the spike-delay round. This could be changed from requesting a signature to providing information on the form that the data will be used. If you don’t agree, don’t submit the form. The response from staff was that we needed the signature as a record of consent and/or accuracy, depending on the form in question.
On the fact of it, that seems a reasonable and fair response.

What does the evidence say?

However, the data showed a different reality. What actually happened is that, even if the form wasn’t returned, the process could still go ahead. True, it didn’t go ahead for every service user, but the fact that it could proceed implied that the signature wasn’t always required. Or rather, wasn’t required all of the time. We were able to look at the data to understand how many service users progressed without signature, we were able to look at common characteristics, etc.
By presenting this understanding back, we ended up moving forward in our joint understanding of the process; joint in that the consultant and the team had the same understanding. Before that point, they had had different interpretations.

So where does that leave us?

An undocumented process or exception is a risk. In the above case, we had uncovered that some of the cases were allowed to progress without signature, but there was no documentation defining which cases could proceed and which cases had to stop. Instead it was left to individual judgment, but again without defined criteria. So what happens if the usual staff members weren’t present? Were the decisions they made equal and equitable to all involved? How did we measure the outcomes?
Depending on the type of organisation and service involved, there will be a different focus regarding the risk involved.
In this case, we had a process with an unclear gateway, e.g. do we continue or do we halt and wait?
  1. Complete the analysis in terms of understanding when the process can continue.
  2. Engage with service users to understand what they need out of the process, what their engagement should be
  3. As a team, choose a default option, either they progress by default or they pause by default
  4. Help the team define the rules that govern the exceptions
  5. Implement a training and induction programme for ensuring that everyone knows how to apply the rules
I always prefer the default option to be the one that improves efficiency, e.g. the one that’s the most common option or the one that removes a spike-delay pattern.

Impact

The wider understanding that, in most cases, the signature wasn’t required let us to a better solution. Had we not challenged either with data or further questioning, we would have been left with the difficult situation of lack of signatures stopping the process and the resulting action of requiring signatures in order to proceed. Instead by challenging the assumption and developing solutions to the issues of the spike-delay caused by several signatures for a sequence of documents, we were able to reduce the expected time from 6 months down to just over one day (actually 2.5 completions per week). That’s a massive difference in expectations for customer and the organisation serving the customer.
Anything to say, get in touch at @alanward.

The Value Affix – Xtech and Why I’m Fed Up with Tech part 2

ecommerce

I wrote in the previous article that we don’t need a separate xtech for any given sector x.

Abstracting further, the focus should be on the customer, not the technology.

We see healthtech, fintech and insuretech which indicate the use of new technologies to improve existing or introduce new business models. But technology is just one factor that could be changed.

Historic changes to business models

Instead we could be changing other elements of the business model.

We’ve already seen the changes introduced during the shift from bricks-and-mortar to online. We stuck an “e-” at the beginning of everything. If it’s Apple-related, maybe an “i”.

We saw segmentation and stuck a CRM at the end of it. And I still chuckle from hearing a supplier introduce “farmerCRM” at the time. In that room, we had all misheard PharmaCRM which made more sense consider the state of the market, although nowadays farmerCRM or more formally agriCRM has enough market presence.

Sometimes we did both and added an “e” and a “CRM”, e.g. ePharmaCRM. Although that was more a proposition from one company than an industry concept.

Then organisations started to realise that not every customer type was the same, so we removed the ‘C’ out of CRM and replaced it with ‘P’ for Partner, ‘E’ for Employee, “G” for Government, etc. Fortunately that died out and we are left with CRM for any type of customer.

We looked at how the channels were being managed and ended up with B2B, B2C, P2P, G2C and so on.

Moreover, some brand names have become synonymous with the elements of the business model they’ve changed.

Think cheap, put an “easy” at the front

Think everything related in one place, put an “rUs” at the end (although at the time of writing, maybe that should be Chapter11RUs?)

And we can continue with the other elements of business models looking for the affixes that denote what’s being changed. Unfortunately, we can also use those affixes to misdirect prospects by indicating that we’ve changed but we haven’t, instead we’ve just stuck an “e” at the front because everyone else does.

Focus on the Customer

Whatever element we’re changing, the focus should always be the customer, or rather, how to deliver more value to the customer.

Based on that concept, should we also see healthvalue, finvalue, insurevalue, etc? However similar to the tech suffix mentioned in the previous article and how techtech is absurb, adding value as a suffix also sounds absurd, but for different reasons.

1) The word “value” is being hijacked

The word “value” has become a euphemism for cheap and a synonym for budget, e.g. “you’ll want our value model” meaning “cheap model” or “budget model”. The word has been hijacked by brands not wanting to admit to customers that it’s a cheaper, inferior product to what they could have bought. I remember returning a drill a few years ago because my house broke it. The clutch on the drill had not coped well with the dense bricks and so the drill had stopped working. I returned the drill to be asked “what did you expect? That’s a value drill.”

On one hand, when viewed as value=cheap. That’s just on the edge of being an acceptable response, but should be followed up with how they can help me.

On the other hand, when viewed as value=worth of good received for total cost (money, time, effort) of transaction, then it implies that every other model of drill in that shop doesn’t provide value to the customer. We can then infer, from using the word as commonly defined in the dictionary, that I had obviously bought the right one for me as it was the only one that provided value.

However, in the parlance of that brand, and many other brands, I’d bought a cheap, inferior product. So we’d have to question whether value is the most appropriate term.

2) It’s all just improvement

By affixing a suffix, we lose sight of what we’re trying to achieve. We allow ourselves to abstract from the domain and the problem at hand, and immediately focus on our solution to resolve that problem. That’s definitely the case for the “-tech” suffix or the ‘e’ prefix. By adding -tech, we’re implying that our solution is tech and it will resolve the issues in that sector or allow us to expand into that market. However there may be more appropriate solutions than tech, so we shouldn’t be constrained by that.  Interestingly, the “-value” suffix doesn’t constrain us in that way, so maybe it is suitable after all.

But we still must be aware that what we’re trying to do with every initiative is to improve. It’s either improve our marketshare (and investor returns), improve our efficiency (and hence profits), improve the life of our customers or some combination thereof. Even if we’re innovating or inventing to get to that point, it’s still an aim to improve the position.

Conclusion

So instead of creating yet more hyped portmanteaus, can we simply stick with the original sectors?

Instead of saying you’re in Fintech, say you’re in Finance and you’re increasing the value you provide to customers everyday. You may do that through technology or you may do that by improving the partnership relations. Or probably both. But it’s still Finance.

 

Since I started writing this article, I began to formulate a 3rd article in the series.