It is impossible to find a perfect way to predict every complaint from a customer. Even if a service or product is excellent, many parts of the customer's experience can go wrong. This leads to different ways of complaining, from a phone call, a letter, a visit, or even a legal complaint. No matter the method, complaints, when looked at through data, are like a gold mine. They offer useful information to help a company stay competitive and learn from its mistakes.

In the early 2010s, I joined a telecommunications company in Peru as a data analyst. My role gave me access to their complaint database, and my main task was to identify solutions to customer complaints on a large scale by working with all departments across the company. Sometimes, we felt overwhelmed by the wide variety of complaints from customers. However, there was a common reason that led to most complaints: a broken promise. In this context, a promise is an expectation set for the customer, such as a special discount price for a certain period, or a service package with specific features. However, one of the main reasons for complaints was the invoice.

Imagine you bought an internet, pay TV, or telephone service. You were promised it would cost 29 dollars for the first three months, then go up to 49 dollars. But when your first invoice arrived, the price was already 49 dollars. Your immediate thought would be that you had lost the discount, as it simply was not applied, and your first reaction would be to complain. You call the company, tell your story, and then the company gives discounts on future invoices to make up for the missing initial discount. This situation, at first glance, seems resolved. However, we learned from our data that a high number of these customers then asked to end their service. This was very bad for the business. Since the company put the customer at the centre of its strategy, this became a very important issue and was discussed in many follow up meetings.

Finding the Root Cause of Complaints

I was lucky to be involved at the start of this research, when the team had not yet created any specific way to control invoices as the main cause of complaints. This allowed for more creative solutions and many brainstorming sessions to decide on a path forward. The system that handled reports from the complaint team, who dealt with customers, included different categories of complaints. These included: "Non promised offer," "charges belong to other services not contracted by customer," and "client was ended but still getting invoice," among others. Most of the data showed that the "Non promised offer" category was the most critical one. Fixing this could reduce complaints by about 20%. As mentioned, this type of complaint happened when an initial discount was offered to new customers, but then this discount was not actually applied, leading to a complaint.

I remember being in many meetings with the Product department, the Invoice department, and the Complaint department to understand their views on this problem. It was clear that each department had different goals. For instance, the Product department focused on getting more new customers and launching products that met all internal quality standards for new telecommunication products. The Invoice department's goal was to meet legal requirements and monitor invoice payments. The Complaint department's aim was to handle complaints and resolve them within specific legal timeframes. It was clear that there was no shared goal to reduce complaints caused by mistakes in giving discounts to new customers with initial offers. However, as reducing these complaints was a key objective for my team, we began by truly understanding the situation and the motivations of the main departments involved.

A second step was to look at the data to try and understand where the complaints came from. We found that the transactional system, which was part of the company’s ERP (Enterprise Resource Planning, a system that manages a company’s business processes), made it very difficult to apply discounts. Also, there were no warnings during the customer registration process. This can be explained by the fact that the product registration system was created in a simpler time when products had a single price. However, competition in the market made the company add special offers for new customers, like initial discounts for a set period. Because of this, the developers who changed the registration parts within the ERP added new options that were not easy for the sales teams to follow. This led to mistakes, and was a very hard problem to solve, because even with training for sales representatives, there were occasional errors that led to future invoice complaints. For this reason, my team decided that the problem would be solved not at the very beginning of the process, but at the next management layer. Extracting sales data from the ERP and comparing it with complaint data could give us more insights about which products were causing customer complaints. But there was one missing piece of information.

Filling the Gaps with Data

This missing piece was the company’s product catalogue. As you might imagine, the ERP registration system did not have an online catalogue with product information. Entering product catalogue details into the ERP registration system involved many manual steps. It was easier to share product information using an spreadsheet printed at sales points rather than putting it directly into the system for proper registration. As mentioned, this was because the system was created before product catalogues became more complex, and it was not practical to add the new catalogue rules to the ERP’s registration module.

Initially, we asked product teams to share the monthly product catalogues and any updates in spreadsheets. This information was then processed by my team to get a clean list of products sold during the month, their initial price, the later price, and the discount period. This was then matched by product code with the list of products that customers had complained about. This three way data matching gave us a complete view of the complaint. At the beginning, I wrote a Visual Basic (VB) program to automatically extract these three pieces of information every day and combine them into one system. This system could be searched by complaint or by customer. We shared this tool with the complaint team who dealt with customers. It helped them quickly understand any invoice difference and led to a manual fix of the invoice.

Proactive Solutions and Positive Outcomes

Then, we started thinking: what if we could automatically find customer complaints where a catalogue offer was not put into the product registration? This way, we could list these cases and share the fixes with the invoice department to add these discount items as corrections. This would be a proactive way to avoid complaints. Indeed, this idea was first tested and then became the new standard for automatically preventing complaints. Finally, we added the information about automatic invoice fixes to the VB tool we shared with the complaint representatives. This helped them calm the customer or, if the automatic process did not work, they could use a form to create a specific fix from a list. The result was amazing. The number of complaints actually decreased by about 20%. This was not only because of the automatic fixes but also because the complaint representatives felt more capable with the new tools. Most complaints were solved quickly because an automatic fix was planned for the next invoice period, and this was shown in the tool. Later, this tool became part of the company’s intranet websites, which led to a big change in customer experience. I received an award for this work, in representation of the team, and shortly before moving to Europe to pursue an MBA (Master of Business Administration) in the mid 2010s.

Looking back carefully some years after this experience, I can now see that this fix should have been made at the roots, right at the very beginning of the system. However, sometimes, because it is too complex or too expensive to fix a registration part inside an ERP, solutions are instead put in place as a later management process. This definitely increases the risk of problems. Luckily, if data is available, it allows for fixes like this case, and leads to a better understanding of a business problem. This problem can then be solved using the company's own resources. Moreover, this showed that the company needed to be more advanced in how it used data. I wish I could have seen the company’s digital transformation after I left, but I am happy to reflect on this experience. It is part of my professional solutions that can be used in any situation where a promise must be kept, with the help of data.

Joe Esteves