Chatbots at Swiggy

At Swiggy, chat remains one of the primary contact mediums for customers to reach out to us. In fact, about 70% of our customers prefer to communicate via chat as opposed to calls, as it is the most non-obstructive way of getting help.

Back in 2018, we were using a third party messaging software for chat, and it worked for us, for most parts. It helped our customers connect with the support executives. But, in a matter of months, Swiggy went from being operational in 9 cities to 200+ cities. This resulted in a 10x increase in the number of conversations created on a daily basis.

The third-party chat was starting to feel inadequate. To begin with, it was a black box for us. It was not easy to extract privacy-aware trends of queries, customer satisfaction scores, etc. We were looking for some concrete data streams that our internal data science and analytics tools could easily hook into, and thus drive business decisions to improve the customer’s overall experience.

For the customers, the chat experience was not at par with Swiggy’s highly recognized UX. We wanted greater control over the UX around being able to build interactive messaging components and monitor customer interactions with each of these components.

The support executives were also not very thrilled with the increased traffic. They were solving similar repetitive complaints every time — be it order cancellation or updating the customers about their order status.

That’s when we started pondering — What if we could automate some fragments of this? What if, we build a chatbot that can help the customer independently, without requiring assistance from a support executive?

Just to set some context, chatbots are computer programs that can automatically simulate interactions with customers based on a set of predefined conditions or events. They, however, are not meant to replace customer support executives, but rather provide a first step in the conversion process. Most times, chatbots will be able to resolve customer queries, adding a level of transparency to the conversation and a buffer for the support executives. But if the customer prefers to talk to a human support executive, we would not prevent that.

We evaluated many systems in the market, but there was no turnkey one-stop solution that met our requirements and user experience standards. Finally, we decided to build an in-house chat platform, that would be robust, scalable, extensible and will provide a unified seamless experience to our customers and support executives alike.

When we started to think about post-order customer experience, we realized that traditional ticketing based CRM systems won’t work for us. If we are to deliver a great customer experience for our hyperlocal business, it has to be a real-time conversational interface. But at the same time, it wouldn’t be possible for us to scale our Contact Center to keep pace with the scale of our business. This required us to think about automation, right from Day 0.

Designing a chatbot flow

We started off with a controlled flow within our conversations. This meant that customers wouldn’t be required to type in any text, but are provided with options to choose from and proceed to the next step. This is actually a ‘decision tree’ that is running at the back-end. A decision tree is a tree-like data structure, where each node will have child nodes, which are associated with conditional control statements — also known as child node validity rules. At each step of the chatbot flow, we show the customer a list of valid child nodes as the options to proceed further.

Consider something like this.

The best use case for chatbot automation was order cancellation. From the thousands of conversations created by customers who wanted to cancel their ongoing orders, we gathered the common reasons for cancellations and created a simple chatbot flow:

• Ask the customer about the reason for cancellation.
• Show the predicted time for delivery as a deterrence.
• Show the cancellation fee, if applicable.
• Ask the customer for confirmation on the cancellation.
• Show details about refund using a rich visualization.

The whole task has now become a self-serve for the customer, and can be done in 10 seconds. To put that into perspective, the earlier cancellation process took about 5 minutes and multiple phone calls.

Experience wise, this was a much more evolved approach. The customer is always just one step away from human help. The transition between chatbot and agent flow within the same conversation was effortless and seamless.

Conversation as a Service

From earlier on, we knew the core components that need to be built for this.

• The Webview — the customer interface for the chat that is used by Swiggy mobile and web apps.
• The Orchestrator - a controller for conversation routing between customers, chatbot, and support executives.
• Agent Workbench — the support executives’ interface for resolving customer queries, defining assignment logic and rules.
• The Bot — a decision tree parser that connects with multiple systems within Swiggy to validate nodes.
• Notification systems.

All of these are highly reliable micro-services. All components of the chat-platform are in an insourcing model. Any other team within Swiggy can on board their conversation workflows with very little effort. Beyond the regular food orders, the Swiggy Daily and Swiggy Stores also use the chat platform.

Fraud Detection

While the newly introduced chatbots made life easier for customers, we also saw increased fraud activities in the system. This can range from some customers cancelling dozens of orders per day, to claiming 100% refunds for all the orders. Some guard rails had to be put in place to prevent misuse of the system.

Swiggy, being an AI first company, created a Fraud Model - a machine learning model that takes several signals as input to define the fraud segment of all customers. This was integrated into the chatbot, to take more informed and personalized decisions. The results are very promising.

Scale and Criticality

Chat has grown to be one of the critical subsystems in the overall ordering experience within Swiggy. We have seen the chat platform handle incredibly large volumes of queries without any disruption or degradation of services.

At the same time, the chat-platform has dependencies across multiple systems — within swiggy and outside Swiggy. This meant we had to account for the non-ideal scenarios when things go haywire.

In operations parlance, this is called Business Continuity Plan a.k.a, BCP. We have built 2 levels of BCP scenarios within the chat platform, that helps us continue to serve the customers even when the system is under duress.

• Self Serve Bot flow: Any issues with the messaging module will cause a degraded experience with sending and receiving messages. During such times, we fall back to a request-response model within the chatbot flow. The customers will still get the same great experience, and the bot will be able to resolve most of the concerns.
• Third party agent chat — this is when the chat platform itself is down, and is more of a backup. The chances of this happening are extremely rare.

Business Impact and roll-outs

One of the key metrics that we track religiously is the bot efficacy percentage. This compares the percentage of conversations resolved by the bot vs the support executives. With various ongoing optimizations, more than 75% of the conversations will be positively resolved by the chatbot in the coming weeks.

The improved customer experience and overall impact of chatbots encouraged us to onboard more workflows. Swiggy’s order experience is very transparent, thanks to its live-tracking. In addition to that, the chatbot was able to reduce anxiety and give assurances to customers who reached out to us to check about their orders’ status.

We have also automated the following customer queries.

• Reporting issues with a delivered order.
• Adding delivery instructions.
• See details about refund status or failed transactions.
• Selecting alternatives when any of the items are out of stock.

All of these have significantly empowered the customers to take swift actions on their orders, while requiring very less manual intervention from our support executives. This also helped support executives to focus on more critical tickets.

What’s next?

We have started investing in natural language processing (NLP), sentiment analysis, smart replies, and multi-language support. These platform capabilities will take the chatbot to the next level. The on-boarding the support systems for our delivery executives and restaurant partners onto the chat platform is also in progress. We wanted to provide the same great experience for everyone, while providing data isolation and multi-tenancy.

Originally posted on Swiggy's Engineering Blog - Swiggy Bytes