Chatbot: guiding users through the B2B and B2C sectors

---

The chat used during the registration process on the Houpa! app was designed to facilitate access to the platform's B2B and B2C environments.

The chat structure was closed from the beginning; it did not use artificial intelligence and guided users through decision trees.

Some problems in the experience were observed in a brief analysis and by looking at the data stored on our server: 

• People took 10 to 15 minutes to complete the registration;
• The data was not entered qualitatively;
• Many scenarios led the user to get lost within the chat itself, such as: password recovery and resending of registration confirmation email.

From there, our how might we question arose: How can we design an experience that would encourage the user to register by entering as much qualitative information as possible?

4 UX/UI Designers

1 UX Writer

2 Developers

During the first design sprints, we structured the hierarchy of information entered by the user, prioritizing the most frequently filled-in data and comparing it with the data that was most important to us, all of this from a business perspective and thinking about leads — of course.

The hierarchy of data helped the team to create a better narrative for the flows that were created later.

We took advantage of this moment to work on a desk survey and benchmarking to help define what the format of this data would be — masks, characters, etc. — how the system would receive it and how this information would be requested from the user.

For two weeks, the UX team focused on redesigning the experience, by creating flows with a decision tree. Since all the data was formatted and the order in which it would be requested was defined, the biggest challenge at this point was to simplify the paths so that registration would happen quickly and not lead the user to get lost in scenarios that were not associated with our goal: registration.

Imagine that the user types in an email that has already been registered, and we send the message “Sorry, but this email has already been registered on the platform. Do you remember registering?” If they remember having registered, we would take them to the password recovery module. If they don't remember, we give them the option to contact our customer service in a more targeted way to resolve this problem, on the assumption that they probably forgot that they had registered or someone else had registered for them.

We realized the need to include these exits precisely after analyzing the possible scenarios that could happen within each stage of the chat. And after speaking with the Customer Experience team and realizing that these were common problems reported in customer service.

After scoping out the data and flows to better understand how they would be requested, we reformulated the entire chat narrative using more friendly and strategic language.

• Asking for the name to personalize the experience;
• Addressing the user with the pronoun “you”;
• Bringing it as close as possible to the mental model of WhatsApp or other chats already used by users;
• Creating interface elements.

We defined some metrics using happiness and engagement that we consider important to better understand the experience. - Yes, we borrowed a bit from HEART.

Happiness:

• Goals: complete the registration process in less time;
• Signals: number of people who completed the registration process;
• Metrics: number of people who completed the registration process and the time taken to complete it.

Engagement:

• Goals: respond to as many data as possible in a qualified manner;
• Signals: amount of qualified data;
• Metrics: number of people who responded to the data in a qualified manner;

Task success:

• Goals: use the password recovery exits;
• Signals: number of people who used the exits;
• Metrics: number of people who used the exit and managed to recover their password.

Creating a closed chat seems simple, but when you get into the discovery process, you understand the complexity of guiding the user along happy paths through decision trees.

We put a lot of effort into structuring these trees. At times, we looked at each other and it felt like we were in “Bandersnatch,” that episode of Black Mirror where the programmer freaks out over the number of possibilities the user could have in that scenario.

But whenever we got a little lost, we looked at the macro objective: registering our user.