By mmatee / Shutterstock.com
Oh good, yet another maturity model! Yes, but this one, like the good ones out there, delivers not only a suggestion of the problems we face in fulfilling customer orders, but also suggests a roadmap to address the interdependencies and rising complexities in achieving various levels of delivery and customer experience.
Fulfilment, what is it?
Fulfilment is the action a service provider takes to deliver something to their customers. It is seldom about infrastructure delivery, it is more about ensuring that the intended delivery to a specific customer is met.
In the digital and telco service world, fulfilment is about setting up services that customers have bought, such as a mobile voice service and the associated voicemail and text services. In Amazon’s world, fulfilment is getting the thing you bought in the store picked from the self, packaged and then delivered to the address of your choice.
A classic example would be a voice mail service for a mobile voice line. Somewhere, somehow, a bit of compute and store needs to be linked to the mobile voice service, or the client will not have voicemail, or they will not get text notifications that a voicemail message is in their mailbox.
This maturity model also suggests a metric to measure the effectiveness of the process at each level of maturity. When it comes to metrics, the more mature your process, the more metrics you will have. This is because greater maturity is dependent on underlying process effectiveness.
Level 1 Maturity – Fulfilment for Service
This is a foundation for all that follows. The fulfilled service has to work. If it is not working, then it is going to cost the service provider time and energy to fix the problem, and that will continue until it does what it said it would do on the tin.
Fulfilment for service is not that hard, and often service providers can limit this type of transaction to a single resource provider vendor’s management system. In the telco world this level of maturity has been part of the industry since inception.
A useful metric for this state of maturity would be % failed requests, or the mean time to deliver.
Level 2 Maturity – Fulfilment for Billing
But wait, surely this is not an option?
Yes, it is optional. Those of us who have been in telco for a while will remember the days when services were offered to the public, and then we figured out how to get the billing interface working. There are many terms for this, but free introductory offer is an oft used customer facing message.
Holding your fulfilment at level one – service only – is also a great brand launch tactic. Jio in India has just completed a cycle of this, and has managed to disrupt their competitors while boosting their own brand.
Setting up your systems so that the billing happens if the service works, and billing does not happen if the service did not get set up is hard. You need to integrate multiple systems, and you also need to understand which transactions to roll back under what failure conditions.
A useful metric for this state of maturity would be % requests not charged for, a classic RA metric or Mean Time between Order and Invoice.
Level3 Maturity – Fulfilment for Assurance
Now we start getting tricky. We must make sure that we can easily see what state each service is in from a central abstracted view so that if something goes wrong, either first line support or an automated response can fix the problem. This is to address the time-consuming and expensive need for trained and experienced experts to manually look at each service management platform when something goes wrong with a service.
Setting up multiple services across multiple management systems and the relationships between them is not easy. What makes this even harder is that once set up, things do not stay the same, and our wonderful centralised view needs to be able to include the current state of the services if we are to get the full value of this form of fulfilment. This implies that this level of maturity of fulfilment is not surpassed until we have also set up the parameters to efficiently monitor a service as well as the service parameters themselves.
A useful metric for this state of maturity would be MTTR – Mean time to Repair.
Level 4 Maturity – Fulfilment for Security
This is really difficult. The brutal reality of digital life is that baddies are trying to find their way into your systems. This means you need to plan to keep them out and you have to be able to tell if a change that happened in your system was made by an authorised user or a baddie.
This means that when you get the service going, when you set up the billing account for the service, and when you set up the management view for the service, you are going to have to ensure you had the right permissions, that the setting for any service are in line with the business rules for the product and that you safeguard what the settings were at initiation. Using default security and authentication settings is a clear indication that this level of maturity has not yet been achieved.
This complexity is increased by the potential for each service to have different ways to be protected, and also by the need to adjust service parameter values over the lifespan of the service. This little tale deals with a failure to reach this level of fulfilment maturity
A useful metric for this state of maturity would be % security audit fails, or the number of security breaches.
Level 5 Maturity – Fulfilment for Platform Business
Until this level of maturity, we had a tacit assumption that the initiation of the service fulfilment was within the service provider organisation. If we start looking at a platform business, where capabilities are exposed to external agents, we find that all of the fulfilment actions listed in the lower order maturity fulfilment processes have to be robust enough to live in the wild.
This level of maturity requires deep automation of fulfilment processes, and effective means of meeting any delivery metrics and other quality measures. There are also considerations such as the best way to group the allowed actions, and of course, ways and means to measure if the solution is delivering an acceptable experience to the system users. It is important to note at this point that this is a multisided model, and while your end customers have choices in the market, your system users also now have the option to use your solution or not. The system user experience starts to match the customer experience in achieving utilisation and revenue goals.
A useful metric for this state of maturity would be all the above metrics, but with a comparative split between internal and externally initiated fulfilment requests. The experience aspects can be covered to some degree using net promoter scores.
In conclusion
I have proposed a relatively simple maturity model to assist service providers in their journey to deliver excellent customer experience of fulfilment actions. I have not suggested any specific values to be targeted for the metrics.
There are two good reasons for that. Expectation of these values vary greatly between industries and markets, and secondly, a good value for this season may be woefully inadequate next year as the competition hots up.
This model is a journey to continuous improvement, and not a specific goal.
Recent Comments