The When/If/Then Framework for AI Customer Support Workflows

The single biggest reason support automation rules fail in production isn't the AI, it's how the rules are written. Vague rules produce vague behavior. The When/If/Then pattern is a forcing function for specificity, and Ensoras's plain-English workflows are designed around it.

The pattern aligns closely with how the model providers themselves describe building reliable LLM agents. Anthropic's Building effective agents and OpenAI's function calling documentation both reach the same conclusion: predictable agent behavior comes from explicit, structured triggers and bounded actions, not from open-ended prompting. The When/If/Then format is the operational version of that engineering discipline — and the format Ensoras converts directly into working workflows without you touching JSON or a flowchart editor.

If you've struggled with workflow rules that work in testing but fall apart with real tickets, this is the format that fixes it.

The pattern

A workflow rule has four parts:

When [trigger event] / If [conditions are met] / Then [take this action] / Else [escalate or fall back]

Read it out loud. If any of the four parts is fuzzy, the rule will produce fuzzy results.

Why each part matters

When (the trigger)

The trigger is the inbound event that activates the rule. It should be specific enough that you'd recognize it on a real ticket.

• ✅ Good: "When a customer asks where their order is"
• ✅ Good: "When a customer requests a refund"
• ❌ Bad: "When the AI is unsure" (too vague, what AI does is the rule's job)
• ❌ Bad: "When a customer is frustrated" (too vague, define how to detect frustration)

The intent classifier handles the matching. Your job is to define the intents clearly.

If (the conditions)

Conditions are the data that determines whether the action is appropriate. Be specific. Use AND/OR explicitly.

• ✅ Good: "If the order is unshipped AND placed inside our refund window"
• ✅ Good: "If the customer is flagged VIP OR has lifetime spend over $1,000"
• ❌ Bad: "If it's reasonable" (whose definition?)
• ❌ Bad: "If the customer is unhappy" (you'd need a sentiment threshold)

Each condition should be something the AI can actually check, a data field, a flag, a computed value. If you find yourself writing conditions the AI can't verify, the rule won't work.

Then (the action)

The action is what happens when the conditions are met. Be explicit about every system change.

• ✅ Good: "Process a full refund to the original payment method, send the customer a confirmation email, tag the ticket 'auto-refund-within-policy'"
• ✅ Good: "Generate a return label, attach it to the reply, update the order status to 'return-initiated'"
• ❌ Bad: "Handle the refund" (what does that mean?)
• ❌ Bad: "Apologize and resolve" (how?)

Multiple actions in a single Then are fine, list them all explicitly. The AI executes them in order.

Else (the fallback)

The Else is what happens when conditions aren't met. This is non-negotiable. Without it, the AI is guessing.

• ✅ Good: "Else escalate to a human with a recommendation to refund as goodwill"
• ✅ Good: "Else ask the customer to provide their order number"
• ✅ Good: "Else tag the ticket 'refund-outside-policy' and queue for manual review"
• ❌ Bad: "Else do nothing" (the customer is left hanging)
• ❌ Bad: (omitted) (the AI improvises)

Always have an Else. Always.

Real examples for ecommerce

These are production-grade rules, written for clarity and execution.

WISMO (where is my order?)

When a customer asks for order status (e.g., "where's my order", "shipping update", "tracking info")

If the customer's most recent order has a tracking number AND it's in transit or delivered

Then reply with the carrier name, tracking link, last-known status, and estimated delivery; tag the ticket "wismo-resolved"

Else ask for the order number if not provided, OR escalate to a human if the order shows no tracking after the standard processing window

Refund within policy

When a customer requests a refund

If the order was placed inside our refund window AND no items have shipped AND the order total is under $200 AND the customer has fewer than 3 recent refunds

Then process the refund to the original payment method, send confirmation, tag "auto-refund-within-policy", note the timestamp and trigger

Else escalate to a human with the customer's order details, refund history, and a recommended action (approve / partial / decline with goodwill offer)

Subscription pause

When a subscriber asks to pause their subscription

If the subscription is active AND has no recent failed payments AND the next billing cycle is far enough away to apply the change cleanly

Then pause until the date the customer requested (or your default pause length if no date), update the subscription via Stripe or Recharge, send confirmation

Else if the next bill is imminent, ask if they want to skip this cycle or pause after the next charge; if there's a payment failure, escalate to a human to investigate

Return initiation

When a customer wants to return an item

If the order was placed inside our return window AND items have shipped AND the customer specifies which item to return

Then generate a prepaid return label via the warehouse API, email it to the customer, update the order status to "return-pending", set expected refund amount based on item price

Else if the return window has expired, explain the policy and offer store credit if eligible; if items haven't shipped, treat as cancellation; if the customer hasn't specified items, ask which items

Address change

When a customer asks to change the shipping address on a recent order

If the order has not yet been picked up by the carrier (status is "processing" or "pending fulfillment")

Then update the address in Shopify, confirm the new address with the customer, tag "address-updated"

Else if the order has shipped, explain that the address can't be changed and offer to help with carrier-side reroute; escalate if the customer pushes back

Common mistakes (and how to spot them)

Mistake 1: Conditions that aren't actually checkable

You wrote: "If the customer seems reasonable." The AI can't check that. Replace with: "If the customer's tone is neutral (sentiment > 0.3 on the standard scale)."

Mistake 2: Multi-part Then with no order

You wrote: "Then process the refund and send the email." Fine, but in what order? If the email fails, did the refund happen? Make it explicit: "Then 1) process refund, 2) send confirmation, 3) tag ticket. If step 1 fails, escalate before step 2."

Mistake 3: Else that defaults to "do nothing"

You wrote: "Else don't take action." The customer is left hanging. Replace with an explicit fallback: "Else send the customer a message acknowledging the request and tag for human follow-up."

Mistake 4: Rules that depend on context the AI doesn't have

You wrote: "If this is a regular customer." What's "regular"? Number of orders? Lifetime value? Frequency? Replace with: "If the customer has placed 3 or more orders OR has lifetime value over $300."

Mistake 5: Rules that contradict each other

You have two rules: "Refund all returns within our refund window" and "Don't refund items damaged in transit." If a customer returns a damaged item inside the window, what wins? Make the priority explicit. Ensoras workflows have a Priority field; the highest-priority matching workflow wins.

Layering rules

Most categories need a few rules at different priority levels:

Priority 1 (highest): Hard escalations, VIP customers, legal language, fraud signals, dollar threshold breaches. These always escalate, regardless of what other rules say.

Priority 2: Specific exceptions, "If customer has lifetime spend over $1,000, refund outside our standard window automatically."

Priority 3 (default): The general policy rule, "Refund within our refund window, unshipped, etc."

When a ticket comes in, the highest-priority matching rule wins. This lets you handle exceptions cleanly without breaking the general logic.

How to test rules before going live

Before turning on autonomous mode for a category:

1. Pull 100 recent tickets in that category.
2. Run them through the rule on paper. For each ticket, write down: would the rule match? What action would it take? Does that match what your team did in reality?
3. Categorize the misses. Tickets where the rule would have done something different from what your team did. Are these:
   • Cases where the AI would actually be right (your team made an exception that wasn't policy-aligned)?
   • Cases where the rule is too aggressive (need to add conditions)?
   • Cases where the rule is too cautious (need to remove conditions)?
4. Iterate. Update the rule. Run again on the same 100 tickets.
5. Don't go live until <5 honest misses out of 100.

It's optional but useful. Ensoras's audit trail also gives you the same visibility on real tickets — you see which workflow matched, which tools ran, and what the AI returned, so you can iterate quickly on rules even after going live.

Why this framework works

The When/If/Then format does three things rule-based automation needs:

1. Forces specificity. Vague terms get exposed when you try to write them in this structure.
2. Maps cleanly to AI execution. Ensoras converts this format directly into the underlying logic without translation loss — no JSON, no visual flowchart editor, no abstraction tax.
3. Is auditable by anyone. A rule written this way can be reviewed by your operations lead, legal, finance, or a new hire — they don't need to know the platform's internals. Ensoras's audit trail then logs every workflow match, every tool call, and every AI decision against the rule, so the loop closes.

A common pattern when teams refactor existing automation: a sprawling set of flowchart-style workflows compresses into a small set of well-written When/If/Then rules in Ensoras. Less complexity, better coverage, faster iteration.

The rule of thumb

If a rule can't be read out loud and understood by someone who's never seen your platform, it won't survive production. That's the whole framework in one sentence. Everything above is just how to get rules to that bar.

What to do next

1. Install Ensoras free — Shopify App Store, WordPress plugin, or direct sign-up. 10 minutes. 30 tickets/month free, no credit card.
2. Open Automation > Workflows and write your first When/If/Then rule using the pattern above.
3. Save and watch the audit trail confirm the workflow matched and the right tools ran.

For a worked example of these rules running in production, see the refund automation walkthrough for Shopify and Stripe. Every step of that post is a When/If/Then rule. And if you've struggled to get rule-based automation working elsewhere, the 7 reasons customer support automation stalls post covers the rule-design failures specifically (#3 and #6).

Sources

• Anthropic, Building effective agents, model-provider research on structured triggers, bounded actions, and predictable LLM agent behavior. The When/If/Then pattern is the operations layer of these engineering principles.
• OpenAI, Function calling documentation, model-provider documentation on tool definitions, parameter schemas, and reliable execution patterns for LLM agents.