Conversation Flows

Conversation flows are the automation backbone of RapiDesq. Using the visual flow builder, you design step-by-step interaction sequences that greet contacts, gather information, integrate with external systems, leverage AI for intelligent dialogue and analysis, and route conversations to the right team — all without writing code.

Overview

A conversation flow is a directed graph of steps (also called nodes) that defines what happens when a contact starts an interaction. Each step performs a specific action — displaying a message, asking a question, calling an API, running AI analysis, or routing to a team — and then passes control to the next step based on its configuration.

Flows are created and edited in the visual flow builder, a drag-and-drop canvas where you place nodes, configure their properties, and draw connections between them. The builder gives you a clear, visual representation of every path a conversation can take.

Flows connect to your customer-facing channels. When you assign a flow to a chat widget, email channel, or web form, it runs automatically whenever a new conversation arrives on that channel. This means you design the automation once, then deploy it to any channel with a single configuration change.

The flow engine supports over 15 node types spanning messaging, data collection, routing, AI, external integrations, conditional logic, and ticket management. Whether you need a simple greeting-and-route sequence or a sophisticated multi-branch automation with API lookups and AI classification, the flow builder has you covered.

Accessing the Flow Builder

To create or edit a conversation flow:

1. Navigate to Admin > Conversation Flows in the left-hand menu.
2. You will see a list of all flows for your tenant, showing each flow's name, assigned channel, and published status.
3. Click Create Flow to start a new flow, or click on an existing flow's name to open it for editing.
4. The visual flow builder canvas opens. From here you can:
   • Drag new nodes from the node palette onto the canvas.
   • Click a node to open its configuration panel on the right.
   • Draw connections between nodes by dragging from one node's output port to another node's input port.
   • Delete nodes or connections by selecting them and pressing the delete key.
5. Click Save to save your changes as a draft, or Publish to make the flow live.

Node Types Reference

The flow builder provides a rich set of node types organized into functional categories. Each node type is designed for a specific purpose — combine them to build exactly the interaction you need.

Send Message

Displays a text message to the contact. No response is expected or collected — the flow immediately proceeds to the next connected step.

When to use it: Greetings, status updates, informational messages, farewell messages, or any point where you need to communicate something to the contact without waiting for a reply.

Configuration:

• Message content — The text displayed to the contact. Supports variable interpolation using {{variableName}} syntax, so you can personalize messages with data collected earlier in the flow.

Output: None. The flow advances to the next step automatically.

Ask Question

Prompts the contact with a question and waits for their response. The contact's answer is stored in a named variable that can be referenced by any subsequent step in the flow.

When to use it: Collecting a single piece of information such as a name, order number, issue description, or a selection from a list of options.

Configuration:

• Question text — The prompt displayed to the contact.
• Variable name — The name used to store the contact's response (e.g., customerName, orderNumber). This variable can be referenced in later steps as {{orderNumber}}.
• Response options (optional) — If provided, the contact selects from predefined choices presented as buttons rather than typing a free-text response.

Output: The contact's response is stored in the configured variable. The flow waits until the contact responds before advancing.

Collect Information

Displays an inline form within the chat interface to collect multiple pieces of structured data at once. The form uses the same field types available in web forms, providing a familiar and validated data collection experience directly inside the conversation.

When to use it: Gathering several related fields at once — such as name, email, and a description of the issue — rather than asking for each piece one at a time. This is faster for the contact and produces cleaner, validated data.

Configuration:

• Form fields — Define one or more fields, each with:
  • Field type — TEXT, EMAIL, PHONE, TEXTAREA, SELECT, or NUMBER.
  • Label — The label displayed above the field.
  • Variable name — Where the submitted value is stored (e.g., contactEmail).
  • Required — Whether the field must be filled before the form can be submitted.
  • Validation — Built-in validation based on the field type (e.g., email format, phone number format, numeric range).

Output: Each field's value is stored in its configured variable. The flow waits for the contact to complete and submit the form.

Bot Conversation

Hands the conversation to an AI bot for free-form, natural language dialogue. The bot engages in a back-and-forth conversation with the contact, understanding their questions and providing relevant responses. The bot continues the dialogue until it determines the issue is resolved or needs escalation to a human agent.

When to use it: Handling open-ended customer inquiries, answering frequently asked questions, troubleshooting common issues, or providing a first line of support before routing to a human agent.

Configuration:

