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.

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.

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).