100 Days to RASA Chatbot!
My 7th day in the organisation and I was told that we need to build an NLP driven Chatbot or what’s popularly called a Conversational A.I.
Alright, let’s go back a little!
I joined Cashify as an A.I. Product Manager in August 2020. While I was ambitiously looking forward to creating some really cutting-edge ML and Data Science based products for the organisation, I did not however actually anticipate that a RASA Chatbot will go to be the first on the list.
Coming out from my first Monday morning meeting in the organisation, I knew it’s going to be an exciting journey for me, building a Conversational A.I. I had recently completed my Post Graduation in Machine Learning and coincidentally my final industry project was also a RASA / LSTM based chatbot, out of which I had opted for both, but really enjoyed RASA particularly, TBH!
I will try to quickly take you through our 100 days spent in making the Conversational A.I. at Cashify, which we are now calling “CashBot”.
Day 01 to Day 05
Business Requirement Gathering
These first 5 days were the usual business requirement gathering and problem statement understanding days. However, something that I knew from the beginning was that the problem statement has to be understood right, else we will end up taking the wrong train, with the next station being quite distant, for us to get down and be able to get back where we started.
I will share a quick glance on the Business Requirement Gathering discussion that I had with my B.U. :-
— — — — — — — — Business Requirement Gathering — — — — — — — —
BU : We currently use a very basic conventional third party chatbot. Apparently, it’s not essentially even a chatbot, but rather a user selection-driven drill-down flow which will let the user make their choice from the options/use-cases available and then finally connect them to a support agent.
Me : So you mean the user does not have a choice but to connect with the support agent at the end? Isn’t this a little annoying and also mundane for the end user? I am sure we have some meaningful data at our end to actually provide to the user right there on the chat instance. Instant Solution is what I am suggesting. Some APIs are to be integrated and we are sorted. Isn’t it?
BU : Right! And now that you have already understood the gist of it, let me tell you that as of now, we have the following different types of customer queries that we receive, along with the share of each in the overall tickets, over a span of 10 days. Our new RASA Chatbot will have to take care of each of these, as we progress gradually :-
What can be seen from this pie chart is that our two most important use cases where we generally get a lot of customer queries are:-
1) Awaiting Pickup Specialist- This is where the customers who have placed their Sell/Repair Orders on Cashify, enquire about their Pickup Specialist/Service Technician arrival status on the day of service.
2) Service Ability- This is where the Cashify’s potential and existing consumers enquire about the Sell (Buyback)/Repair serviceability in their areas/location (pin-codes). Similarly, there are a few more use-cases, but we can implement them incrementally in upcoming phases.
Me : Understood! I should now align my APIs & Design requirements and then, we can get started.
— — — — — — — — Business Requirement Gathering — — — — — — — —
Now before I go further to take you through the remaining 95 days of Chatbot development, let me just give you a glance at what we were trying to produce through a Conversational A.I.
What you will see below is the overall user flows covered by the previously running third party chat widget on Cashify. We knew it’s a lot to build, but gladly, we had to release only the two most important use-cases in the first phase :-
You might have to zoom in a bit 😆
Day 05 to Day 10
Wireframes | Dialogue Flow / BluePrint Creation | API’s Sourcing
Wireframes: I always had a fair idea of how a typical fancy conversational bot should look like. And now I just had to draw some lines and fit the bot in those line frames. That’s where I produced the wireframes for our Phase-1 chatbot.
The following that you see are the initial wireframes shared with our Design team. There were obviously some updates and improvements later on. Nevertheless, these wireframes should give you a fair idea of where the final bot was inspired from.
I will now quickly describe our two use-cases for the Phase-1 of our RASA Chatbot and also present their respective dialogue flows:-
Awaiting Pickup Specialist: This is the use-case where Cashify’s customers reach out to our Support to enquire about their Pickup Specialists’ arrival status. This majorly happens when they have a Sell/Repair order and their assigned Pickup Specialists or Repair Technicians don’t reach their location on time on the scheduled date of visit. Some of the time, it also happens that the customers enquire about the Agent’s ETA a few days prior too, just to plan their service day well in advance.
Here, now when the customer comes to our Bot, we fetch all the Sell & Repair service numbers associated with the contact number the customer is logged-in with. The customer can either choose from the listed order IDs or can manually enter a Service Request No. (Order ID). Once the bot gets the Order ID from the customer, there’s a sequence of API calls that follow which basically provide an approximate Agent ETA by querying Cashify’s Logistics Unit and taking into account the Pickup Specialist’s current lat-long coordinates, their last served customer and their shift-start time.
Well, that’s not the entire recipe obviously!
Just giving you a decent idea of how we calculate that time. The actual holistic approach is quite verbose and complex.
The customer can now acknowledge the information given to them and simply end the session, or can alternatively also speak to our Support Agent on a Live chat or also ask for a call back. Let’s look at a sample dialogue flow in this case:-
Service Ability: This is a little simpler use-case of the two, however, probably a more business-encouraging one. Here, a Cashify customer basically reaches out to us to enquire whether Cashify provides Buyback (Sell) or Repair service in their location.
In this case, the bot simply requires the customer’s pin-code in order to check the Buyback/Repair serviceability in their area. There are two ways that this is accomplished. One is where the user can manually enter their area pin-code and the other way is where they can also pick from their saved addresses.
Either way, the bot requires a pin-code to call the integrated API which basically requires a pin-code in the request and prompts a binary response (Yes or No) to the customer, which is whether Cashify provides that particular Sell/Repair service in that pin-code or not! However, the bot also provides a link to the customer, which the customer can click and land on the Cashify’s site and check the serviceability for their specific device variant.
This obviously also provides us some referral traffic on the platform. Some of them can be potential consumers too. 😉
And now to not to make it a long read for y’all, I thought of continuing with the remaining 90 days of Chatbot development on a different article.
Click here to go to that article.
We will mostly cover the Tech part of the Chatbot development there.
If you anyway wanted to fast forward to the RASA concepts, namely intents, stories, domain, actions, etc. implemented in the chatbot development, then let’s see you on the other side.
