Customer Service design & Digital
Well, we have been working with the demands coming into the organisation, and also realising that some of these demands are the result of a previous interaction, via digital intereaction or as part of the workflow. The learning so far is that the snapshop that we collected is very helpful for leaders to decide what to do next. So, at 1:25pm we brought in the Chief Executive, CS manager, and a director for digital and CS to:
- see what we had been doing,
- why had we done it
- what we have learned
- implications for the next steps
The feedback took about 15 minutes, with questions and discussion. Then we got on to the subject of the real learning for the organisation and how to take it forward.
We agreed to handoff the CS work to the CS manager and his team. And to input knowledge to the new CRM and Digital work.
Passing on to Customer Service
Getting back to the work we have already done. Our new approach to analaying demands is helpful for the future, and the leaders are considering if and how we should continue to record them. If we wish to improve, how will we know if we have made a difference if we cannot compare outcomes before and after? This type of analysis will help us to have a baseline. So, I also had a discussion with the customer services manager, 30 min this morning, and we have agreed that this work is now something that I should complete as a consultant, and the work move to a leader to implement into his service. There are three aspects to this:
- The physical implementation of front line staff recording the demands and their categories.
- The thinking behind customer services as being part of the end to end service, contibuting and enabling the public to solve the problems they have.
- The behaviours that need to change in both managers and staff so that the points 1 & 2 above become effective.
So, tracing back to my original agreement. The total time to complete the CS analysis is 15 days. Time spent so far 10days at this point. I have not quite finished yet, but the outcomes now could not have been predicted when we started.
Next steps
OK, just to be clear. I know that I dont like admin, and I undertake emergent and iterative designs. But this is quite lacking in formal structure. Usually my work has more formal designs and plans, but then you have a small organisation, very good engagement and trust, then this flexibility is far more appropriate. I am also surprised by the enthusiasm and speed of those involved in all this. Its not usual. What has helped alot is the fact that my knowledge from previous times doing this means that I can see patterns and have knowledge of doing this before that then helps me to advice the client after perhaps little analysis and with trust that what I am saying is valid. I always take them on the journey with me.
The Customer Service Work
I have found nothing more valuable than actualy listening to demands myself, with a headset sitting next to the staff answering them, and in total I think I have spent the equivalent of three days listening. I hear the actual demand, what really matters to the caller, and the reactions and workflow from the staff. I will never use any consolidated and summarised information, un til I do this listening. I dont know of a better way of understanding without bias.
And there comes a time when this information needs to be summarised and learned from.
One of the most important things I have seen time and time again is the translation from what someone has learned and is in someones head, to transmitting that to someone else. We typically use reports, and I find that a report can contain merely a fraction of the knowledge that I wish to convey. So I dont use them.
I have sat with my person who is working with me and helping me from the council, (they are working on this full time, and I am two days a week), and we sat down for some time and came up with these summaries.
Demand summaries
These are designed to be discussed with people, not sent by email. They describe some of our learning with regard to overall calls, emails and one service in particular — repairs. If I start with actual demands, then we can see what natural groupings emerge. This will help us to eventually focus on groups of people, but it depends on what we are trying to achieve with the data.
For instance, we discovered that Council Tax demands are generally transactional and resolution can happen on the phone. However, if a tenant is behind on their rent, that call is one of us needing to understand if that person is getting into financial difficulties because they are having serious issues at home. We need to know that. This is an example of a demand that is far from transactional, and involves a different set of skills to remedy.
This shows a different take on the concept of personas, as personas are often used in some circumstances, and often grouped as the organisation wishes to see those groups. Anyway, I suggest caution when creating categories of demand and those who make them.
Final Demand Summary
The overall purpose of reviewing the demands is to help heads of services to understand their service, from the point of view of demands. So, I designed and came up with a format and overview that focuses on this, and helps them to understand all the jumbled learning in our heads. It is easier to standardise a output summary, but the value in creating something for the client is paramount in my view.
version 2 of Demand summary learning for Repairs
The demand types are categorised into Value and Failure, with failure being those that the system has created by not doing something right.
The codes are central to linking the front end to the individual service and what value it brings, or not. We started with Resolved, Passed back, and Passed On. And we have now detailed greater analysis with real value for the service and customer services together, and have nine groups. I will post a better version of the flow codes soon as someone in the team is developing a digital diagram. At least you can read the code legend, and I have added the value that they provide in that legend. This document will become a foundation of a good conversation with each service head.
Frequency is a simply highest frequency of that demand type.
Looking at some of the different services. it is clear that Repairs could have an element of Digital front end to it, as the request for a repair is a simple transactional demand However, the greatest demands are failure demands that reflect a failed service. This needs to be remedied at the same time as the Digital design. On-top of that, when we listen to calls, we get a real sesnse of the urgency of the problem. Especially with the failure demands, we need to understand the issues and conditions of the problem, that affect the person.
Another service, Council Tax, is very ready for Digitalisation, except for the important demands of those who have a problem paying. Then, were suddenly into complexity and helping people who are in trouble. I will post more detail in another post about the different services, as the summaries also include knowledge about how to redesign each service end to end.
Finally, Digital
For those who start with Digital, you will see that this approach has taken its time to go to Digital. In fact, it has only taken about 12 days of my time to get here, and anout 30 hours of my assistant from the organisation.
So, why this design? How could we rush to Digital when the underlying workflow is not fit for purpose, or designed sub-optimally? At this point, with the demands pointing to different interactions with the public, it would have been foolish to jump into the digitalisation of services without going throuth an analysis of the complexity and end to end understanding that we did.
My ‘assistant’ Emma who has been working with me, can now work with Refuse services and help them design the Digital front end, with minimal support from me. I have transferred enough of this approach for her to know how to do this on her own. This for me is a crucial aspect of this work, that the client can now reap the benefits of using me.
