Chatbot Settings in Mumble

TL;DR

Before you build the conversation flow on the canvas, you set the foundation on the chatbot’s settings screen. The settings determine what the bot knows about itself (name, language, description), who triggers it (keywords), who it runs on (targeting), and how it behaves at the edges (going back, returning to start, handing off to an agent, and resetting). The canvas is the conversation board, but the settings are the framework.

Background: the split between settings and canvas

Every chatbot in Mumble has two work areas. The canvas, where you build the conversation flow (blocks, replies, branches), and the settings screen, where you define the framework that flow runs within. Don’t confuse the two. A change on the canvas doesn’t affect who triggers the bot, and a change in the settings doesn’t affect what the bot says. The two screens are connected through the “Settings” button in the canvas’s bottom toolbar.

Chatbot details

The first part of the settings screen is the bot’s general identification. Four fields:

Chatbot name. An internal name that helps you identify the bot in the list. Not visible to customers. It’s worth using a descriptive name like “Hebrew Customer Service” or “Website Lead Qualification,” not just “Bot 1.”
Business name. The name the bot can use in its messages (if you reference it with a variable). Usually identical to the business name that appears in the WhatsApp profile.
Chatbot language. The language the bot operates in. The default is “Hebrew.” We recommend creating a separate bot for each language, rather than one bilingual bot.
Chatbot description. Free text describing what the bot does. Mainly for your own and your team’s internal needs, not for display to the customer. It’s worth writing the bot’s purpose and target audience here, so others working on it can understand it quickly.

Keyword to trigger the bot

The “Which word will trigger the bot?” area defines what the customer needs to type for this bot to start. When a customer sends a message containing the word (or one of the words) defined here, the bot kicks in and starts from the main block on the canvas.

Format. Plain text. No # at the start, no special characters. Valid examples: “customer-service”, “menu”, “support”, “interested”.
How many words. You can add several synonyms for the same bot by clicking +. Useful for covering variations customers might type without knowing the exact word in advance.
How customers learn the word. Usually by promoting a WhatsApp link with ?text= that fills in the word automatically, a QR code that generates that same link, or a Quick Reply button inside a message template.

Keywords for controlling the conversation

Separate from the trigger word, there are three groups of command words that let the customer control the flow regardless of the specific block they’re in. Each group supports several synonyms.

Go back one step. Default “back.” When the customer types “back” at any step, they return to the previous block in the flow.
Return to the start of the bot. Default “main.” When the customer types “main,” they’re sent back to the starting block.
Switch to a human agent. Default “agent.” When the customer types “agent,” the bot ends its role and the conversation moves to manual handling by the team.

We recommend not changing the defaults (“back,” “main,” “agent”) unless there’s a strong reason. If you do change them, it’s important to update all the messages on the canvas that mention them (“type ‘main’ at any step to return to the start”), otherwise the instruction will point to a word that isn’t active.

Chatbot targeting

The “Choose lists or customers the bot will run on” area determines who the bot can run on. Three options:

All customers. The bot will trigger on every message that comes into the account. This is the classic route for a main opening bot that handles every conversation. Only one bot can be set up this way at any given time.
Customers from lists. The bot will trigger only on customers assigned to one or more lists. Useful for domain-specific bots. Example: a Hebrew service bot only for the “Hebrew Speakers” list, an English service bot only for the “English Speakers” list.
Specific customers. The bot will trigger on individual customers you search for and add manually. Useful for testing before going to production, pilots, or handling a single VIP customer.

Targeting is set at configuration time and works on messages that arrive afterward. It doesn’t trigger the bot retroactively on open conversations.

Reset settings

The “Under what conditions will we reset the bot” area determines what happens when the conversation goes off track. Four fields:

Reset message text. The message sent to the customer the moment the bot resets the conversation (whether for timing reasons, too many attempts, or another reason). Example: “The conversation has restarted, how can we help?” Don’t leave this field empty, otherwise the customer will get a reset with no message and think the bot is broken.
Response to an invalid message. The message sent when the customer types something that no reply in the current block catches. Example: “Please choose one of the options from the menu.” This is the first message, shown until the number of attempts defined in the next field is reached.
Timer. The number of hours since the customer’s last message, after which the bot returns to the main block. Default 12 hours. Useful so a customer who hasn’t replied for a long time doesn’t stay stuck in the middle of a flow. If you set 0 or a very low value, the bot will behave like a one-time conversation with no continuity.
Number of attempts. How many times the customer can type an invalid message before the bot automatically resets them to the main block. Default 5. A value that’s too low (1 or 2) will bounce customers out quickly. A value that’s too high (10+) will tire out stuck customers.

After saving the settings

Saving the settings doesn’t activate the bot in production. For it to start working, you need to:

Go to the canvas and build at least the main block.
Click the activation button in the canvas’s bottom toolbar. The icon will turn from red to green.

A bot that’s configured but turned off won’t trigger even if the customer typed a keyword. A bot with no main block won’t start even if it’s active.

Common issues

I set a keyword but the bot doesn’t start when it’s typed

Possible reasons: the bot isn’t active (red icon in the canvas’s bottom toolbar), the customer isn’t in the bot’s targeting (if you set a specific list, customers outside the list won’t get the bot even if they typed the word), or the keyword wasn’t saved. Fix: make sure the bot is active, check the targeting area, and confirm the settings were saved.

Customers get stuck and can’t get back to the start

Cause: the bot’s messages on the canvas say “type ‘main’ to return,” but in the settings you changed the default to “start.” Fix: align the two. Either restore the default to “main,” or update all the messages on the canvas that use the word.

The timer doesn’t work and customers stay stuck in one block for hours

Cause: the value in the “Timer” field is too high, or it wasn’t saved. Fix: check the value. A reasonable default for day-to-day work is 4 to 12 hours. If you want the customer to always return to the start after a night, 8 hours is a good value.

The bot resets customers too quickly

Cause: the value in the “Number of attempts” field is too low. A value of 1 or 2 means every typo triggers a reset. Fix: raise it to 4 or 5. Also set a clear “Response to an invalid message” that explains to the customer what to type, so they don’t reach a reset at all.

The bottom line

The settings define the framework: who triggers the bot, who it runs on, how it lets the customer go back or switch to an agent, and when it resets. The canvas won’t help if the framework is wrong, and a correct framework won’t be enough without a working canvas. The two screens go together.

Want to Use WhastApp API?

Chatbot Settings in Mumble: Name, Keywords, and Targeting

Mumble Team