“We see customers as invited guests for a party and we are the hosts. It is our job every day to make every aspect of the customer experience a little bit better.”
An earlier post discussed value chains and the newer paradigm of value fabrics. Another post indicated how the value fabric can be used by CSPs to deliver services to customers without needing to directly invest in the networks and systems that the services are carried on (selling something they don’t own).
This poses an interesting set of OSS questions for the CSPs that “own” the customer experience but don’t own any/all of the delivery infrastructure, possibly including the networks, network designers or network installation teams.
A few thoughts to act as fire-starters for the CSP that is considering what their OSS will need:
- I believe that the people utilising the OSS, not the OSS technology, will drive the experience.
- Being a value-fabric, there will be limitations in the CSP‘s systems, the third-party provider systems, the interfaces, the hand-offs, the processes, the data, etc that will likely lead to a higher than usual fall-out rate. The front-line customer service teams (eg field work-force, contact centre, etc) will have to be able to work within the scope of these fall-outs and have the tools to efficiently accommodate them
- Knowing the business and the analytics intimately, the CSP will have better data on what drives their customer NPS (Net Promoter Score) than we do, but we could hazard a guess that the customer’s definition of quality won’t be the traditional internal metrics (eg 99.999% up-time), but will have more to do with:
- How long it takes to get a service turned on
- How many truck-rolls it takes (ie how many times the customer has to be waiting at home for them)
- How large a contact window the customer has to wait for each truck-roll (eg 8-9am on Friday rather than Friday)
- Whether the customers have ongoing issues such as billing discrepancies
- Whether the customers get mixed accountabilities across multiple delivery partners (ie CSP, third party supplier, design partners, construction teams, etc) and/or across multiple OSS/BSS platforms
- The old parable of, “what gets measured gets managed,” will need to apply to the OSS/BSS. The OSS/BSS will need to identify if any of the above metrics are being breached and have the processes in place to act upon them. A customer simply wants a working service with as few interactions as possible. For example, We see customers as invited guests for a party and we are the hosts. It is our job every day to make every aspect of the customer experience a little bit better.”– Jeff Bezos
if they have made more than X number of calls into the contact centre, then they are going to be unhappy with the CSP‘s service (albeit backed by third-parties). The CSP will have to know what strings to pull if/when the metrics are breached and what remediations can be made. Predictive analytics and decision support systems may be required here
- In a competitive environment, the questions will also have to be asked as to whether/why competitors are able to pull the third-party’s strings more efficiently (eg why the competition can respond faster). Are their processes simpler? Are there less layers of accountability (and end-to-end accountability)? Are their systems (OSS, CRM, order entry, field-work-force) better? Do they have less reliance on systems and more on customer / front-line staff management
- The CSP is accountable at the start of the river (ie handing over service order information, systems and data) and at the end of the river (ie ongoing customer support), so as much OSS/BSS effort should going to the upstream side as the down-stream side, if not more, to ensure the third-parties are able to limit the CSP‘s support burden
- Starting with the down-stream situation in mind (ie the dot-points under item 3), what does the CSP have to insist on their third-parties implementing? For example, truck-rolls could be wasted due to requirement of special equipment, special install skills or special instructions to complete the job. There also needs to be mechanisms for CSPs getting feedback into third-parties if/when metrics are breached (item 4) and ensuring the have the mechanisms (and encouragements) to rectify breaches