AI Procedures vs. Workflows: Which Automation Tool Does Your Team Need?
Customer service teams running Intercom or any modern AI support platform typically have two automation tools available: Procedures, which guide an AI agent through multi-step, judgment-intensive query resolution, and Workflows, which route conversations, trigger background automations, and present customers with structured button-driven paths. Both automate customer interactions. They solve different problems.
Choosing the wrong tool for a given use case is one of the most common reasons automation projects underperform. This article explains what each tool does, where each one excels, and the decision criteria that should guide which you reach for on any given query type.
What is an AI Procedure?
A Procedure instructs an AI agent on how to handle a specific class of complex customer query from intake to resolution. You write it in natural language, like training a teammate on an SOP, and add conditions, code, and system integrations where precision matters.
Procedures adapt. When a customer changes their mind mid-conversation, asks an unexpected question, or provides information out of order, the agent reasons about what to do next. Procedures use AI judgment to navigate conversations that do not follow a script.
Procedures are built for queries that require:
- Collecting information from the customer across multiple turns
- Pulling live data from external systems before making a decision
- Applying business logic that branches based on what that data shows
- Resolving the issue autonomously or handing off to a human with full context
Real examples: Subscription cancellation with retention options based on plan tier; damaged-order claims with evidence collection; prescription refill requests requiring pharmacy system lookups; account verification with identity checks.
What is Workflow Automation?
A Workflow is a visual, canvas-based automation that presents customers with structured paths using reply buttons, routes conversations to teams based on attributes, and triggers background actions based on conversation events.
Workflows follow predefined paths. When a customer clicks "Billing issue" in a triage menu, the Workflow routes to the billing team. When a conversation closes, a Workflow fires a CSAT survey. When a high-value customer contacts support, a Workflow routes to a dedicated team and sends a Slack notification.
Workflows are built for interactions that require:
- Guiding customers through a fixed set of options where the paths are known in advance
- Routing conversations to the right team or channel based on topic, segment, or attributes
- Triggering automated actions in response to conversation events (assignment, closure, SLA breach)
- Running background automations that do not require a customer-facing conversational interaction
Real examples: Triage menus with routing by topic; CSAT surveys triggered on close; priority routing for enterprise accounts; assignment rules based on conversation tags; SLA alerting.
The Core Difference: Open Conversations vs. Structured Paths
The fundamental distinction is how each tool handles customer input.
Workflows use reply buttons and predefined paths. The customer chooses from options you defined. If they type a free-text response when a button is expected, the flow breaks. This is a feature, not a bug: structured paths are predictable, fast to build, and easy to maintain for interactions where the set of options is genuinely limited.
Procedures use open-ended conversation. The customer types anything, and the agent reasons about how to respond while staying within the Procedure's defined logic. This is necessary for resolution-oriented interactions where the customer's situation, and therefore the right answer, varies in ways you cannot enumerate in advance.
Decision Framework: Which Tool to Use
Use a Procedure when:
- The query requires two or more steps to resolve
- You need to pull live system data to give the right answer
- The right response depends on what the data shows (branching)
- The customer needs to provide information in a free-text, conversational way
- The goal is resolution, not routing
- You need the agent to take an action in an external system (update a record, trigger a cancellation)
Use a Workflow when:
- You are routing the conversation to the right team or channel
- You are presenting a limited, well-defined set of options
- You are triggering a background action that does not require further conversation
- You need to collect structured information through a form-like interaction
- You need to automate an action that fires when a conversation reaches a certain state
Use both together when:
This is the most common production architecture. A Workflow handles initial triage: routing conversations by topic, filtering by customer segment, and surfacing a triage menu. When a complex query type is identified, the Workflow routes to the AI agent, which then runs the appropriate Procedure for resolution.
| Query characteristic | Procedure | Workflow |
|---|---|---|
| Requires live system data | Yes | No |
| Resolution requires AI judgment | Yes | No |
| Customer inputs are free-text | Yes | No |
| Goal is routing, not resolution | No | Yes |
| Requires background action on event | No | Yes |
| Fixed, limited set of options | No | Yes |
| Multi-step with conditional branching | Yes | Limited |
Where Teams Go Wrong
Using Workflows to handle queries that need Procedures. A Workflow that tries to collect troubleshooting information through button trees will frustrate customers who need to describe their issue in their own words. When a query requires open-ended interaction and judgment, use a Procedure.
Using Procedures for simple routing tasks. A Procedure that identifies the customer's topic and routes them to a team is doing what a Workflow does better. Procedures carry computational overhead; reserve them for queries that actually need AI reasoning and resolution.
Building everything in Workflows because they are visual and familiar. Workflow-native teams sometimes try to approximate Procedures by building elaborate button trees for complex query types. The result is a high-maintenance structure that breaks constantly, frustrates customers who do not fit the anticipated paths, and requires engineering to maintain.
Not testing edge cases in Procedures. Workflows are deterministic: if the button tree is correct, it will always produce the correct path. Procedures rely on AI reasoning, which can behave unexpectedly on edge cases. Build Simulations for off-nominal paths before going live.
A Practical Example: Subscription Cancellation
Here is how a production implementation typically splits this query type between the two tools:
Workflow handles:
- Detecting that the conversation involves billing (using topic detection or a triage menu option)
- Routing to the retention-focused team queue
- Adding a tag to the conversation for reporting
Procedure handles:
- Confirming the customer's cancellation intent
- Pulling current subscription details from the billing system
- Branching based on plan type, renewal date, and customer tenure
- Presenting retention offers relevant to the customer's situation
- Processing the cancellation request in the billing system if the customer proceeds
- Adding a note to the conversation and routing to an account manager if cancellation involves an enterprise plan
The Workflow does the routing. The Procedure does the resolution. Neither tool is trying to do the other's job.
What to Measure
| Metric | Tool | What it tells you |
|---|---|---|
| Procedure resolution rate | Procedure | What percentage of Procedure-handled queries Fin resolves without human involvement |
| Procedure trigger accuracy | Procedure | Whether the Procedure is activating on the right query types |
| Workflow drop-off rate | Workflow | Where customers abandon a structured path before completing it |
| Routing accuracy | Workflow | Whether conversations are reaching the right teams |
| Time to resolution (automated) | Both | How long automated interactions take compared to human-handled baseline |
Frequently Asked Questions
Can a Workflow trigger a Procedure?
Not directly in the current architecture. Workflows route conversations to the AI agent, which then matches the conversation to the appropriate Procedure based on intent. The combination achieves the same effect: use the Workflow for routing, let Fin select and run the Procedure for resolution.
If a customer is mid-Procedure and asks an off-topic question, what happens?
The agent handles the question using its knowledge base and general guidance, then returns to the Procedure. If the off-topic question suggests the Procedure is not the right one for this customer, the agent can switch to a more relevant Procedure based on the updated context.
How do I know which existing Workflows to convert to Procedures?
Look for Workflows that include multiple reply-button steps with informational questions, that frequently end with a human agent taking over, or that customers frequently abandon or re-route around. These are signals that the interaction needs AI judgment, not a fixed path.
Can the same conversation use both a Workflow and a Procedure?
Yes. This is the standard architecture for complex support operations. The Workflow handles triage and routing; the Procedure handles resolution once the conversation arrives at the right team and query type.