Putting our full weight behind a decision that could be revolutionary in its value for our organization — or catastrophic, if it goes poorly — usually comes with a big price tag. Even if it’s not expensive in terms of the dollars-and-cents we need to spend to make it happen, it can be quite expensive in the number of man-hours — or in the social and political capital required — to accomplish it.
Suppose, for instance, that we find that our call center employees perform better in resolving customer complaints when using customized scripts in their conversations with customers. We then investigate whether it would be possible to bake this new “custom scripts” process into the call center’s standard procedures. We would need to not only train the employees on how to use the scripts in their conversations; we would also need to create a scalable process that can affordably provide those scripts based on customer data.
To solve the scale problem, we could hire people who focus on nothing but writing scripts in real time for the call center representatives. But this comes at significant cost and overhead. We would need to train those people. We would need to pay them. And we would need to keep them happy to reduce attrition rates, as routine script writing is a rather boring and thankless job. We are hard-pressed to imagine an entire staff of people paid just to write scripts on the fly for call center representatives; they would have to secretly listen in on the calls, violating the customer’s sense of trust, or at least creating an awkward situation in which there are three people on the call, but only two who speak. It is almost a certainty that the representatives relying on the scripts they write would grow frustrated with the delivery: a slow, teleprompter-esque interface riddled with typos.
Alternatively, we could use a technology platform to provide the scripts to our call center resources. The technology platform could use a large language model (LLM) that would ingest data about the customer at hand, the situation the customer has raised in the present conversation, and how the call center representative speaking to the customer behaves. Then, the LLM would output a highly effective script, focused on resolving the customer’s problem, and feed it to the call center representative, who can implement it with a more human touch. The platform would be able to do this at a lower cost than the cost we would incur by hiring several scriptwriters, which would potentially solve our affordability problem.
But to achieve this vision of an AI-powered, knock-out call center, we would still incur costs in terms of effort and capital: How would we get access to such a platform? Would we build it by hiring data scientists? Would we buy it from a technology vendor? Would our employees need training to trust the platform and adopt it? These costs can add up.
Moreover, how would we integrate its outputs into our call center process? Would it be entirely systematized, producing outputs that the call center representative simply reads from a computer screen? Do we need a new application framework to transcribe and process the conversation in real time? Should it interface with a customer relationship management (CRM) system that contains information about the customer calling and is retrieved using their caller ID? These business process questions must be answered, too, including what startup and ongoing costs they would add to the process.
Let’s say we go through the exercise of implementing such a system. As expected, customer complaints are now globally resolved at a greater rate than they were before. The important question becomes: does resolving customer complaints increase the amount of revenue coming in from those customers? And, if so, is that increase sufficiently large to justify the investment when combined with the costs of the process change in an ROI calculation?
If it doesn’t, even though the new process and technology were able to improve the quality of our service, the exercise did not result in an ROI that would make it “worth it.” Indeed, there is some research to suggest that companies are more profitable when they provide poor customer service via their call centers and interactive voice response (IVR) systems because the customers who are most expensive to satisfy end up leaving anyway, and the customers that have issues that are trivial but require lots of time to resolve do not have the anger or patience to make it through the arduous “hassle costs” required to actually resolve the problem (these hassle costs actually protect the company from having to take action, like refunding an order).
When these costs get too high, even a great insight can look rather deflated, because it can become clear that the cost of implementing it exceeds the value it is anticipated to generate, and hence, the value the company can capture back through the pricing of its services and products. This is the tension of operational enablement. Whatever we do in business, and whatever value we create for our customers, we must ultimately be remunerated for providing that value, such that we are able to deliver it at a lower cost than the remuneration received. We can sell incredibly valuable products at high prices, but if we don’t have a way of delivering those high value products at a lower cost than what we bring in, we won’t be in business for very long. With the right framework for thinking about data-driven operational enablement, we can deal with the problems associated with the implementation of our ideas more confidently, knowing that there really is a way to deliver the value we’ve discovered … without breaking the bank.
