Chat bot or call bot: pick the kind when you create it
Same place, same parts, one decision you make at creation and cannot change afterwards. A call bot needs two things a chat bot has no use for.
Bots, bot flows and knowledge bases share one rail item and are siblings rather than a hierarchy. Within bots there is exactly one irreversible decision: whether this is a chat bot or a call bot.
It is set at creation and shown afterwards as a read-only Type. Getting it wrong means building a new bot and copying the instruction across, which is annoying rather than catastrophic — but avoidable.
Steps
Understand what they share
Both are built from the same five parts: an assistant name, a first message, an instruction, a knowledge base and handover conditions. Both are pointed at by channels, flows and campaigns rather than knowing where they are used.
Understand what only a call bot gets
A voice per language, and its own call timings. A chat bot has no use for either — there is no voice in a WhatsApp message and no calling hours on a text conversation.
Pick the kind at creation
Type is set when the bot is created and displayed read-only afterwards.
Let them work together rather than choosing
They are siblings, not rivals. A chat bot can hand a qualified lead to an AI calling campaign; a call bot can trigger a WhatsApp follow-up. The same customer can be handled by both across a week.
Share the knowledge base across both
One knowledge base serves many bots of either kind. Your prices and policies should be written once for the company, not once per bot.
Check it worked
Look at your bot list. Each row should state its kind, its state and what it serves. If you cannot tell from the list what a bot is for, its name is doing too little work.
The parts people get wrong
- How good a call bot sounds is a plan feature rather than a bot setting, improving at each tier.
- A bot is created as Draft. It does not answer anything until a channel, flow or campaign is pointed at it.