The biggest operations problem carriers face is more debatable than you might think. The CFOs and most CEOs say it’s high operations cost, but some in the operations and CIO groups think it’s really customer portal problems. Telcos and cable companies alike have been cutting operations costs by cutting headcount, largely by eliminating humans as tech and support contacts in favor of automated systems. That shift has created serious issue for many of them, to the point where some say that churn created by service problems is costing more than they’ve saved by reducing the number of human agents.
Let’s look back to roughly 2016. By this point, it was clear to most operators that SDN and NFV were not going to be effective in transforming network infrastructure to improve profit per bit. The real problem wasn’t capex, the target of both SDN and NFV, it was opex. Not only is opex a larger portion of every operator revenue dollar than capex, SDN and NFV’s capex savings were eroded by opex growth. But every attempt by operators to improve opex through a generalized service lifecycle automation strategy failed as much as SDN and NFV before them.
The response of operators was predictable. Pick low apples. There were areas of operation that were human-labor-intensive, and many of those areas could be addressed (they believed) through automated systems, through portals that let customers interact with support systems without a customer service rep acting as an intermediary. These low apples had the advantage of being obvious and also being technically contained. You didn’t need an over-arching lifecycle automation system that you couldn’t really seem to get off the ground.
Now, we’re seeing the results of this one-off operations cost targeting strategy. Any major problem, according to three Tier Ones, results in a whole community of unhappy users, and this creates the largest risk to churn that operators face. Sure, competitors can lure customers with special pricing or offerings, but those can be easily countered by simply meeting their terms. On the other hand, operators say that two outages, combined with bad support experience, will mean that a significant portion of the impacted users will actively seek an alternative provider, and will stay with you only if none can be found.
Operators say that churn accounts for almost a third of opex, and it’s clear to most of them at this point that their strategies for reducing opex in other areas has increased churn risk. I did a general survey of my contacts asking not about their business networking and IT but their personal mobile and wireline broadband, and I got some interesting results.
Over a period of a year, a third of them had experienced what they called a “significant outage”, which meant that they lost their connectivity for more than 2 hours during a time when they relied on it. They had experienced this sort of thing before, but what was interesting was that every one of them said that the response of their operator to the 2020 outages was far worse than before, and just over half said that it was unsatisfactory. About a third said they’d tried to change providers. I can’t claim statistical rigor here, but even assuming this represents a kind of network-consumer elite view, it’s troubling to say the least.
One almost-universal complaint is that operator support of broadband often implicitly depends on the availability of the service that’s failed. My home or office broadband is down, but the support portal requires access to the Internet. When I try to access it via mobile phone, it’s difficult to communicate the identity of the service that’s failed. Maybe I need a bill. Maybe I’m hunkered down in a closet in my basement trying to read a little label on the router. Maybe I don’t have mobile service in that closet. Almost 80% of my contacts said that just getting to a proper support page for the service that was involved was difficult.
The second most-related problem (by over half of users) was that the status of the service being reported was incorrectly related by the support system. There were three specific problems, related almost an equal number of times. First, the system reported that the service was operational, which clearly it was not. Second, the system ran through a series of tests the user was expected to run, and at the end of the tests had no suggested remedy. Third, there was a systemic outage (the “cable-seeking backhoe” problem) and the support system failed to note it.
When a problem was eventually acknowledged, users said they were run through a dialog telling them that if this was their problem they’d have to pay for support. This often took several screens and several acknowledgements that you’d read and accepted this or that statement. They were then asked if they wanted to schedule a service call, and if they did, were told that it would take an average of about a week to get it. This, mind you, in cases where a whole neighborhood was out.
Users also said that there were major inconsistencies in the information they were given. In almost two-thirds of cases, the online support system conveyed incorrect status, and the automated voice response system, if used, offered correct information. In the cases where the problem was systemic (impacting multiple users), voice response usually provided a reasonable estimate for remediation.
International use of mobile devices and domestic wireline broadband services for consumers and small business sites are the two areas where users are most likely to be unhappy with online customer support. They’re not the only area though. Enterprises tell me that if they have a problem, they expect to be able to call a human account rep for support. They’re willing to do simple things to change a service online, but they want problem resolution done via a customer service rep. Why? “Because the online stuff” either “takes too long”, “doesn’t work”, or “requires too much skill to use.”
Broad call-center systems can be helpful in addressing this problem, but they’d have to include online support and also have to provide an agile linkage to operator OSS/BSS and perhaps even NMS systems to get the correct information. The big benefits of this path are the fact that it tends to harmonize support look-and-feel, reduces the cost of multiple solutions, and can provide for escalation to a voice call, providing that online support can be handled through the same system. However, to be effective these systems still have to meet the criteria I’ve below. This is the path most operators are currently exploring.
What’s the take-away on this? I think there are two truths that emerge in any serious exploration of customer support. First, we don’t have portals down pat, and their poor design makes things harder than they need to be. Second, we need some sort of local agent process to do things on the user’s premises. That might mean providing an app or browser extension, or it may require a feature set in the user’s device.
Suppose that a broadband access point for wireline Internet had a QR code on it. Suppose your bill had the code. Suppose you had an app on your phone, linked to your wireline broadband account, that could immediately provide information to the support connection via mobile broadband, if it was wireline that failed? Suppose that everything about service state was recorded in a common database (which it usually is) and accessed by agents, voice response, or online support, via the same set of APIs? That gets us started.
Portals are another dimension of the problem, and the solution. Too many portals are ill-thought. They take information that might be available to a CSR and sanitize it for user consumption, forgetting that the CSR has access to other information, and is trained to respond to problems that a given user may be seeing for the first time. You really need to think of a portal as a compositor of multiple information APIs, something that can compose an information view from all the available facts. In software terms, it’s a “Storefront design pattern”, and you can change the user experience quickly by changing the “storefront” appearance and the way it integrates its API-based information streams.
I think that the combination of an agile multi-source portal design and local agents to facilitate the exchange of critical information are fundamental to good customer support. That they’re harder than pasting a layer of information distribution on top of current CSR resources is obvious, but that they’re at risk of failing is even more so.
What about that systematic service lifecycle automation option? This was, is, and will likely always be my own preferred approach, and I think that by the time operators get through their one-offs and fixes and corrections, they’ll have more than paid as much for their anemic efforts as they would for a good solution. The problem is that they don’t know how to get to a good solution, and the fact that we’ve fumbled the ball on this for a decade now suggests that train has left the station. If that’s true, then we need to get customer care fixed, and quickly.