Service Guarantees, the MMT Story: MMT Promise

This is part 3 of my series on Service Guarantees.

Part 1 talked about the concept.

Part 2 starts the MMT journey with guarantees, covers the first baby steps we took, including instant refunds.

We were now processing most of the refunds instantly. But we didn’t have the guarantee ready yet: what would happen if the refund was not processed instantly?

MMT Guarantee 3: MMTPromise

As we thought about this, we asked ourselves – why only for refunds, why not for all of customer support? That would also raise the marketing power of our guarantee significantly.

Quality of MMT’s support, already among the best, had dramatically improved during the year 2016.

We wanted the world to know this. We wanted to make a statement.

Why? Well, perception of great support would help the brand anyway. But it was specially important for the online hotels business– trust in support would get people to try out online bookings more easily.

These thoughts led us to MMT Promise: a customer support guarantee.

Now this was one scarier.

Ticket bookings and refunds were mostly large scale automated systems, with simple, well defined outcomes, even if the process was complex. But customer support overall did not have well defined outcomes: they were often subjective. And the nature of support issues would change with changing business and market dynamics. Support processes were always trying to catch-up with new types of upstream issues. Finally, support involved significant human involvement leading to potentially much higher error rates.

The Goal

The promise was this – when you raise a support issue with MMT’s customer support system, we instantly give you a promised time of resolution. If we don’t resolve your ticket by that time, every minute of delay earns you money.

We wanted no small print. The one line mentioned above had to be it. We didn’t want any exclusions – all support interactions had to be covered.

We also were clear that this promise needed to have high visibility. If you had an interaction with MMT’s support system, there was no way you could miss the promise.

And we wanted to delight the users by removing the need to invoke the guarantee – we would do it automatically, and we would do it openly.

This was huge.

Step 1: Define the promise

We had to start at the basics. In the beginning, we couldn’t even estimate the cost of the program. Quite a few of the support transactions were fully automated, but for some of them, we didn’t have the instrumentation in place to measure resolution times.

For the agent driven support tickets, we had only a few broad SLAs. (Service Level Agreements – in this case, the promised time to resolve a ticket). Most issues had a SLA of 24 hours, and the others being 3 days or 7 days. This wouldn't do. We needed more specific SLAs. When we sat down to define them, we realized that we had to redo pretty much everything about support.

Defining SLAs should be trivial.

Right?

Right?

Wrong!

It took us weeks to do this. The more we peeled, the more we needed to keep peeling. Layer by layer, it just kept growing at us. But this was fun. We were ripping things apart and creating an entirely new foundation and new style of thinking.

Why was it difficult?

Let’s see.

Differential SLAs: SLAs needed to be different for different types of issues. So we needed to review ALL issue types, go through all processes, and figure out how much time was required for each of them. This was a very large exercise – it required us to create detailed process maps for every type of issue.

As we started doing this, we quickly realized that SLAs needed to vary based on a number of additional factors related to the booking, not just by the type of issue. (e.g cancellation processes varied by airline, type of booking, etc.)

We also had to take care of different definitions of time. Different teams at MMT and at partner firms followed different business hours. The SLA definitions needed to take this into account.

Definition of Issue Types: The existing Issue Types had been defined for the convenience of the internal teams, not for the customer. They spoke a language that was inside-out, rather than outside-in.

Here’s an example: let’s say a customer called to complain that they had not yet received a refund. There used to be four different issue types for this call, depending on the internal processing status. But for the customer, these 4 issue types were simply one: I haven’t received my refund.

A promise to the customer needed to be based on the customer intent. We needed to completely redo our Issue Types based on customer voice. This was another large exercise and required quite a bit of unlearning for the support teams. It was a totally new way of thinking.

Inside-out v/s outside-in SLAs: So far, the thinking on SLAs was also inside-out. They were defined based on current processes. What customers would expect had no role to play. But we were now putting these SLAs out there in full public glare. They needed to sound reasonable to customers.

With that perspective, we reduced some SLAs significantly, and had to find ways to meet those SLAs - by re-engineering processes and developing new capabilities.

Step 2: Build the capability

A number of issues required multi-stage process flows, often involving other teams (revenue, finance, supply), and often involving partners such as airlines or hotels. All these flows, so far, had been executed over emails or phone calls. There was no structured information about them.

That simply wouldn’t do in this new world. Without structured information, the support team would be running blind. How would they know what ticket was getting delayed and needed intervention? If they waited till the SLA was breached, the delays could be very large, and it could create large losses. We were going to pay for every minute of delay, after all!

This meant that we had to build granular, stage-wise workflows for every issue type, and define internal SLAs for each stage. This forced us to look at each process stage with even higher rigour. And new tech capabilities had to be built.

Step 3: Build the customer visibility

To get the biggest impact, we wanted to be make the promise highly visibile. MMT’s mobile app home page had the concept of visual cards – the home page was basically just a set of different dynamic cards. We created a new card for the MMTPromise. If a customer had an open ticket, or a recently closed one, the MMTPromise card would be the first card on the home page. (This was highly lucrative real estate - so was not an easy choice. Credit to the revenue teams!)

The cards had a ticker on them, showing how much time had elapsed, and how much was left to the SLA breach. If the SLA had already been breached, the card would show the penalty already earned.

But not everyone used the MMT mobile app. We wanted to use other high visibility channels too. Luckily, we had access to Whatsapp through their early access business API program. Together, these two channels ensured that no consumer who interacted with support, would miss MMTPromise.

Our tech and product teams built a fantastic Promise Engine on top of existing operational systems. This engine was non-intrusive: it would only read information from these systems, never write to them. This engine maintained the current state of each ticket, and responded in real time to the hundreds of thousands of app opens every day.

Step 4: Launch

With pieces coming together, we launched the system in shadow mode- and it was a whole new world! We had known what we were building all along. But when we sat down to look at the first real dashboard, it blew our minds!

We could see the amount of money we would be paying out. This was scary. But this was exhilarating too! We now had a rupee cost of a bad support experience. The way we thought about support and prioritized support would change radically.

We started looking at total money spent. Money spent by business. Money spent by issue type. Average money spent per issue of different types. Issues where money paid out was more than Rs. 1000. And so on.

Teams started working on reducing the spend, and continued to work after we went live. Spends came down very rapidly. Even after going live, the first month itself saw spends come down 50%.

Customers loved this. NPS (Net Promoter Score) of customers who reached out to support, went up 10 points. And the operating metrics also improved rapidly.

As it turned out, they didn’t really care much about the money they were getting – getting the issue resolved timely was more important for them. But what they loved was the fact that we were willing to put our money where our mouth was – if we screwed up, it would hurt us. The money worked as proof we were trying our best. We gained trust. Our agents were no longer issuing meaningless apologies: our apologies came with hard cash.

While MMTPromise was a big step, it impacted only a small percentage of our customers - only those who needed support. The real challenge was the hotels experience, which was both the dominant reason for detraction in customers, and the single biggest barrier to trial for offline bookers.

This would lead to the big daddy of service guarantees: MMT Assured Hotels. This one was radical – we made guarantees on something that was not in our control!

But let's talk about that in Part 4.