Building A Chatbot: Flows

Quick links in this article:

In this article, we’ll cover the key flows required to run your chatbot journey. This article is part of a series - be sure to have completed all of the steps in Building A Chatbot: Setup before beginning this one!

Summary

To build a chatbot in Gnatta, you’ll need to create multiple flows in the builder. Together, these flows will guide a customer through their chat journey. At a high level, here’s what each of them does:

• Chatbot Starter Flow (Chat Started event) - Initializes the interaction in an automation state, assigns it to your queue, and sends the first response.

• Check Automation State (Response Received event) - Ensures chatbot flows only process automated interactions, stopping if assigned to an agent.

• Check Pathway (Response Received event) - Determines the customer’s selected pathway, assigns the appropriate label, and routes the interaction accordingly.

• Pathway: X (Response Received event) - Handles a specific chatbot branch (e.g., Returns, Tracking, Claims) by evaluating the journey step and message contents.

• Anything Else Loop (Response Received event) - Ends the chat or re-offers options, resetting the pathway if needed.

• Assign Agent (Response Received event) - Checks if the interaction should be assigned to an agent, verifies availability, and updates interaction state to Queued.

• Ignore Abandoned Chatbot Journeys (Chat Ended event) - Removes abandoned automated chats from the queue to keep reporting clean.

As you can see, most of your chatbot flows happen on the Response Received event. A completed chatbot should took a bit like this:

Open

The chatbot processing flows on a Response Received event

Check Automation State

This super simple flow is just one Decision action. The first branch (labelled Not Automation) is checking if Automation State (Interaction.Automation) Equals False, and splitting the flow accordingly. We’ve labelled the Fallback branch as ‘In Automation’.

Open

Add a Decision action to check if Interaction.Automation is False!

On the Not Automation branch, you’ll need to click into that Stop action and toggle ‘Stop Processing’ to true. This will mean the message that triggered the Response Received event doesn’t go on to trigger the rest of your Chatbot flows and erroneously receive messages whilst assigned to an agent.

Open

Ensure the Stop action for ‘Not Automation’ is set to Stop Processing, so subsequent flows don’t run

This flow is generic - that means it looks exactly the same for every chatbot setup, in every Gnatta domain. You can insert this exact flow into your Gnatta domain by copying the code below. Then navigate to the builder, and click ‘Import from clipboard’.

Then simply hit File>Save and File>Publish. Done!

Open

Once you’ve created, or imported, your Check Automation State flow, ensure you File>Save and File>Publish the flow. Then, navigate to your Response Received event and attach it as the first flow!

Check Pathway

This flow is a bit more involved. Here’s what it will do:

1. It’ll set the Status custom field to Responded (or an equivalent in your Gnatta domain).

2. It will check your Chatbot Pathway custom field for a value.

3. If it does detect a value in that field and it isn’t ‘Reset’, it’ll carry out no further action and will go on to be processed in the next flow (until it reaches the selected pathway).

4. If it doesn’t detect a value in that field, or detects ‘Reset’, it’ll carry out a Decision to check the message the customer has sent and identify the pathway they’ve selected.

5. Depending on the pathway identified, it’ll set the Chatbot Pathway custom field as appropriate and the interaction will then continue processing to reach the correct pathway flow.

6. If the customer’s message doesn’t match any of the criteria, it’ll resend the options and ask the customer to click one of the buttons provided. (Sometimes, customers may use free text to reply, defeating your Decision logic!).

Open

An example Check Pathway flow

As this flow configuration is based on your custom fields and the pathways you’ve planned in your journey, you’ll need to build it bespoke! Check here for a step-by-step for building this flow.

Pathway: X

You’ll need a version of this flow for each of the major pathways you’ve designed your chatbot to handle - such as Pathway: Returns or Pathway: Claims etc. These flows are where the main body of your chatbot responses are going to be determined and sent - here’s an outline of the logic that governs them:

• The first action is a Decision, which checks the Chatbot Pathway custom field to confirm it matches the current pathway (i.e. Returns on the Pathway: Returns flow).

• If it’s the correct pathway, a subsequent Decision will check the Chatbot Journey Step i.e. 0,1,2,34 etc.

• Branch 0 will send the first message, and update the step to 1 then await the customer’s next response.

• Branch 1 will use a Decision to evaluate the customer’s selection and handle appropriately by:

  • sending the appropriate response and setting step 2 OR

  • assigning to Pass Agent path OR

  • assigning to Anything Else path

The step branches will continue in this way until all child branches have reached an end! Check here for a full step-by-step guide for building a pathway:

Anything Else Loops

When the Chatbot Pathway field is set to Anything Else in a previous Pathway: X flow, messages will go on to trigger this flow immediately after that.

This flow will then:

• Ask the customer if they need further help

  • If yes, it will offer the Welcome Options again so they can Reset their journey

  • If no, it’ll close the chat and send the post-chat survey

Check here for a full step-by-step for building this flow:

Assign Agent

When the Chatbot Pathway field is set to Pass Agent in a previous Pathway: X flow, messages will go on to trigger this flow immediately after that.

This flow will then:

• Check if the current time is within the opening hours for the team connected to the account

• If out of hours, send an autoresponse advising your opening hours and close the chat

• If in hours, set the state to Queued so it will be queued for assignation to the next available agent

Check here for a full step-by-step for building this flow:

Ignore Abandoned Chats

Sometimes, customer’s will start a chatbot journey and then abandon the chat before it reaches a conclusion - by assigning or closing itself. If that’s the case, the interaction itself will not be closed, and will remain in an Automated state in your queues. Whilst not inherently problematic, it will fog up your reporting and dashboards over time!

With this flow attached to the relevant Chat Ended event you can:

1. Check if the interaction is currently in an Automated state

2. If it is Automated, check if the Statuscustom field equals Closed (to exclude successfully completed chatbot journeys)

3. If the Status is not Closed, then you set the Status to Ignore

This will remove the interaction from your queues without assigning to an agent or fogging your reports, or accidentally Ignoring successfully completed chats.

Check here for a step-by-step for building this flow: