Proactive Workflows, Variables, and Human Handoff

Proactive Workflows, Variables, and Human Handoff

Once you have built a couple of conversation-triggered workflows, three patterns unlock most of the remaining value. This article walks through each one.

Proactive triggers

A conversation trigger waits for the customer to message first. A proactive trigger lets the widget start a workflow on its own, before the customer says anything.

Common proactive setups:

• Page-targeted nudges. When a visitor lands on /pricing and stays for more than 30 seconds, fire a workflow that asks "Looking for a specific plan? I can help you compare." This catches intent at the moment of consideration.
• Onboarding check-in. When a newly-signed-up user opens the app for the first time, fire a workflow that asks if they want a quick tour or a help article.
• Post-checkout follow-up. Combined with a Wait node, you can run a workflow three days after a purchase to check that everything went well.

Proactive workflows still respect the same controls: they only run while the workflow is Active, and the customer can dismiss the conversation at any time.

Variables across nodes

Anything captured by an Ask, Classify, or Action is available to later nodes as a variable. Two places this matters:

• Inside Action parameters. When you configure an Action node, you map workflow variables to the action's request parameters. So an Ask: order_number followed by an Action: lookup order flows naturally: the action receives the customer's actual order number, not a placeholder.
• Inside message text. Use {variable_name} style placeholders inside Ask and End messages to weave captured values into the reply. For example, after a successful lookup: "Thanks, I can see order {order_number}. It shipped on {order_shipped_at}."

Variables are scoped to a single workflow run, so two parallel customer conversations never see each other's data.

A practical tip: name your variables for the value, not the node. email and order_number age well; ask_node_2_answer does not.

Getting handoff right

Helpium is built so that the bot never auto-escalates. The chatbot will not silently flip a conversation to a human, even if the customer is frustrated. The only path to a human is the explicit "Talk to a human" button or a Handoff node in a workflow you control.

This is intentional. It keeps your inbox volume predictable and gives you full control over when a human is involved.

When designing a workflow, think about handoff as a deliberate exit:

• Reach a Handoff node only when the workflow has gathered enough context that the agent does not have to start from scratch. A workflow that handed off after capturing the customer's email, plan tier, and a description of the issue is far more useful to the agent than one that hands off on the first message.
• Use Conditions and Classify to keep simple cases inside the bot, and route only the cases that actually need a human.
• Pair handoff with a clear closing message to the customer so they know what is happening: "Got it, I am bringing in someone from our team. They will pick this up shortly."

Inspecting workflow runs

Every workflow execution is recorded with full event history: which node ran, what variables were captured, what the AI saw, what it returned, and any action requests and responses. From any conversation you can open the workflow run and step through it.

When something does not behave the way you expect, this is the first place to look. Most "the bot did the wrong thing" issues come down to either an unclear Classify description or an Ask that captured a different shape of answer than the next node expected, and both are visible in the run history.

Where to go from here

If you have not yet, work through:

• What Are AI Workflows? for the high-level intro.
• Workflow Nodes Explained for the node reference.
• Building Your First Workflow for an end-to-end tutorial.