Bot Design Patterns — Entry Points, Triage & Orchestration

Overview

Velaro V20 bots can be designed in several ways depending on your audience, topics, and how you want visitors to experience the conversation. This guide covers the three main entry point patterns, how to route between bots, how specialists return control to the primary bot, and when to use one bot vs two.

The Three Questions Before You Build

Before choosing a pattern, answer these:

1. Who's arriving? — Existing support customers, new prospects, or a mix?

2. What do they need? — 3-4 predictable topics, or open-ended natural language?

3. How do they prefer to communicate? — Click a menu button, or just type?

Your answers determine which pattern to use.

Pattern 1 — Quick Menu (Deterministic)

Best for: 3–4 clear, predictable topics at high volume.

The bot shows clickable buttons ("Support", "Order Status", "Sales", "Other") and routes based on the button clicked. No AI cost — instant, always works.

How to build it: Use a Quick Reply node at the start of your workflow. Each button routes to a separate workflow branch or transfers to a specialist bot.

Always add a catch-all: Any condition node must have a default branch for unrecognized input — route it to an AI node or escalate to an agent. Never leave a visitor stranded.

Pros: Fast, predictable, no LLM cost per interaction.

Cons: Rigid — visitors must fit your buckets. If they type instead of clicking, you need a fallback.

Pattern 2 — AI Triage Bot (Natural Language)

Best for: Mixed audiences, unclear intent, when you want one seamless conversation.

A lightweight AI node reads what the visitor types, classifies their intent, and delegates to the right specialist. Each specialist handles their topic, then calls return_to_previous to hand control back.

How to build it — no coding required:

1. Create a "Triage Bot" AI Config under Bots with a short prompt: "Greet the visitor, understand their request, then delegate to the right specialist."

2. Create each specialist AI Config (Orders Specialist, Sales Specialist, etc.) with its own prompt

3. Open the Triage Bot's workflow, click the AI node, and find the Specialist Agents panel

4. Use the dropdown to select each specialist — no tool names to type

5. For each specialist, fill in the "Specialist handles topics like…" field: e.g. "orders, shipping, returns, tracking"

6. Optionally check which tool servers (BigCommerce, NetSuite, etc.) that specialist gets

7. Save — the system automatically injects delegation tools into the triage bot and return_to_previous into each specialist

The triage bot never needs to know the names of its tools — it sees them automatically as "delegate to Orders Specialist" etc., and uses your scope hint to decide when.

Triage bots should be lightweight: No tools on the triage bot itself — it only classifies and routes. Specialists carry the tools (NetSuite, Shopify, HubSpot, etc.).

Pattern 3 — Pre-Chat Survey

Best for: When you need structured data (name, email, topic) before the conversation starts.

Static pre-chat form (non-interactive): A form shown before the chat opens. Visitor fills it in, clicks Submit, then the bot/agent starts. The form data is available to the bot as conversation variables (visitor name, email, topic choice).

Use this when: You want lead data captured even if the visitor abandons. Good for CRM pre-fill and routing by topic selection.

Conversational opening (interactive): Skip the pre-chat form entirely. Start the bot immediately — it asks for name and email conversationally. More personal and engaging, handles unexpected answers gracefully.

Use this when: Engagement and warmth matter more than rigid data capture.

Choosing between them: Use the static form when structured data is critical before routing. Use conversational when you want the experience to feel human and flexible.

The Hybrid Pattern (Most Recommended)

Minimal pre-chat form (name + email only) → bot starts with context → AI handles the rest.

The form captures the lead even if the visitor leaves. The bot greets them by name and continues conversationally. Best of both: data safety + natural conversation.

Pattern 4: Specialist Knowledge Section (Manuals and Troubleshooting)

Use this when customers ask two different kinds of question: product and order questions, and how-to or fix-it questions answered from manuals. Do not put both in one AI step. Build two.

Step 1, Product and Orders: an AI step that searches your general index and your manual catalog. Add a jump to Troubleshooting.

Step 2, Troubleshooting: an AI step that searches your troubleshooting index and your manual catalog. Add a jump back to Product and Orders.

Each step searches only the indexes listed on it, so answers never mix. A wrong jump costs one move, not a wrong answer. Both steps include the manual catalog, so "do you have a manual for X?" is answered wherever the customer is.

