Chatbot is the feature we’re truly proud of. What is a bot? It’s software that helps our customers qualify users on their websites, collect leads, and sell more with the same traffic.
We began developing Dashly chatbot 1.5 years ago. Today we want to tell the story behind Leadbot and share our experience. This is what we’ll talk about in this post:
On the article cover, you can see the team who worked on the chatbot:
Businesses need to talk to customers to help them and prevent churn. However, support agents are not superheroes: their time is expensive, they only respond during working hours, and they have limited capacity and speed. That’s where customer service chatbot comes in handy.
The chatbot is already helping us grow faster as it sorts incoming leads by campaigns. Within campaigns, we differentiate communications so our sales reps work to target leads, close more deals, and generate bigger revenues.
Thank you! The playbook is already in your inbox
Our users often asked for a website chatbot. We analyzed all requests and found out possible use cases and value to customers, and then concluded that a chatbot facilitates customer communication:
Our main goal is to help digital businesses improve customer communication which means growing the customer base without scaling sales and support teams. You can only do it if you automate tasks and optimize the workforce. That’s why chatbot platforms are getting so popular, they help resolve the automation issue.
We started developing Leadbot before the pandemic. With time, we got more and more requests from our users. The eCommerce industry transformed:
Starting fresh isn’t easy, that’s why we teamed up for a design sprint.
Design sprints are quick, they usually take a week. We only needed to build the overall logic of the chatbot, so we reduced our design sprint to just two days.
These are the guys who developed the first prototypes:
At stage one, we discussed the most essential things:
Our major task was to ensure Leadbot meets these requirements:
— it can appear timely when needed;
— it’s compatible with our live chat;
— you can run and adjust it;
— you can edit threads and conversation stages.
In addition, the software shouldn’t be too complicated to use. We wanted people to understand how to create a chatbot intuitively and with no coding skills.
We researched our rivals and user requests, learned more about chatbot best practices, and then decided we would build a chatbot that collects leads.
After a discussion of the research outcomes, each team member sketched their option of a prototype.
At this stage, we considered the logic under the hood of a chatbot. We decided to prototype on paper to create and show them faster. Besides, this stage was offline as the team didn’t go remote at that moment.
We ended up with a bunch of tree-like chatbots with various visualizations. All prototypes looked alike except for one thing: CEO Dimitrii drew a mind map system that was too complex for an MVP (minimum viable product), that’s why we settled upon the tree-like structure.
After running ideas, we assigned to our developers the first option of a prototype:
We initially planned to finish Leadbot in one sprint. To accelerate the development, we decided to make maximum use of the code we already had.
For example, we based the chatbot on the existing framework of auto messages. The bottleneck was that the chatbot’s functionality was wider than that of auto messages. It also had to allocate conversation between channels and agents.
Eventually, our “auto messages” framework was running the new code responsible for showing Leadbot, processing incoming messages, and building threads.
During the development and QA, we revealed some tasks that we couldn’t complete in one sprint.
Executing asynchronous code didn’t come cheap to the team.
A chatbot means several messages triggered by one event, and they should be sent sequentially so that the logic isn’t interrupted. Before the chatbot, each message was triggered by a particular event, so there was no need to send them in a sequence.
We found an issue in executing asynchronous code. A user could see several notifications (messages appearing when the chat is closed) in the wrong order.
Then, we added the message sequence check to ensure the right order and the chatbot’s logic.
Another feature of notifications that ruined the chatbot’s logic was the moment of reading a message. In auto messages, showing notifications meant the message was read. That was an issue as users stopped seeing the chatbot if they got a welcome message. Though they didn’t interact with the chatbot, the system thought the opposite and no longer showed messages.
Though we could complete some tasks faster, we deliberately invested more time. Considering the architecture and developing the chatbot’s backend went a little beyond the design sprint and took a few weeks.
We decided not to bind the architecture to the tree-like structure; in the backend, there are chatbot actions linking to certain threads, the list of threads, and the list of links to them. They’re not related to each other and can run in any order. All threads and possible actions simply exist like lists, and there’s a list of links to them.
Thank you! Your playbook is already in your inbox
We learned from our beta test participants about the things we should improve. Before we started to develop Leadbot, the platform couldn’t save the intermediate phase of auto messages. You need to fill out all required fields and create an auto message to save it. You can run it immediately or save it for later. An auto message is validated: the system checks if all properties are specified correctly.
Building a chatbot is a more complicated task than running auto messages, so we had to save partially created chatbots.
We derived two stages in the chatbot creation process: saving the structure and running validated messages. This way, we could ensure that users wouldn’t lose progress and could save it. A user can save the structure and the content, and the system will check it before the launch.
This task appeared at the beginning of developing Leadbot, and we implemented the minimum required functionality:
Early birds complained that their users couldn’t text the live chat, because the input field only appeared after the conversation was finished.
We enabled users to include the interruption thread: a user can send a message to the bot at any time, interrupt their conversation, and start talking to a human agent.
We initially implied an opportunity to interrupt the bot. This was a precaution in case a user managed to text the bot. Users wanted to see the field during their conversation, so we gave them this opportunity.
The bot’s user pic and name make up its identity. We started to develop it together with our regular agents’ userpics. They should be styled the same though still look different, so users wouldn’t mistake Leadbot for a human agent and vice versa.
The user experience viewpoint suggests that the chatbot should look appealing so users want to talk to it.
Our design team made a set of userpics for Leadbot expressing various emotions. We use one of them by default. In the final version, the bot looks friendly with its mouth open. It looks like it’s talking as its userpic is always next to a message.
During the first iteration, Leadbot’s user pic looked like a standard system icon with a robot:
Then, we made it friendlier:
Finally, Leadbot’s userpic looks like this:
Leadbot’s userpic turned out to be popular within the company.
“It looked like we didn’t want to change our code”: how we did the QA and redesigned Leadbot
Leadbot version one with the tree-like structure was developed quickly, but its functionality was limited. We launched the free Leadbot beta test to see if it fits users’ needs. During four months, 232 customers tested Leadbot on their websites.
We found out from user feedback that users experience difficulties creating complex structures due to linear threads in Leadbot. They had to copy threads, and they couldn’t take a conversation back to previous messages.
We had many similar cases, and “Polly’s bot” where we had to create 161 threads was the most catchy. Polly, our manager, ran a qualification bot on the customer’s website and she discovered that she had to create a separate conversation for each new thread.
The team started to explore possible solutions to this issue within the linear bot’s structure, but the Leadbot builder wasn’t getting better visually.
We solved it by giving up the linear structure in favor of the visual Leadbot builder.
We considered three possible solutions: SVG, HTML, and Canvas. Our major criteria were:
We tested all prototypes using hallway tests in several iterations:
After some fine-tuning, that version became the new visual builder. Now users can configure and edit Leadbot campaigns, and it’s much easier. What users can do now in the builder:
Though Leadbot version one didn’t come cheap to the team, we rearranged our processes and learned to set more realistic deadlines.
We also reconsidered our standups and took a different approach to bug fixing.
What Dashly’s Leadbot can do now:
— collect and qualify leads even at night when sales reps are sleeping;
— close repetitive requests before users send them;
— offer goods tailored for a particular user.
We are working on the bot that replies to a message sent to live chat. We keep an eye on chatbot future trends, so our product meets the expectation of the users. Subscribe to our updates and be the first to beta test it!
The industry is moving towards automation that proves the demand for chatbots: for higher performance, businesses need to engage customers better at a lower cost. Chatbots reduce costs for businesses, facilitate the routine of different teams, and improve customer loyalty with precise and quick replies. It’s a win-win-win scenario!