I’m assuming that if you’re reading this blog, chances are you’re already an OSS/BSS expert, or spend a lot of your working life thinking about them. Perhaps you do more than think about them and actually help to implement them in some way. Perhaps you don’t implement them yet, but have been tasked with understanding them in more detail.
During those activities do you spend much time thinking about the end user (EU)?
But I guess I should first start by classifying who I think our EUs actually are. They can fall into a few different categories:
- Internal EUs (IEUs) – If you’re developing an OSS/BSS in-house, then you might be providing a product / service to your colleagues in network operations, IT, sales, etc that helps them do their job
- Client EUs (CEUs) – Similar to IEUs, but you’re providing a product / service to a client’s team in network operations, IT, sales, etc. This generally implies that you’re an OSS/BSS vendor or integrator that is supplying a solution to a client like a telco, utility or enterprise customer. Your solution helps them to provide a network-related service
- Ultimate End Users (UEUs) – These are the people who consume network services. The IEUs and CEUs simply provide support to the UEUs to ensure their network and related services are all operational and usable.
My gut feel is that we don’t tend to think about UEUs very often. After all, I sometimes wonder whether our clients (eg telcos) only think about them in terms of how to avoid them.
The UEU calls the help line because they want someone to help them. But that’s expensive for our clients (eg telcos), so they’d rather:
- IVR them or
- Chat-bot them or
- Point them to canned URLs / FAQs or
- App them
“When you are the upset customer, you want a full, uninterrupted hearing, you want to deal with someone with the authority to fix the problem and you want a fair resolution. You don’t want to be sent a copy of the company’s warranty policy.”
Jeffrey J. Fox.
The “typical” approach to handling upset customers (UEUs) for our telco clients is akin to sending a copy of the company’s warranty policy.
But the telcos are in a bit of a catch-22 situation. They want to keep customers happy (ie they don’t want churn). But they generally don’t have the tools that give sufficient insights about why the customer is upset. An expensive call centre operator (CEU) often adds little extra value than the cheap customer avoidance channels dot-pointed above. So customer avoidance mechanisms are invested in.
For example, NOC operators (CEUs) can see logs, alarms, performance within their network, but that doesn’t often directly translate into a user’s experience. It certainly doesn’t translate the network telemetry into words / actions that a contact centre operative (CEU) can clearly communicate with UEUs (especially non-tech-savvy UEUs).
Personally, I think this is a massive opportunity for OSS/BSS developers. If we could create the tools that:
- Could reliably interpret real UEU experiences (ie health of the service as experienced by the UEU, not reverse-engineering nodal info and guessing what the experience might be)
- Diagnose degradations / failures / fallouts / problems in UEU services
- Translate the diagnosis into actions / recommendations – either for the UEU to perform as self-help, or for CEU / backend-systems to repair
- Inform UEU of what’s happening and when the problem will be solved
- If the customer calls before a proactive notification can be sent, ensure the collective telemetry insights / recommendations are available for contact centre operators (CEU) to help resolve rather than deflect the problem
… then there would be less incentive for building the annoying customer avoidance mechanisms. If we can do that, OSS/BSS would surely pick up more of the investment that’s currently carved out for chat-bots, IVR, etc. It’s a new/improved revenue line, but only because it better helps the people further down the line who ultimately pay our bills.Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email