How to Automate Complex Customer Support Queries with AI Procedures

Complex support queries, the ones that require pulling account data, applying a business rule, and making a judgment call, consume 40-60% of a typical support team's time while representing a fraction of total ticket volume. Knowledge-base deflection handles the easy stuff. What does not get automated is the hard stuff: account troubleshooting, subscription changes, refund claims, order disputes. That is where AI Procedures change the equation.

This article explains what AI Procedures are, which query types they can handle, how to build one, and what to measure once it is live. After reading it, you will have a clear framework for identifying your first Procedure use case and a step-by-step build process to follow.

What is an AI Procedure?

An AI Procedure is a multi-step workflow that instructs an AI agent how to handle a specific class of complex customer query from first contact to resolution. You write it in natural language, the same way you would document a process for a new team member, and augment it with conditional logic, code, and live system integrations where precision matters.

Unlike rigid chatbot scripts, Procedures adapt when conversations shift. If a customer asks an off-script question mid-flow, the agent reasons about what to do next rather than failing. If system data changes the right answer partway through, the Procedure branches accordingly.

Fin Procedures are the implementation of this concept inside Intercom's AI agent. Intercom reports that customers using Fin Procedures for high-volume complex use cases, including prescription refill handling at healthcare companies, subscription management at SaaS businesses, and order claims at ecommerce brands, achieve automation rates well above knowledge-base-only approaches, with some targeting 60-80% on the specific query types they cover.

Why Complex Queries Resist Simple Automation

Standard knowledge base automation works on a pattern-match logic: the customer asks something, the AI finds the best-matching article, and the conversation ends. This covers a large percentage of support volume, often 40-50%, for free-text informational queries.

Complex queries fail this pattern for three reasons:

They require live data. Answering "can I cancel and get a refund?" requires knowing the customer's current plan, payment date, and cancellation policy for that plan tier. A static knowledge base article cannot substitute for pulling that data in real time.

They require decisions, not just answers. Handling a damaged-order claim requires collecting evidence, checking order details, applying the relevant policy (which may vary by product category, order value, or customer tier), and then taking an action in the order management system. Each step depends on the last.

They require process consistency. The wrong answer on a subscription cancellation or refund claim creates real business and legal risk. Rule-based automation gives consistent outputs. AI that is only guided by instructions without deterministic controls introduces variance that support leaders cannot accept at scale.

AI Procedures address all three by combining natural language flexibility with deterministic control points.

Identifying the Right Use Case for Your First Procedure

Not every complex query is a good candidate for automation. The best first Procedures share three characteristics:

High volume and repeatable structure. At least 50-100 conversations per month, following a consistent process that your agents already know well. If there is no standard approach, the Procedure will encode inconsistency.

Available system data. The Procedure needs to read live data to make decisions. If the relevant systems have APIs your team can access, the data integration step is tractable. If data lives only in spreadsheets or email threads, start elsewhere.

Clear success criteria. You need to be able to define what a good outcome looks like before you build. For a refund claim Procedure: did the customer get a refund or a clear denial with the correct reason, within one conversation turn, without needing a human agent?

Common first-Procedure candidates across industries:

• SaaS: Subscription cancellation, plan change requests, invoice disputes, seat management
• Ecommerce: Order status, cancellation before shipment, return initiation, damaged-item claims
• Fintech: Account verification, transaction dispute triage, subscription management, chargeback intake
• Healthcare: Prescription refill requests, appointment scheduling, insurance verification
• Gaming: Account recovery, refund requests, ban appeals with evidence collection

How to Build a Fin Procedure: Step by Step

Step 1: Document the manual process first

Before opening the Procedure editor, write out the exact steps a human agent follows today. What information do they gather? What systems do they check? What decisions do they make at each point? What are the possible outcomes?

If your team does not have a written SOP for this query type, write one. A Procedure automates the process you define — it does not create the process for you.

Step 2: Define the trigger

The trigger tells the AI agent when to activate this Procedure. Write a clear description of the customer intent it should match, plus two or three examples of actual customer messages that should trigger it, and one or two that should not.

A strong trigger description for a subscription cancellation Procedure: "Use this Procedure when a customer asks to cancel their subscription, downgrade their plan, or stop being charged. Do not use this Procedure if the customer is asking about pricing for a different plan, or if they have already canceled and are asking about refund status."

Step 3: Write the instruction steps

