Writing a Workflow Description
The description is the only input to the assistant's decision about when to use a workflow. These are the five rules Chatleadr checks against, each drawn from a measured failure on a live bot.
Rule 1: Name the Subject#
State what the workflow does in concrete terms. Pronouns with no referent, and keywords that are never listed, fail this rule.
BAD Trigger this workflow if the user asks about it or mentions the words.
GOOD Runs a live sample chat so the visitor can try the bot themselves.The bad version was live on a production bot. It fired on "hi", on "what do you guys do?" and on "what is 47 times 12?", because "it" refers to nothing a reader can see and "the words" were never listed.
Rule 2: Give It a Boundary#
State what the workflow must not fire on. A description with no boundary fires on loosely related questions.
DO NOT USE for general questions about pricing or availability. Answer
those from the knowledge base instead.In testing, rewriting vague descriptions to name their subject and state a boundary moved false triggers from about 7% to about 1%.
Rule 3: Keep It Reachable#
Describe the request the way a visitor phrases it, not as one exact form of words. Requiring a literal phrase, or the workflow's own name, puts it out of reach of most real messages.
BAD Use when the visitor types "Chatbot Demo".
GOOD USE WHEN the visitor asks to see a demo, to try it out, or how it
works in practice.The bad version was a rewrite that read as tighter and performed worse, because none of the real phrasings contained the literal phrase.
Rule 4: Trigger on What the Visitor Said#
Every condition for when to use the workflow has to be decidable from the visitor's message alone. The assistant chooses before the workflow runs, so it cannot know whether a record exists, whether a previous workflow succeeded, or what is in your database.
BAD Do not trigger if the workflow has not completed successfully.That condition cannot be evaluated at the moment of choice, and it degrades the rest of the description.
Rule 5: Say Whose It Is#
Anything belonging to a person or the business should say whose it is.
BAD Emails the catalogue to the visitor.
GOOD Emails the Patio Warehouse catalogue to the visitor.A noun with no owner can be read from either side. "The CV", "the invoice" and "the quote" all leave the assistant to guess whether the document belongs to the business or to the visitor. A workflow described only as "the CV" can offer the visitor their own CV back.
A Template That Satisfies All Five#
Describe what this does in one sentence.
USE WHEN: the visitor asks for <the specific thing>.
DO NOT USE for general questions about <the surrounding topic>.The editor's Start from a template button fills this in while the description is blank. Fill in the placeholders. An untouched template is worse than a blank one: it looks configured and instructs the assistant to fire on <the specific thing>.
Keep Two Descriptions From Competing#
Every active workflow's description is read together, so two workflows described similarly compete for the same messages and either can win.
Give each one a boundary naming the other's territory. A workflow about delivery times says DO NOT USE for returns, and the returns workflow says the reverse. Where two workflows do the same job, delete one.
Selection accuracy falls as the list grows, and each plan caps how many workflows a bot may hold. See plans and limits. For more jobs than your cap allows, run more than one bot, each with its own focused set.
What Chatleadr Checks#
Two checks run, and they differ in strength.
On every save. An AI workflow cannot be switched on with a description that is blank, too short, or an untouched template. This blocks the save. With no description the assistant falls back to guessing from the workflow's name, which measured about 91% selection accuracy in testing against about 99% for a written one.
After save, advisory. The description is checked against the five rules above and anything it breaks is reported, with the rule and what to do about it. It blocks nothing. It agrees with measured outcomes about 83% of the time.
Common Questions#
How Long Should a Workflow Description Be?#
Two to four sentences. One sentence naming what it does, one USE WHEN covering the phrasings visitors use, and one DO NOT USE marking the boundary. Longer descriptions do not measure better. The boundary clause accounts for most of the measured improvement.
Does the Workflow's Name Matter?#
Only when the description is missing. With a description present the name is close to irrelevant to selection. Names still identify the workflow in the editor and the execution log.
Can I Use Keywords in a Description?#
Listing a few real phrasings inside a USE WHEN line helps. A bare list of keywords does not, because the assistant matches on meaning and not on spelling. See why descriptions beat keywords.
Can I Force a Workflow to Run?#
Yes, by binding it to a conversation starter. A starter bound to a workflow runs it directly when clicked and skips selection entirely, so that path does not depend on a description at all.
Does the Knowledge Base Affect Which Workflow Is Chosen?#
No. Selection reads workflow descriptions only. The knowledge base is what the bot answers from once it has decided not to run a workflow.
Why Did the Bot Answer Instead of Running My Workflow?#
Choosing nothing is a valid outcome, and it is what happens when no description clearly covers the message. It points at the description rather than the workflow. Work through my workflow is not triggering.
Does the Order of Workflows Matter?#
No. All descriptions are considered together, so reordering them in the dashboard changes nothing about selection. Tightening the boundaries on two competing descriptions does.
The Advisory Check Flagged Something I Disagree With. What Now?#
Save anyway. The check does not block. If the description reads clearly to someone who does not know your business, it is likely fine.