Use two AI steps with jumps, not one large step with every index, and not Route by Intent. Route by Intent sends a customer to a team after the bot finishes. It does not change what a bot searches.

Requires the Troubleshooting Knowledge add-on for the troubleshooting index. The bot will not change or recommend therapy or device settings. It sends those requests to the customer's provider.

Moshky knows this pattern and can walk you through it. Ask her how to set up a troubleshooting section from your manuals, and see the Troubleshooting Knowledge guide for loading them.

How return_to_previous Works

When a specialist bot finishes helping, it calls return_to_previous with a brief summary. The primary/triage bot resumes with that context and continues the conversation.

You do not need to wire this — it is automatic. When a bot runs as a specialist (called by a primary bot), the system automatically injects the return_to_previous tool and prompts the specialist to use it when done.

The specialist never needs to know who called it. return_to_previous always means "go back to whoever delegated to me."

Maximum delegation depth is 5 levels. A specialist can itself delegate to another specialist (sub-specialist), but this is rarely needed.

One Bot vs Two Bots

Use one bot when: Topics are part of the same visitor journey. Order status, return request, and refund question are all one support conversation — one bot with the right skills handles all of it.

Use two bots when:

• Visitor types are different (existing customer vs. new prospect)
• Data sources are completely different (support in NetSuite vs. lead creation in HubSpot)
• You want different tones or escalation rules
• A feature on one bot should never be accessible from the other

Do Bots Need to Name Each Other?

No — orchestration flows only downward. The primary bot lists its specialists in "Can Delegate To." The specialists call return_to_previous when done. Specialists never need to list the primary bot or other specialists.

The only exception: if a specialist needs to itself delegate to a sub-specialist for a sub-topic. In that case, the specialist lists that sub-specialist in its own "Can Delegate To" panel.

Reusing Workflow Logic — Call Workflow, Jump to Canvas, Jump To

Three node types let you reuse logic across workflows instead of rebuilding the same steps twice:

Call Workflow: Runs another workflow inline, like a subroutine, then continues where it left off. Use this to share a common section — e.g. the same pre-chat survey or a standard "collect order number" sequence — across several workflows without maintaining duplicate copies. If you update the shared workflow once, every workflow that calls it picks up the change automatically.

Jump to Canvas: A one-way redirect — the current workflow stops completely and a different workflow canvas takes over from its trigger. Unlike Call Workflow, execution never returns here. Use this when a topic genuinely belongs to a separate, self-contained workflow (e.g. handing a "billing question" conversation fully over to a dedicated Billing workflow) rather than a step inside this one.

Jump To: Redirects to another node within the same workflow — useful for reusing a disconnected branch (like a shared "collect contact info" section) without drawing a visible wire on the canvas. Unlike the two above, this never crosses into a different workflow.

Which one do I want?

• Reuse a section, then come back and keep going → Call Workflow
• Hand the whole conversation off to a different workflow, for good → Jump to Canvas
• Reuse a branch inside the workflow you're already editing → Jump To

Moshky can add any of these three node types for you — just describe what you want ("reuse the same prechat survey in this workflow" or "jump to the Billing workflow when this branch finishes") and she'll wire it in, always asking for your confirmation first since these change how conversations route.

Avoid These Common Mistakes

• No fallback branch: Every condition node must handle the "no match" case — route to an AI node or agent, never a dead end.
• Skill conflict: Do not enable an AI skill (e.g., shopify_get_order) AND a deterministic path that does the same thing. They will conflict. Choose one approach per topic.
• Overloaded primary bot: The triage/primary bot should classify and delegate — not have tools and handle topics itself.
• Wrong pre-chat choice: Static pre-chat form for a conversational brand feels cold. Conversational opening for a compliance-sensitive flow (where you need the email before starting) causes data gaps.

Pre-Collecting Structured Data Before AI Starts

If you need an order number or email before the AI node runs, use AskQuestion nodes before the AI node in the workflow. The AI node's system prompt can reference these variables:

"The customer's order number may be available in the conversation context. Use it if present, otherwise ask."

This combines deterministic reliability (structured data collection) with AI flexibility (everything else).