Transforming the way customer disputes are resolved at Careem
How the Care Engineering team revolutionised the way customer disputes are resolved. This is just the beginning of our journey to simplify the lives of our customers, captains and colleagues.
At Careem, our Care agents resolve thousands of interactions everyday. These interactions involve over 100+ different contact reasons. A customer (here customer refers to a user — a captain, customer or a merchant) can contact us pre, post or in ride and naturally, each of these contact reasons has a different resolution. The wide variety of contact reasons are both different in terms of the investigation as well as the actions taken to resolve the contact.
When I joined Careem, back in 2018, I visited one of our call centres to understand how our care agents resolve a contact. That visit made me realise the number of manual steps that were being done were very high. Some agents had calculators open on their desktops to recalculate the ride fare. New agents had to go through documents to understand how to resolve an issue which they were solving for the first time. Only the highly experienced Care agents were made to receive calls from customers as they had the investigation and resolution steps fully memorised. To escalate an issue to the supply team they had to write an email or create a Jira ticket. At this point, you might be wondering if the handling time was skyrocketing? Well yes, it was.
Being a Care agent is a hard job especially when the other person is reaching when they are most unhappy with a service or situation. They have to make sure the customer is happy by the end of the interaction. They have to make sure that customer satisfaction (CSAT) remains high, handling time remains low and incase of payment adjustments they are just giving the right amount to the customer — enough to keep both customer and Careem happy. By mid-2018, we made a goal to simplify the lives of our Care agents and provide fast and consistent resolution to our customers.
It was not that we didn’t have a portal, we did. That portal allowed them to see customer details, trip details and even to perform payment adjustments on customer accounts. The problem was that it was a generic web-app with all the information that the agent might need. But the steps required to resolve a contact were embedded into the brains of our agents. We wanted to embed those steps into an app which would guide them towards a resolution. We wanted to create a resolution engine.
And so we started our journey to simplify the lives of our agents. We wanted to come up with an MVP and launch it as soon as possible. More importantly we wanted to gather feedback of our agents if the product really helped them and then iterate on it.
We experimented with the Lean Startup methodology. And we wanted to think of the fastest way to empower our agents. The goal was to simplify Care agents life by guiding them on every step.
Lean Product Management
Our team came up with the idea of using Google Forms in an iframe inside our web app. When I first heard of the idea, it sounded bizarre. As a junior software engineer out of university, I was new to the idea of Lean Product Management. I wanted to deliver complete features and as quickly as possible. And so I questioned why are we using Google Forms when we can create flows and forms inside our web app. My PM calmed me down and assured me that we will definitely iterate over it and improve.
Google Forms helped us in policy adherence as well. It ensured that every agent was following the same steps to resolve the same problem and that there was no personal sentiment involved. We gradually started rolling it out. Not only our Care agents were satisfied but our quality & other metrics started to improve. QA agents found a way (via Google Form responses) to validate the steps taken by the Care agents and ensure that the resolution provided was correct and followed Careem expectations. In about three months, we launched 20+ category flows on Google Forms. It was not only Google Forms, we started displaying the relevant trip and customer related relevant information beside it as well.
Google Forms had its limitations
The data filled by our agents was not easily accessible. Trivial questions like trip related information and basic customer information had to be filled manually. Policies change based on cities, car types, customer segmentation, customer LTV and so on. These are all things which our ecosystem (100’s of microservices) already know and so there was no point in asking an agent to fill this trivial information to reach a resolution. There was limited automation possible inside Google Forms. We could auto populate the form sections but we couldn’t skip those forms. And so we decided to move away from Google Forms.
The first iteration allowed us to understand the problem context further. We wanted to create something not only for our agents but also for our business operations team as well. We wanted to give them the ability to change resolution policies on the fly with little to no tech involvement. That sounded really hard to do when we thought about it at first. Embedding business policies in code is easy, if they seldom change. In our case, policies changed very often (1–2 changes every week in one flow). If you consider encoding 20+ different flows then it sure seems like a lot of work to do. Below is an example of how does a contact resolution policy looks like:
It’s a flow chart. One way to embed this policy is by using conditional statements in code. But this was not a viable option as we wanted to minimise tech involvement. Another more dynamic way to implement this is by encoding this policy on a BPM engine. We researched on the available open source BPM’s available. After careful consideration we chose Flowable due to its community support. This time it was an experiment for our tech ops team. We wanted to know if Flowable was the right tool for them and that they were comfortable enough to create and modify business policies in it?
Migrating away from Google Forms
It was challenging at first. Coming from a stable solution like Google Forms to an open source tool seemed like a tough decision, but we took a leap of faith. As a POC we migrated one of our google forms to flowable app. We utilised API’s exposed by flowable SDK’s and built a service on top of it. We then migrated 2–3 more flows. Everything worked fine in the beginning. We were doing about 50k+ transactions on Flowable everyday. As data grew in Flowable database the API’s started getting slower. We suffered a few hiccups on the way. In order to truly reap the benefits of an opensource tool you need to dig deeper and understand its internal working as well. It turned out that there were missing indexes on the database side. We raised it with the Flowable team and got them added in their source code.
Currently we have around 20+ resolution flows on Flowable and we are scaling it as I write this. Now our goal is to introduce automated machine tasks in the BPM process to reduce the average handling time of each resolution and remove those trivial questions that I outlined above.
Reflection
As I look back on the past two-year journey, I realise that we have travelled so far. Not only in-terms of making our agents lives easier but also evolving as a true agile team.
When we started this journey, we had a design sprint to decide on what we are going to build and we created wireframes, prototypes and what not about what out final web-app would look like. It looked great as a prototype, but the thought of implementing that prototype burdened us. Being introduced to lean startup methodology made our lives a lot easier. We have started experimenting a lot more. If we are not sure of something, we make that available to our Beta agents. To validate our hypothesis, we measure the impact using analytical tools like Google Analytics and finally, we iterate over it.
Learnings
- A feature can never be fully complete. There is always room for improvement. Its in the hands of the user to decide which improvement is more important than the other. So reduce the scope, launch soon, gather feedback and then iterate over it.
- To truly understand what your user wants, sit with them while they are working on the problem you want to solve. If possible, shadow and role play as a user as well. This way you understand the problem in users shoes.
- Tech debt keeps growing and growing. New features have some monetary benefits attached to them and so they will always have higher priority. The way we deal with tech debt is by incrementally reducing it with new features. When we have to implement a feature on a piece of code with huge tech debt, we first refactor the code and then implement the feature on it. Incremental refactoring is always helpful and keeps the code clean over the long run.
- Open source tools give you a huge boost and enable you to launch quickly and experiment if the intended functionality is beneficial to the users or not.
- Writing tests increased our confidence on the code we wrote. If we didn’t have enough time, we reduced the scope of the feature but ensured that we wrote quality code.
