Planning workflows for automation

Plans and permissions:

• Add-on: AI agents, billed separately
• Build a workflow from your plan: Admin, Manager, or Team Lead role, or a custom role with Workflows set to Can create, edit, and delete workflows

Use this guide to decide which support processes to automate with workflows, and to write each one down before you build it. A process that’s clearly documented, with its triggers, decisions, and outcomes, turns into a workflow that selects the right cases and handles them consistently.

If you already have step-by-step standard operating procedures (SOPs) that include decision criteria, the systems involved, and every possible outcome, you can go straight to Building workflows.

What makes a process ready for automation

A workflow combines decision logic with AI to handle one kind of request. It works best for processes that are:

• Repeatable: they follow the same pattern each time.
• Linear: they move step by step toward a result.
• Actionable: they end in a specific outcome, such as a reply, a refund, or an update to the case.

If the right answer varies a lot from case to case, the workflow needs more condition branches, or the process may not be ready to automate yet.

Choose what to automate first

Look at your case data to find high-volume, consistent requests, rather than edge cases.

• Start with your top two or three case categories by volume. They give you the biggest return first.
• Check that the resolution is predictable. You should be able to say in plain language what should happen when a customer asks for X.
• Reuse what your team already has. An SOP or a set of macros for a request type is the foundation of its workflow.
• Look for patterns in recent cases. Export cases from the last 7–30 days from your help desk and look for common phrases, keywords, and the cases that should and shouldn’t count. Some teams use an AI tool to help find these patterns.

Good first workflows usually have high volume and low complexity, a consistent resolution, existing documentation, and a reply that can be largely the same each time. Common examples:

• Return and refund requests
• Cancellations
• Account access and password resets
• Shipping and delivery questions
• Pricing and discount questions
• Basic troubleshooting

Processes that take your support team a long time, or that are already handled with templates or macros, are also good candidates.

Document each process

For each process, write down the following. Describe it the way you’d explain it to a new team member.

Trigger conditions

• What kinds of customer requests start this process?
• Which words or phrases show that it’s needed?
• Does it apply only to certain customers or situations?

These answers become the workflow’s selection criteria.

Information and systems

• What customer details are needed, such as an order number, account email, or date?
• Which systems does a support team member use, such as your CRM, order management, or billing system?
• What permissions or access does the process need?

These answers tell you which lookups, API connections, and questions to the customer the workflow needs.

Steps and decisions

• What does the support team member do first?
• How do they decide what to do next?
• What are the decision points, and what are the exact criteria at each one?
• What happens on each branch?

Outcomes

• What are all the possible results?
• What does the customer receive for each one?
• Is anything needed afterward, such as a follow-up or an update to the case?

Write clear documentation

• Structure it. Use headings, short paragraphs, steps in order, and bullet points for lists and criteria.
• Be precise. Use plain language, define abbreviations, and be specific about timing, amounts, and criteria. Avoid words such as “usually” or “sometimes”.
• State the decision logic. Write each “if this, then that” condition, give the exact criteria for every decision, and include exceptions and edge cases, so every path through the process is covered.

Example: password reset

What triggers it: the customer can’t log in, has forgotten their password, needs to reset it, or can’t access their account because of a login problem.

Steps:

1. Ask: “What email address is associated with your account?”
2. Search the customer database for that email.
3. Decide whether the email is found:
   • If it is: send a password reset link from the customer’s profile.
   • If it isn’t: explain that there’s no account with that email, and offer to help create one.

What the customer receives:

Account found:

I’ve sent a password reset link to [email]. Check your inbox and spam folder. The link expires in 24 hours. Let me know if you don’t receive it.

No account found:

I don’t see an account with that email address. Would you like help creating a new account, or might you have used a different email?

In a workflow, the question becomes a Collect information step, the search becomes a lookup, the decision becomes a Condition step, and each outcome becomes a reply.

Map complex processes

For processes with several decision points, a visual makes the logic easier to check and to build.

Decision trees

Map each yes-or-no decision and the action that follows it.

Process tables

List each situation with its action and outcome.

Decide how many workflows you need

• One workflow when the customer’s intent is the same but the outcome depends on the details. For example, all return requests follow one process, with different replies depending on the order’s age.
• Separate workflows when the intents are different. For example, returns, cancellations, and account access each get their own workflow.

Common workflow patterns