• Bot instructions — Guidelines that shape the bot's behavior, tone, and scope. For example: "You are a helpful support agent for an e-commerce company. Help customers with order tracking, returns, and product questions. If you cannot resolve the issue, escalate to a human agent."
• Escalation conditions — Define when the bot should stop and hand off to the next step in the flow (e.g., the contact explicitly requests a human, or the bot determines it cannot resolve the issue).

Output: The flow advances to the next step when the bot conversation ends (either resolved or escalated). The full conversation history is available to subsequent steps and to any agent who receives the conversation.

Route to Team

Transfers the conversation to a specific team's agent queue. Once this step executes, the conversation enters the team's queue and the routing engine uses the team's configured agent selection strategy (round-robin, least active, etc.) to assign an available agent.

When to use it: Any time the conversation needs to be handed off to a live agent. This is typically the terminal step for a flow path, after information has been collected and the appropriate team has been determined.

Configuration:

• Team — The team to route the conversation to. Select from teams configured in your tenant.

Output: The conversation is placed in the selected team's queue. All data collected during the flow (variables, conversation history, form submissions) is passed to the agent for context.

Schedule Condition

Branches the flow based on whether the current time falls within configured business hours. This node has two output paths: one for when the interaction occurs during business hours, and one for outside business hours.

When to use it: Providing different experiences based on time of day. During business hours you might route directly to a team, while after hours you might collect the contact's information and create a ticket for follow-up.

Configuration:

• Schedule — Define the business hours schedule (days of the week, start and end times, timezone).

Output: Two branches:

• During hours — The path followed when the current time is within the configured schedule.
• Outside hours — The path followed when the current time is outside the configured schedule.

Conditional Branch

Evaluates one or more conditions against collected data, flow variables, or AI classifications, and routes the conversation down the appropriate path. Each condition creates a separate output branch, functioning as an if/else if/else decision tree.

When to use it: Routing the conversation differently based on contact responses, API results, AI classifications, or any other variable data. This is the primary decision-making node in the flow builder.

Configuration:

• Conditions — One or more conditions, each consisting of:
  • Variable — The flow variable to evaluate (e.g., issueCategory, customerTier).
  • Operator — The comparison operator: equals, not equals, contains, does not contain, starts with, ends with, greater than, less than, is empty, is not empty.
  • Value — The value to compare against. Supports literal values and variable references.
• Default path — The branch followed when none of the defined conditions match (the "else" case).

Output: One branch per condition, plus a default branch. The flow follows the first condition that evaluates to true.

See the Conditional Logic section below for a detailed guide on building effective conditions.

Set Variable

Stores a value in the flow's execution context. The value can be a literal string, a number, a computed expression, or a reference to another variable. Once set, the variable is available to all subsequent steps.

When to use it: Preparing data for later use — setting a default value, combining multiple variables into a single formatted string, storing a computed result, or normalizing a value before it is evaluated by a condition.

Configuration:

• Variable name — The name to assign (e.g., priority, formattedName).
• Value — The value to store. Supports variable interpolation with {{variableName}} syntax.

Output: The variable is available for use in all subsequent steps via {{variableName}}.

Subflow

Executes another flow as a nested subroutine. The parent flow pauses, the referenced subflow runs to completion, and then the parent flow resumes from the step after the Subflow node.

When to use it: Reusing common sequences across multiple flows. For example, if several flows share the same contact information collection sequence or the same after-hours handling logic, extract that sequence into its own flow and reference it with a Subflow node.

Configuration:

• Flow — The flow to execute as a subflow. Select from published flows in your tenant.

Output: Variables set by the subflow are available in the parent flow after the subflow completes. The parent flow resumes execution from the next connected step.

End Flow

Explicitly terminates the flow execution. The conversation ends from the automation's perspective.

When to use it: When the flow has fully resolved the contact's issue and no further action is needed, or when you want to explicitly mark the end of a branch that should not route to an agent (e.g., the contact chose to cancel their request).

Configuration: None.

Output: The flow stops executing. No further steps run on this path.

API Call

Makes an HTTP request to an external REST API and stores the response data in a flow variable. This node enables your flows to interact with external systems — looking up customer records, checking order statuses, verifying account details, or triggering actions in other platforms.

When to use it: Any time the flow needs data from or needs to trigger an action in an external system. Common use cases include CRM lookups, order management queries, identity verification, and webhook triggers.

Configuration:

