A couple of weeks ago Rahul joined Yoda, an early-stage D2C startup.
The first time he met with Nikhil, the CEO, he asked if there were any critical tasks he could begin working on. Nikhil thought about it for a couple of seconds and told him there are a lot of customer escalations regarding order delivery. Customers complain mainly about poor order status communication. Nikhil encouraged him to look at the problem and propose a solution.
Rahul reviewed/listened to customer complaints and studied existing customer communication related to orders for a couple of days. Then he summarised the current flow and the issues that need to be addressed.
- Yoda is built on Shopify. The tech team has configured the default order confirmation template available in Shopify. So currently, the order confirmation email is triggered by Shopify post successful order.
- To deliver orders, Yoda partners with Clickpost, a third-party logistics company. Order status communications, such as Shipped, In Transit, Out for Delivery, etc are handled by logistics partners such as Delhivery and Bluedart.
- Currently, Yoda's backend integrates these 3PL players' order status APIs. However, the order tracking flow in My Accounts hasn't been built yet, so customers can't track their orders there.
- These logistics partners send only SMS. If users miss seeing these SMS, they end up searching for emails or push notifications to see if they received any updates. When they couldn't find it, they sent stinkers to Yoda's customer service.
Rahul realised that the order status communication is a critical flow and it needs to be foolproof. The best option is to build the order tracking within the App/website, but it will take a couple of months to design, build, and release it.
To keep users updated on their orders, he decided to use multiple communication channels (Email, SMS, Push).
Rahul listed out the tasks that needed to be completed.
- Assess service providers, negotiate prices, and finalise the contract
- Provider integration.
- Release after testing.
As the CEO wanted the issues resolved as soon as possible, Rahul chose one service provider for all channels in order to expedite the release process.
Evaluating and finalising service providers
Rahul talked to colleagues who have done similar integrations in the past and shortlisted Gupshup, Kaleyra, and Karix for SMS. In addition to Google FCM for Push, he decided to trigger Emails directly from the backend using Amazon SES.
He evaluated SMS vendors based on service levels since SMS pricing is pretty standard across vendors. Based on his evaluation, he decided to go with Kaleyra.
Integration
Next, Rahul sat down with his engineering team and shared the API docs for Kaleyra as well as a PRD with templates for sending email, SMS and push notifications.
- For each status, the tech team must configure an email, SMS, and push template
- It is necessary to log the send status for each communication (so that future debugging can be conducted).
Timelines
A timeline of 2 months was given for all activities, including testing. The CEO isn't happy about the timelines, but he has little choice because integrating with multiple channel providers, testing, and logging each action is going to take time.
Feature Release
Three months after Rahul spoke with the CEO, the feature was released. Following its release, customer complaints started dropping, and NPS (Net Promoter Score) started increasing. The CEO praised Rahul for delivering such an impactful feature so quickly.
Then, things went downhill
It was fine for a few months. Rahul was casually conversing with one of the customer service executives one day, and the CS executive mentioned they were still receiving complaints from customers regarding order status updates from time to time. Rahul decided to investigate the issue more thoroughly. He got a list of customers who had complained and followed the steps below:
- Downloaded the sent logs (Email, SMS, Push) from the database.
- Downloaded those customers' delivered logs from Kaleyra.
His frustration grew as he realised he couldn't download individual customer logs from SES or FCM.
Rahul concluded that after analysing the data,
- A few SMS were not delivered from Kaleyra. He escalated the issue to Kaleyra, who mentioned that the SMS wasn't delivered for some reason and promised to investigate.
- He wasn't able to verify whether customers who didn't receive SMS received emails or push notifications due to the lack of individual user logs.
Having realised that he must solve these cases before the CEO asks for RCA, Rahul decided to do the following:
- Finalise SMS, email, and push failover options.
- Log the sent and delivered messages for each service provider in Yoda’s db.
Now, Rahul has to finalise new vendors, integrate them, and add logs for each channel for monitoring purposes. He was deflated when his engineering team told him it would take 3-4 months.
His next meeting with the CEO would require him to convey these timelines, and he was not looking forward to it.
Rahul wondered how he could avoid spending so much time dealing with new service providers or channels in the future (to reduce time and costs) and realised Nikhil would also ask the same question. Having thought of that, he started looking up keywords like "automating user communication", “communication infrastructure”, and “scaling communication service”, etc on Google and stumbled upon Fyno.
The moment Rahul visited Fyno's site and reviewed its documentation, he realised how much time it would save his engineering team. Taking that thought into consideration and thanking his lucky stars, he scheduled a demo with the Fyno team.
