“The return policy has changed again, can you update the code?”
“Could you add an exception for our VIP customers?”
My cofounder kept hearing those questions over and over again when he was leading the automation customer support team @Uber, leading to a nightmare of maintenance.
Below, I’ll be sharing our key learnings.

TL;DR
Build a strong Tech structure for your customer service automation project.
Your engineers will thank you, your customer support team will thank you and your customers will thank you.
However, it is much harder than you think.

Why is it a nightmare?

You could be tempted to launch a quick in-house project to automate your main customer service flows, however you’ll quickly discover that it is a nightmare to maintain.

My cofounder has learnt it the hard way at Uber where they ended up scaling to a big team of 10 to fully complete the challenge.

You get overwhelmed by requests to change procedure resolution logics


This is too much

The way we support customers fluctuates a lot during the lifetime of a company, and can evolve based on:

  • A new release of the product
  • An improvement of how we support customers by using segmentation (e.g special conditions for VIP customers)
  • A change in the refund policy
  • The launch of a new city
  • etc…
Each time, a feature request would be made by the customer support teams and developers keep being distracted from doing their core job:
Improving the product!

You get overwhelmed by requests to change your product front end

Also, some procedures will need additional inputs from customers.
For instance, if the customer is complaining about a missing item in his order, this information needs to be retrieved so that the issue can be automatically resolved.

Consequently, a technical team would be asked to modify the front layout.

And, here is another team that gets involved in the process and distracted from another priority.

This is too much

You will need to add multiple data sources

Often you will face situations where you would need to integrate to new data sources (e.g in order to get the customer order history).
For that, you would need to connect to the order history database and ask the team responsible of the service to provide you with the right information.

These different tasks keep being accumulated in the team backlog while customer support teams are having a hard time keeping customers happy.

Fraud

This is too much

When running automations, it is easier for malicious individuals to exploit loopholes in your system.
You therefore discover that you need to:

  • develop a fraud detection system to prevent fraud from happening
  • develop analytics to understand where fraud comes from and act accordingly

Testing

Final thoughts on testing, as the flows become more and more complex, the less it is possible to manually unit-test the different possibilities.
That will be a whole subject that you would need to crack 😉

If you think it's a good investment of your engineering time, go ahead and build it in-house, but make sure to go all the way (you could find here Doordash and Uber approaches).

Another option is to rely on customer support automation platforms, built by specialized teams.

To solve this challenge, at Teker we are building the next generation customer support automation tool that can be setup in minutes by the tech team and then autonomously used by the business team.

If you are interested, register here to be part of our beta :