• URL — The API endpoint to call. Supports variable interpolation (e.g., https://api.example.com/orders/{{orderNumber}}).
• Method — The HTTP method: GET, POST, PUT, PATCH, or DELETE.
• Headers — HTTP headers to include in the request (e.g., Authorization, Content-Type). Values support variable interpolation.
• Request body — The body payload for POST, PUT, and PATCH requests. Supports JSON with variable interpolation.
• Response variable — The variable name where the parsed response body is stored.

Output: The API response body is parsed and stored in the configured variable. Individual fields from the response can be accessed using dot notation in subsequent steps (e.g., {{apiResponse.status}}, {{apiResponse.customer.name}}).

See the External Integrations section below for detailed guidance on building API Call nodes.

AI Analyze

Runs AI analysis on conversation data. This node can classify the contact's intent, extract structured entities from free-text input, summarize the conversation, or make routing recommendations based on the conversation content.

When to use it: Understanding unstructured contact input without requiring the contact to select from a predefined list. For example, analyzing a contact's description to determine their issue category, extracting an order number from a natural-language message, or assessing the urgency of a request.

Configuration:

• Analysis type — The kind of analysis to perform:
  • Classify intent — Categorize the contact's message into one of your defined intent categories.
  • Extract entities — Pull structured data (names, order numbers, dates, product names) from free-text input.
  • Summarize — Generate a concise summary of the conversation so far.
  • Routing recommendation — Suggest the best team to handle the conversation based on its content.
• Input — The data to analyze (typically a variable containing the contact's message or the full conversation history).
• Result variable — Where the analysis result is stored.

Output: The AI analysis result is stored in the configured variable and can be used by subsequent Conditional Branch nodes, Send Message nodes, or any other step that references variables.

Generate Ticket Description

Uses AI to generate a structured ticket description from the conversation history. Chat conversations are often messy and informal — this node transforms them into clean, structured summaries that agents can quickly understand.

When to use it: Before routing to a team or creating a ticket, to ensure the agent receives a clear, well-organized summary rather than having to read through the entire conversation transcript.

Configuration:

• Result variable — Where the generated description is stored.

Output: A structured ticket description stored in the configured variable. The description typically includes a summary of the issue, key details extracted from the conversation, and any relevant context.

Notify User

Sends an internal notification to specific users or roles within RapiDesq. This does not send a message to the contact — it notifies your internal team members.

When to use it: Alerting supervisors about high-priority conversations, notifying specific users about escalations, or sending internal updates when certain flow conditions are met.

Configuration:

• Recipients — Select individual users or roles to notify.
• Notification message — The notification content. Supports variable interpolation.

Output: The notification is sent. The flow continues to the next step without waiting for any response to the notification.

Update Ticket

Modifies ticket fields during flow execution. This allows the flow to enrich the ticket with data collected during the conversation before it reaches an agent.

When to use it: Setting ticket priority based on the contact's issue category, adding tags for tracking, updating the status, or populating custom fields with information collected during the flow.

Configuration:

• Field updates — One or more ticket field modifications:
  • Status — Set the ticket status.
  • Priority — Set the ticket priority (e.g., based on AI analysis or contact input).
  • Tags — Add tags to the ticket for categorization and reporting.
  • Custom fields — Populate custom ticket fields with collected data.

Output: The ticket is updated. The flow continues to the next step.

Flow Variables & Data

Flow variables are the mechanism for passing data between steps. Every flow execution maintains a context — a set of named variables that any step can read from or write to.

How Variables Are Created

Variables are created by several node types:

• Ask Question — Stores the contact's response in the configured variable name.
• Collect Information — Stores each form field's submitted value in its configured variable name.
• Set Variable — Explicitly sets a variable to a specified value.
• API Call — Stores the API response body in the configured response variable.
• AI Analyze — Stores the analysis result in the configured result variable.
• Generate Ticket Description — Stores the generated description in the configured result variable.

Referencing Variables

Once a variable is set, it can be referenced in any subsequent step using the {{variableName}} interpolation syntax. This works in:

• Message content in Send Message and Ask Question nodes.
• API Call URLs, headers, and request bodies.
• Conditional Branch condition values.
• Notify User message content.
• Set Variable value expressions.

For API Call response variables that contain structured JSON, use dot notation to access nested fields: {{orderLookup.status}}, {{orderLookup.shipping.trackingNumber}}, {{customerData.account.tier}}.

Variable Scope and Persistence

Variables are scoped to the flow execution. They persist for the lifetime of the conversation's flow execution, which means:

• Variables set early in the flow are available to all subsequent steps, regardless of which branch the flow takes.
• Variables set in a subflow are available in the parent flow after the subflow completes.
• If a flow is interrupted (e.g., the contact disconnects and returns), the execution state — including all variables — is persisted and restored when the flow resumes.
• When the flow ends (via Route to Team or End Flow), the collected data is attached to the conversation record for agent reference and analytics.

Conditional Logic

The Conditional Branch node is the primary decision-making mechanism in the flow builder. It evaluates conditions against flow variables and directs the conversation down different paths based on the results.

Condition Structure

Each Conditional Branch node contains one or more conditions. Conditions are evaluated in order from top to bottom — the flow follows the first condition that evaluates to true. If no condition matches, the flow follows the default (else) path.

Each condition consists of three parts:

1. Variable — The flow variable to evaluate.
2. Operator — How to compare the variable's value.
3. Value — The value to compare against (not required for is empty and is not empty operators).

Comparison Operators

Creating Multiple Paths

A single Conditional Branch node can have many conditions, each leading to a different path. For example, a branch evaluating issueCategory might have:

• Condition 1: issueCategory equals billing → Route to Billing Team
• Condition 2: issueCategory equals technical → Route to Technical Support
• Condition 3: issueCategory equals sales → Route to Sales Team
• Default: Route to General Support

You can also chain multiple Conditional Branch nodes in sequence to build complex, multi-level decision trees. For example, first branch on issue category, then within the technical support branch, add another condition node to branch on severity level.

AI Capabilities

RapiDesq flows integrate AI at multiple levels, from free-form conversational dialogue to structured analysis and content generation.

Free-Form AI Dialogue (Bot Conversation)

The Bot Conversation node hands full conversational control to an AI bot. Unlike the structured Ask Question node, the bot engages in open-ended, multi-turn dialogue with the contact. The bot understands context, asks clarifying questions, and provides answers or guidance.

Key characteristics of bot conversations:

• Multi-turn — The bot maintains context across multiple exchanges, allowing a natural back-and-forth dialogue.
• Contextual — The bot has access to all data collected earlier in the flow, so it can reference the contact's name, previous answers, and other variables.
• Bounded — The bot follows your configured instructions and escalation conditions. It will hand off to the next flow step when the conversation warrants it.
• Transparent — The full bot conversation history is available to agents if the conversation is routed to a team, so agents have complete context.

Structured AI Analysis (AI Analyze)

The AI Analyze node applies targeted AI analysis to specific data rather than engaging in dialogue. Use it to:

• Classify intent — Determine what the contact wants (e.g., "billing inquiry", "technical issue", "feature request") from their free-text input. Use the classification result in a Conditional Branch to route accordingly.
• Extract entities — Pull structured data from unstructured text. For example, extract an order number, product name, or date from a message like "I need to return order ORD-12345 that I placed last Tuesday."
• Summarize — Generate a concise summary of the conversation so far. Useful before routing to provide agents with a quick overview.
• Recommend routing — Let the AI suggest the best team to handle the conversation based on its content analysis.

Automated Ticket Descriptions (Generate Ticket Description)

Chat conversations are often informal, fragmented, and filled with back-and-forth. The Generate Ticket Description node transforms this raw conversation history into a clean, structured ticket description. The generated description typically includes:

• A concise summary of the issue.
• Key details extracted from the conversation (account info, error messages, steps already taken).
• Relevant context that helps the assigned agent understand and resolve the issue quickly.

This is particularly valuable for after-hours flows where a ticket is created from the conversation but no agent is immediately available — the agent who picks up the ticket the next day gets a clear, actionable description rather than a raw chat transcript.

External Integrations

The API Call node connects your flows to any external system that exposes a REST API. This enables real-time data lookups and actions within the flow.

Configuring an API Call

1. Set the URL — Enter the full endpoint URL. Use variable interpolation to include dynamic values: https://api.yourcrm.com/contacts?email={{contactEmail}}.
2. Choose the HTTP method — GET for retrieving data, POST for creating or triggering actions, PUT/PATCH for updating records.
3. Add headers — Include authentication headers (Authorization: Bearer {{apiToken}}) and content type headers (Content-Type: application/json).
4. Set the request body (for POST/PUT/PATCH) — Write JSON with variable interpolation:

   {
     "customerEmail": "{{contactEmail}}",
     "issueDescription": "{{issueDescription}}",
     "priority": "{{priority}}"
   }

5. Name the response variable — Choose a descriptive name like orderLookup or crmResult. The parsed JSON response body is stored in this variable.

Using API Responses

After an API Call executes, the response body is available as a structured variable. Access individual fields with dot notation:

• {{orderLookup.status}} — The order's status field.
• {{orderLookup.shipping.carrier}} — A nested field.
• {{crmResult.customer.name}} — The customer's name from a CRM lookup.

Use these values in Send Message nodes to display personalized information, in Conditional Branch nodes to make routing decisions, or in Update Ticket nodes to enrich the ticket.

Error Handling

API calls can fail for many reasons — the external service may be down, the request may be malformed, or authentication may expire. Design your flows to handle these scenarios gracefully:

• After an API Call node, use a Conditional Branch to check whether the response variable contains the expected data.
• Use the is empty operator to detect failed or empty responses.
• If the API call fails, route the conversation to an agent rather than leaving the contact stuck. A Send Message node explaining that the lookup could not be completed provides a better experience than silence.

Common Use Cases

• CRM lookup — Look up the contact in your CRM by email to retrieve their account details, subscription tier, or recent interactions.
• Order status — Query your order management system with the contact's order number to display real-time status and tracking information.
• Account verification — Verify the contact's identity by checking their provided details against your system of record before granting access to sensitive information.
• Ticketing system sync — Create or update records in external ticketing systems alongside RapiDesq tickets.
• Data lookup — Query an external API to find relevant information based on the contact's issue, and display the results in a message.

Assigning Flows to Channels

A flow only runs when it is assigned to a channel. Flows can be assigned to three types of channels:

Chat Widget

Each chat widget can have one flow assigned to it. When a contact starts a new conversation through the widget, the assigned flow runs automatically.

To assign a flow to a chat widget:

1. Navigate to Admin > Chat Widgets and select the widget to configure.
2. In the widget settings, find the Conversation Flow option.
3. Select the published flow to assign.
4. Save the widget configuration.

See the Chat Widget Setup guide for full details on widget configuration.

Email Channel

Flows can be assigned to email channel routing to automate the handling of incoming emails. When a new email arrives, the assigned flow processes it — classifying the content, extracting data, and routing to the appropriate team.

See the Email Channel guide for configuration details.

Web Form

Web form submissions can trigger a flow to handle the incoming request. The form data is available as variables within the flow, enabling routing and processing based on what the contact submitted.

See the Web Forms guide for configuration details.

Hot-Swapping Flows

One of the key benefits of channel-based flow assignment is that you can change the active flow without modifying any embed code or channel configuration beyond the flow selection. This means you can:

• Switch from one flow to another instantly.
• A/B test different flows by swapping them on specific widgets.
• Deploy seasonal or campaign-specific flows and revert when they are no longer needed.

Versioning & Publishing

RapiDesq uses a draft/published model for flow versioning, enabling you to safely iterate on flows without disrupting live conversations.

Draft vs. Published

• Draft — A saved version of the flow that is not yet live. You can make changes, test, and iterate on drafts freely. Drafts do not affect any active conversations.
• Published — The live version of the flow. When a new conversation starts on a channel assigned to this flow, it runs the published version. Only one version can be published at a time.

Safely Editing Live Flows

To make changes to a live flow:

1. Open the flow in the builder. Your changes are automatically saved as a draft.
2. Edit and test your changes in draft mode.
3. When satisfied, click Publish to make the new version live.

Until you click Publish, the currently published version continues to serve all new conversations.

In-Progress Conversations

When you publish a new version of a flow, conversations that are already in progress are not affected. They continue running on the version that was active when they started. Only new conversations use the newly published version. This ensures that contacts are never disrupted mid-conversation by flow changes.

Building Common Flows

The following examples walk through practical flows that address common support scenarios. Use them as starting points and customize them for your needs.

Example 1: Basic Support Triage

This flow greets the contact, asks about their issue category, and routes them to the appropriate team.

1. Send Message — "Welcome to RapiDesq support. We're here to help."
2. Ask Question — "What do you need help with?" with response options: Billing, Technical Support, Account Management, Other. Store the response in issueCategory.
3. Conditional Branch — Evaluate issueCategory:
   • issueCategory equals Billing → Route to Team (Billing)
   • issueCategory equals Technical Support → Route to Team (Engineering Support)
   • issueCategory equals Account Management → Route to Team (Account Management)
   • Default → Route to Team (General Support)

This simple pattern ensures that every contact reaches the right team without requiring agents to manually triage and transfer conversations.

Example 2: After-Hours Handling

This flow provides different experiences depending on whether the contact reaches out during or outside business hours.

1. Send Message — "Hello! Thanks for contacting us."
2. Schedule Condition — Check business hours (Monday-Friday, 9 AM-6 PM):
   • During hours path:
     1. Ask Question — "What can we help you with?" (store in issueDescription)
     2. Route to Team — Route to General Support
   • Outside hours path:
     1. Send Message — "Our team is currently offline. Business hours are Monday-Friday, 9 AM-6 PM. We'll create a ticket and follow up with you as soon as possible."
     2. Collect Information — Form with fields: Name (TEXT, contactName), Email (EMAIL, contactEmail), Describe your issue (TEXTAREA, issueDescription)
     3. Generate Ticket Description — Generate a structured description (store in ticketDescription)
     4. Update Ticket — Set priority to Normal, add tag after-hours
     5. Send Message — "Thank you, {{contactName}}. We've created a ticket and will follow up at {{contactEmail}} during business hours."
     6. End Flow

This pattern ensures after-hours contacts still have a good experience and that their issues are captured for follow-up.

Example 3: AI-Assisted Intake

This flow uses AI to handle the initial conversation, then classifies and routes based on what the AI learned.

1. Send Message — "Hi there! I'm an AI assistant and I'll do my best to help you. If I can't resolve your issue, I'll connect you with a human agent."
2. Bot Conversation — The AI bot engages in free-form dialogue, trying to understand and resolve the contact's issue. Configured to escalate if the issue requires a human or if the contact requests one.
3. AI Analyze — Classify the conversation intent (store in intentCategory). Extract key entities (store in extractedEntities).
4. Generate Ticket Description — Create a clean summary of the conversation (store in ticketSummary).
5. Update Ticket — Set the description to {{ticketSummary}}, add tag based on {{intentCategory}}.
6. Conditional Branch — Evaluate intentCategory:
   • intentCategory equals billing → Route to Team (Billing)
   • intentCategory equals technical → Route to Team (Engineering Support)
   • intentCategory equals sales → Route to Team (Sales)
   • Default → Route to Team (General Support)

With this pattern, the AI bot handles what it can, and conversations that need human attention arrive at the right team with a clean summary and classification — saving agents significant triage time.

Tips & Best Practices

Design Principles

• Start simple, iterate often — Begin with a straightforward greeting-and-route flow. Once it is working reliably, gradually add AI, API integrations, and more branches. Complexity introduced all at once is hard to debug.
• Every path must terminate — Ensure every branch in your flow ends at either a Route to Team node or an End Flow node. Dead-end paths leave contacts stuck with no response.
• Always provide a human fallback — No matter how capable your AI or automation is, some contacts will need a human agent. Every flow should have a path to reach one.
• Use subflows for reusable logic — If you find yourself duplicating the same sequence of steps across multiple flows (e.g., contact information collection, after-hours handling), extract it into a subflow. This keeps your flows DRY and easier to maintain.

Data Collection

• Collect only what you need — Every question or form field adds friction. Only collect information that will be used for routing, personalization, or ticket creation.
• Use Collect Information for multiple fields — When you need several pieces of data, an inline form is faster and feels more natural than asking each question one at a time.
• Validate early — Use the built-in field type validation (EMAIL, PHONE, NUMBER) in Collect Information to catch errors at the point of entry rather than downstream.

AI Usage

• Set clear bot instructions — The more specific your Bot Conversation instructions, the better the bot performs. Define the scope of what it should handle and when it should escalate.
• Use AI Analyze for routing decisions — When the contact's intent is not captured by a predefined list of options, use AI Analyze to classify their free-text input and branch accordingly.
• Generate ticket descriptions for agents — Agents work faster when they receive a structured summary rather than a raw transcript. Add a Generate Ticket Description node before any Route to Team node.

Testing

• Test every path — Walk through every branch of your flow, including default/else paths and error conditions. Contacts will encounter edge cases that you did not anticipate if you only test the happy path.
• Verify API integrations with real data — Use test mode to confirm that API Call nodes receive the expected responses and that your flow handles both success and failure cases.
• Test with different schedule times — If your flow uses Schedule Condition nodes, verify both the during-hours and outside-hours paths.
• Check variable interpolation — Make sure that {{variableName}} references in your messages resolve correctly and that the displayed values make sense in context.

Monitoring and Optimization

• Review flow analytics — Monitor where contacts drop off, which branches are used most, and where the flow does not perform as expected. Use these insights to optimize the experience.
• Track execution history — The flow engine records the execution path for each conversation, showing which steps were executed and what data was collected. Review this when debugging unexpected behavior.
• Iterate based on agent feedback — Agents see the results of your flows every day. Ask them which conversations arrive well-prepared and which need better automation.