Work through your documented SOP step by step, translating each action into a natural language instruction block. Each step should describe one coherent unit of work: what information to collect, what system to check, and what to communicate based on what is found.

Keep steps focused. A step that does five things is harder to debug than five steps that each do one thing.

Example instruction step for a subscription cancellation flow:

"Ask the customer to confirm they want to cancel their subscription. Once confirmed, check the subscription details using the Billing data connector. If the subscription renews within the next 7 days, let the customer know the exact renewal date and ask if they still want to cancel. If it renews in more than 7 days, proceed to the cancellation step."

Step 4: Add conditions and code where precision matters

At decision points where the right answer must be mathematically correct, add a Condition step. Use natural language evaluation for judgment calls ("the customer seems to be reporting a technical issue rather than a billing issue"). Use Python code for anything involving dates, numbers, or exact string matching.

Date calculation example: rather than telling Fin to "check if the order is within the return window," write a code condition that computes (current_date - order_date).days <= return_window_days using the values pulled from the order management API. The result is deterministic: there is no ambiguity.

Step 5: Set up data connectors

For each system your Procedure needs to access, configure a data connector with the relevant API endpoints. Specify what data to read (account status, order details, subscription plan), what inputs Fin should collect from the conversation versus pull from Intercom attributes, and what actions Fin can take (trigger a cancellation, issue a refund credit, update a record).

Best practice: pull only the data the Procedure actually needs. Smaller, focused API responses reduce latency and make the Procedure easier to debug.

Step 6: Define the end states

Every Procedure needs clear exit points:

• Resolved: Fin completed the workflow and confirmed the outcome with the customer
• Escalated: Fin passed the conversation to a human agent, with a note summarizing what was collected and why escalation was needed
• Unresolved: The customer's situation did not match any path in the Procedure; Fin acknowledges and routes appropriately

For escalation exits, write the handoff note explicitly. Specify what information Fin should summarize: what the customer asked, what data was retrieved, what decision point triggered the escalation, and any next steps the human agent should take.

Step 7: Run Simulations before going live

Do not publish a Procedure without running Simulations. Simulations use AI-driven test conversations — the AI acts as a customer and runs through the full flow — to validate that Fin reaches the right outcome, follows the right path, and handles edge cases correctly.

Build Simulations for at least:

• The straightforward path (everything goes as expected)
• The most common exception path (the order is not eligible, the customer pushes back)
• An interruption scenario (the customer asks an off-topic question mid-flow)
• A system error scenario (the data connector returns no data)

Save all Simulations. Rerun the full suite any time you update the Procedure.

Common Mistakes to Avoid

Building the Procedure before the process is defined. A Procedure that automates an unclear or contested process will produce inconsistent results. The ten minutes it takes to align the team on the correct SOP will save days of debugging.

Writing trigger descriptions that are too broad. A cancellation Procedure triggered by any mention of the word "cancel" will fire on conversations that are asking about Fin's cancellation policy, competitor comparisons, or completely unrelated topics. Write tight trigger descriptions with examples and counter-examples.

Using natural language conditions for decisions that need to be exact. "Check if the customer is within the return window" is ambiguous. "Compute whether today is within 30 days of the order date" using a code condition is not. Use code for anything that must produce the same result every time.

Not testing escalation paths. The escalation paths in a Procedure are as important as the resolution paths. Test that escalation triggers correctly, that the handoff note contains the right information, and that the conversation routes to the right team.

What to Measure

Frequently Asked Questions

How long does it take to build a Procedure for the first time?

A focused Procedure covering a single query type with one or two data connector integrations typically takes a few hours to draft, half a day to test with Simulations, and a day of iteration before it is ready to go live. Complex Procedures with multiple branches and several system integrations take longer, but the natural language editor means no engineering resources are required.

Can I build a Procedure without API access to my backend systems?

You can build and test a Procedure using mock data connectors that simulate API responses before your real integrations are ready. This lets you validate the logic and conversation flow while the API work is in progress.

What happens when a Procedure gets triggered on the wrong query?

If Fin starts a Procedure and then determines mid-conversation that the customer's query does not match, it can switch to a different Procedure or exit and let Fin handle the conversation normally. The key is investing time in the trigger description upfront to reduce false positives.

How do I update a Procedure that is already live?

Edit the Procedure in the editor, then rerun your saved Simulations before republishing. The Simulations catch any regressions caused by the update. Publish only after the Simulations pass.