We All Need to Develop Chatbots to Move The Technology: The Story of Dashly Leadbot
Leadbot is the feature we’re truly proud of. It’s a chatbot that helps our customers qualify users on their websites, collect leads, and sell more with the same traffic.
We began developing it 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:
- why the first version took the whole year and how we managed to finish the second version in just three sprints;
- how the team learns to set realistic deadlines;
- what tasks you can skip and what can’t, and what ugly sheets got to do with it;
- how bugs should be handled when releasing a huge feature;
- what’s important in the chatbot identity;
- and what place hallway tests take in the development cycle.
On the article cover, you can see the team who worked on Leadbot:
- Dima, Head of Product
- Alex, Frontend Developer
- Olga, Backend Developer
- Sergey, CTO
- Dmitry, CEO
- Helene, PMM
- Victor, Frontend Developer
- Eugene, Product designer
Chatbots accelerate customer communication
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.
Leadbot’s already helping us grow faster as it sorts incoming leads by campaigns. Within campaigns, we differentiate communications so our sales reps work on target leads, close more deals, and generate bigger revenues.
Thank you! The playbook is already in your inbox
Leadbot is the hottest thing demanded by our users
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:
- customers prefer clicking buttons in case of typical questions as it ensures a quicker response;
- companies can collect customer data and adjust their communications.
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.
We started developing Leadbot before the pandemic. With time, we got more and more requests from our users. The eCommerce industry transformed:
- people buy online with more time to compare options, they choose more carefully considering limited resources;
- businesses acquire larger traffic and engage in more conversations risking wasting money talking to non-target leads.
How we did a prototype in two days
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:
- Dmitry, CEO
- Dima, Head of Product
- Sergey, CTO
- Eugene, Product Designer
- Alex, Frontend Developer
Prototyping stage one: team catch-up, task setting
At stage one, we discussed the most essential things:
- what the main Leadbot’s “job” was;
- which campaigns should be engaged;
- what competitor options there are,
- and what the minimum required functionality was required for Leadbot.
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.
We researched our rivals and user requests, and we 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.
Prototyping stage two: each team member designs their MVP
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 Dmitry. 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.
Prototyping stage three: finishing the prototype and assigning it to developers
After running ideas, we assigned to our developers the first option of a prototype:
- with buttons,
- text messages,
- with threads as the main elements,
- with the tree-like structure,
- without cycles.
“We thought it would only take one sprint, and it went on for four sprints in a row”: how we worked on Leadbot’s version one
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.
“Buttons jumped somewhere to the middle”: executing asynchronous code
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.
“Be ready to burn it”: building the architecture
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
“When you’re working on something big, you don’t want to waste it”: saving the intermediate phases of Leadbot
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.
“When my customer’s platform is down, they don’t want to talk to the chatbot”: the interruption thread
This task appeared at the beginning of developing Leadbot, and we implemented the minimum required functionality:
- threads with buttons for Leadbot to qualify users;
- the input field for lead collection.
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 should be friendly”: the identity
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:
- performance (we couldn’t slow the platform down);
- a large and active community of the open-source project;
- Angular compatibility (that’s what our admin panel is working on).
We tested all prototypes using hallway tests in several iterations:
- how well users understand the structure of the interface;
- which terms are better understood (journey, step, thread, etc),
- whether users notice the preview and see that they can interact with it.
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:
- see all messages from Leadbot and their options in one screen;
- relate threads to each other and loop conversations;
- create and launch more complex campaigns.
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’s next? Developing and improving more chatbots
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. 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!