Downloadable Service Design front office demand workflow diagram
This is a freely available technique to aid understanding the value, the customer experience, and the impact on the service generated at the front end of a service design.
Almost all public sector and private sector services start with demands: banks, insurance, bookings, transactional services, online sales, etc.
The questions that the designer may have at the point of the demand arriving is;
1. What are we doing with that demand when it arrives at our interface with our service?
2. How does that interaction affect our engagement with our customer, and how much value does it provide?
3. What waste is in this flow?
To help understand how this works, there are sample demands and their logic described on the right hand side of the workflow.
Resolve
Get resolution at the point of transaction right, and we have the possibility of a successful flow through the organisation, and a happy customer. We want to be resolving the demand at the time they call, and we want to ensure that the organisation involves the least number of persons to answers to the question (Ideally just one person)
Where we have to pull for some support to answer the demand, we should ask ourselves why we are involving two people to answer one demand?
Pass Back & Pass on
We dont know the answer, and we pass it back, or pass the call on, and we could create lots of waste work for ourselves, and make the customer experience a poor one. A smooth flow according to what the customer expects, is ideal.
Sometimes the demand calls for a further transaction, and thats fine. But we should ask ourselves what value have we created at the front end when passing it on. What is the point of the front end if we’re not creating value there?
Using the Demand Logic
I listen to demands into an organisation for a few hours at a time for a service. Using a headset I listen to the demand , and listen to what the customer is expecting to get out of it. Is it a query, an instruction for further actions, is it expected to be answered now? And I track what happens to those demands during the call. (It is also a great opportunity to understand the nature of the demand itself and what matters to that customer, for when I need to look at the customer journey)
If the call handler puts the call on hold and asks a back office colleague the demand question, then are we double handling? If we cannot get hold of the back office, then what do we do?
About 30 calls is a basic level to begin to get a pattern of the demands coming into a service. If you then match the demands to the Demand Logic, then you can assess the effectiveness of the front office call handling.
