When customers contact you, they do it because they need help or information. Something could have gone wrong, a package wasn’t delivered, and they need help. Or they want to know your opening hours, they aren’t happy with a product and want a refund, or they need to change their booking.
Wherever their question falls on the value-spectrum, it’s up to your customer care team to resolve those questions.

In previous articles in this series I’ve written about designing resolution paths to make sure the right type of question is picked up by the right tool. I’ve written about knowledge as a first way to answer questions and provide customers with guidance.

But not every question is answerable with just knowledge. Sometimes we need to do things. Or we need to make decisions. And that’s where procedures come into play. Procedures are the second pillar that define a good AI-powered CX approach, alongside to knowledge, data and insights.

Procedures are key

Before we dive into the practical elements, let’s start with defining some key definitions:

• Intent: the reason why a customer contacts you. E.g. “I want to get a refund”
• Use case: a specific scenario you want to handle. E.g. “Refund handling”
• Procedure: the logical steps to take to handle and resolve a specific use case or intent. (E.g. ask for order number, validate refund options, execute a refund).
• Actions: specific actions to be done by AI agents, human agents or the platform. (E.g. cancel an order in the CRM)

So for any given customer question, you should decide how you want to handle that given question.

Some of them are "easy". If their question is answerable a standard answer, turn it into a support article.

But for other questions, you’ll probably want to do something, or the answer is unique for a customers' context. You want to validate the question, change the booking, cancel the order, repair the device. This is where you need to decide what are the steps you need to take to go from question to resolution. You need to define the logical steps, or in other words the process, that handles such a question.

Before we even look at implementing that process into AI Agents or Agent Copilot we first need to define the overall process. Look at the use case as a whole and really define it. Break that process into its logical steps and turn it into a procedure.

Chances are that for most use cases your process is already written down somewhere. It’s part of an internal support article. It’s an internal note on a macro. It’s written down in your employee guidebook. Or.. it lives inside your agents’ heads and has never been written down.

By writing down the process you’ll start discussions. There might be subtle variants on how you handle specific use cases. Before you even start thinking about implementing these processes in Zendesk, it’s important to resolve these inconsistencies and define a common approach for your team.

It’s only once you write down the process that you can start thinking about automation. If you know your processes, you can detect bottlenecks, repetitive actions or elements you can automate:

• If a human can do it, it’s worth looking into if AI can do it faster or better.
• If it’s too repetitive but the decision flow is defined, AI and actions can be used to automate it.

This is where we can start turning process into procedure and start implementing it into Zendesk’s product.

Available automation options in Zendesk

Within Zendesk there are four ways we can handle any inquiry:

1. AI Agents - fully automated resolutions that use procedures and knowledge to guide a customer towards a solution.
2. Agent Copilot - an assistant that helps human agents to handle tickets by guiding them through procedures by offering suggested replies, offering logical actions and show instructions.
3. Action Workflows - predetermined logical flows and API calls that use required input to call external systems to do something and provide a required output.
4. Knowledge - for all scenarios where we don’t have predefined logic but just need to provide an answer.

If we map these to our use cases, we can see that some questions might be fully handled by an AI Agent. They provide knowledge answers or follow procedures, which might execute specific workflows.
Other questions are escalated to human agents, where some might be resolved with the help of Agent Copilot, while others might be fully handled by humans.
These last ones are prime candidates for future automation efforts.

If we take a look at our previous example, this might turn our process into something that looks like this:

Checking for an order status is a matter of getting the status from the CRM via API and telling the customer that status. In most scenarios that can be done without any problems, so it's a perfect candidate for a fully automated flow.

Similarly, we can write a procedure for our human agents to follow within Agent Copilot. This procedure is applicable when we can’t provide a status via the API and need an escalation, but it can also be used when a customer asks about their order status in the middle of an already escalated conversation.

As you can see, both the AI Agent side and the human side contain a lot of the same logic. But since we can pass information between the AI Agent and human side of the conversation upon escalation, Agent Copilot can skip certain steps and jump right and fast forward to where its procedure becomes relevant.

If we combine both flows we get a flow that looks like this:

So handling complex workflows and logical decisions within Zendesk means you need to think about two things:

1. You need to define your process and define the logical steps to take to resolve a question.
2. You need to map these steps against AI Agents, human agents assisted by Agent Copilot, or workflows and actions that call external tools.

Procedures across agents

You might wonder why we’ve written two procedures for what’s basically a single use case.

To be honest, one reason is a current design choice in Zendesk. AI Agents and Agent Copilot can’t reference the same procedure. This forces us to write (part of) a procedure twice. Once for a fully automatable procedure that’s handled by our AI Agents, and again for Agent Copilot to assist our human agents.

In an ideal world, both tools would refer to the same procedure, and AI Agents would handle the entire conversation up to an escalation step, and Agent Copilot would pickup from there.

And while that should be a future aspiration of the platform, this isn’t possible today, so we’re left with the best next thing: two procedures that each take care of part of an entire process, with overlapping logic for when we expect both to handle the same steps.

Some might argue it's better to only write the entire procedure once on the Agent Copilot side. Since human agents are needed for exception cases anyhow, having the entire order status logic live on the human agent side means we only need to write a single procedure, ignoring our AI Agent.
In all cases where we can retrieve an order status, it’s a matter of lookup, send answer and solve the ticket. And where we get an exception, human agents need to take additional steps.

But that would mean every time a customer asks for an order status update, that question would end up as an actionable ticket for your human agents. Even those where we can retrieve the status, tell the customer and move on.
Moving the procedure towards AI Agents really makes sense here. The AI Agent can take care of all the easy scenarios, leaving only a small subset of complex cases for the human agent to handle.

Or if we refer back to our starting definitions:

If a human can do it, it’s worth looking into if AI can do it faster or better. If it’s too repetitive but the decision flow is defined, AI can be used to automate it.

Surely a human agent can look up the status in the order system. But it’s faster to have Agent Copilot lookup the order and suggest a reply for the agent to approve.
And even better, having an AI Agent automatically reply to all customers for all known statuses is way more efficient.

So while writing our procedure twice might seem a lot of work, in the end it will mean you get the chance to automate as many conversations as possible, while also making sure that if agents get tickets with those some questions, they can handle those faster too.

But each use case and intent is different. So for some it might make sense to put all the logic on the AI Agent side, leaving your human team with the unique steps they handle. And for other use case duplicating the logic across both solutions is the more practical approach.

Mapping use cases to an AI Agent or Agent Copilot

Let's take some practical examples to see how that mapping might work. In this table we've got a list of customer questions, and for each we show how the overall procedure would look, what info we need, and what kind of solution we might use.

Now that we’ve defined what procedures are and how they can interact across the different AI tools Zendesk offers, let’s dive into the actual product and see how we can set them up.

AI Agent Procedures

Zendesk currently offers two AI Agents. AI Agent Essentials, which only handles generative replies based on knowledge, and AI Agent Advanced which handles both generative knowledge responses, as well as procedural use cases.

When a customer asks a question, the AI Agent will try to map that question to a use case. If it can’t find one, it’ll try to find a knowledge answer, and if that fails it’ll fall back to a default reply.

That default reply could be a “please rephrase your question”, “a list of common questions” or an escalation option.

If it can map the question to a use case, it starts the dialogue flow or agentic procedure that’s linked to that use case. For the scope of this article, we'll be focussing on this scenario.

Use Case

The first step in handling a specific use case, is creating one in the AI Agent Advanced dashboard.

Each use case has a name and a customer request reason. The name is a way for you to recognise the intent in reporting. The request reason describes when the use case is relevant, and is used by the AI Agent to match a customers' question to the right use case.

Before the arrival of LLMs, this use case have been a long list of training phrases like “Where is my order”, “What’s my order status”, “When does my order arrive?”. But thanks to modern LLMs, we can now just describe the scenario, and the LLM will map a customer question to a matching use case, no training required.

In our example, that use case would be defined as:

A customer wants to check the status of their existing order.

Confusion

Use case definitions are often a set once and forget, although you need to be careful about overlapping or confusing reasons. e.g.:

• Modify Order: Use this when the customer wants to change details of an existing order they just placed.
• Update Shipping Address: Use this when a customer provides a new delivery address for an order.

"Update Shipping Address" is a subset of "Modify Order." meaning the system won’t always map a customer inquiry to the right use case, and you’ll get an alert in the Admin Dashboard when setting up these flows. Solutions might be to specifically exclude “address” in the modify order use case description, or merge them as one, more complex, use case and procedure.

And while merging them will remove the confusion, in general it's still a best practice to adhere to the "1 use case, 1 process rule" and not overload a single use case with tons of sub-routines. E.g. Use case Order with a first step asking the customer if they want to modify, cancel, track or reorder is a bad idea. It's better to create a use case for each of those four options. It makes each procedure shorter and it allows for better reporting per use case, making it easier to improve them over time.

Resources

Once we’ve got our use case defined, we can start thinking about implementing a procedure linked to that use case.

But before we dive into writing the procedure itself, there’s a few bits we need to set up first.

If we look at our order status example from before, you’ll notice that we need to lookup a status in the CRM system. And while actions and data are part of the next article in this series, we kinda need them configured before we can move on.

API Integration

Within AI Agent Advanced, any external data retrieval is setup as an API integration.

In our example we need to call [POST] /orders , with a payload of:

{
  "order_number": 42,
  "email": "[email protected]"
}

This either works, and we get our order_status:

{
  "statusCode": 200,
  "data": {
    "order_status": "confirmed",
    "order_id": "ORD42",
    "order_date": "June 7h 2023",
    "items": [
      {
        "name": "Jurassic Park Adventure",
        "type": "attraction",
        "ticket_type": "2-Day Park Hopper",
        "ticket_price": 200,
        "quantity": 3
      },
      {
        "name": "Jurassic Park's Grand Hotel & Spa",
        "type": "hotel",
        "room_type": "Premium View Room",
        "room_price": 450,
        "nights": 4
      }
    ]
  }
}

Or we get an error when the users' info doesn't match:

{
  "status": "error",
  "code": "ORDER_NOT_FOUND",
  "message": "No order was found matching the provided email and order number combination."}

Or we get an error when we can'tretrieve an order_status:

{
  "status": "fail",
  "code": "INTERNAL_SYSTEM_ERROR",
  "message": "An unexpected error occurred while retrieving order details.",
}

One of the issues that can occur when deploying or testing new procedures is that the actual API endpoint is not available when you start building out your AI Agent. One workaround for this is creating a placeholder API integration that behaves like the real one. That way you can write your procedure, have it call a fake API that returns a random order status, and validate the entire procedure without waiting for your real API endpoints.

Once the endpoints are available, you just need to update the API integration, and you can keep your procedure as is.

For example, I build myself a small placeholder API to use in procedures until the real APIs are available.

Internal Note Mock API

This worker exposes a small mock API for testing clients. Responses are simple JSON objects that are easy to inspect and assert against.

Knowledge

Similarly, if we want to provide the customer with information on how to retrieve an order status themselves, we need to make sure we have an article indexed that contains that information.

Procedure (or Dialogue flow)

AI Agent Advanced has two types of procedures. We have the classic Dialogue Builder which uses a rigid deterministic flowchart to define a process. And we have the new agentic procedures which aren't as fixed, but give the AI Agent a compass and boundaries. It still has to follow the logic, but can skip steps, rerun logic and dynamically adapt to the customer, while staying within the permitted process.

And while the dialogue flows still have their uses, agentic procedures are easier to build, and are the preferred way to create procedures nowadays.

Easier?

• Since they are fully text based, adding or modifying logic is a matter of changing words.
• Since they are fully text based, what you read is what you get, you don’t need to be able to read a flow chart and understand the technical setup of AI Agents.
• Conditionals and fallbacks, logical loops and other inherent flowchart elements are easier to modify. You can describe your logic and the system will “build” the chart for you, making it more descriptive than something that's mostly driven by technical expertise.

What’s really nice is that the new procedures bring the AI Agent setup closer to the people that actually know and manage the process. While prompting and writing good procedures still requires some knowhow and experience with the platform, the adoption threshold is way lower than learning how to build dialogue flows. In most scenarios, writing down your process brings you most of the way of writing a good procedure.

Additionally, tweaking the process later to account for new scenarios is a matter of just writing down what’s changed or moving elements around. If you want to move the order number validation step from the end of a flow all the way to the start, doing it in text is fast, just tell the AI Agent to do so. Doing that in a dialogue builder flow means: rebuilding it from scratch and a lot of complexity moving steps around.

How do AI Agent procedures work

Agentic procedures are basically guidelines for your AI Agent to follow in order. But they have the benefit that your AI Agent has the liberty to adapt the flow to fit the conversation.

For example, your procedure starts with “ask the customer for their order number”.

When a customer asks:

Customer: where is my order?
AI agent: In order to lookup your order status, I need your order number.

However, if the customer starts with:

Customer: What’s the status of order 42?
AI agent: Order 42 has shipped and should arrive tomorrow.

The AI Agent immediately moves towards the next step in the procedure since it recognises the customers already provided an order number. This might seem like a small thing, but in flows where the customer needs to provide multiple elements, every step the customer doesn't need to take, removes a lot of conversational noise for the customer. It also makes the AI Agent behave more human and less robotic for the customer.

Similarly, the AI Agent can rerun and modify logic throughout the procedure. E.g. a customer provides their preferred destination, departure date, seating preference and adds additional luggage when booking a flight via an AI Agent. Halfway throughout the process the customer interrupts the AI Agent and says “you know what, make it a window seat!”.

Where a rigid dialogue builder would rerun all logic, an AI Agent powered with Agentic Procedures will just modify the seating preference, and move back to the most logical point in the flow, without re-asking all other questions.

That liberty, or agency, does not mean the AI Agent can derail and start improvising. Any decision or interaction is still based on the process you defined (the guardrails), it’s just the conversational flow that can me more dynamic, adaptive and dare I say.. human?

Setting up an AI Agent procedure

Setting up a procedure in AI Agent Advanced is very similar of how you would build an app with App Builder.

On the left side is a conversation pane where you can tell the system how your procedure runs. The right side shows a rendered flowchart of the procedure. While this looks like to the one you’d build with the classic dialogue builder, it’s actually just a representation of how the system understands your procedure. As discussed earlier, the AI Agent can dynamically use this logic and build a conversation around it, skipping or repeating elements in the flow until the use case is resolved.

When building your procedure you can either write the entire logic in one go, or you can write-submit-update the procedure section by section, building it up as you go.

Especially for complex procedures I prefer to first draft an outline of the steps needed, and then start building them one by one, referencing API Actions, parameters or knowledge answers as I need them.

Another important element to take into account when writing your procedure is that you should close all hooks. This means that once you’ve written your procedure you should make sure that for any branch you make in your logic there’s a logical end point. Either a resolution, loopback, or escalation. This way your customer don’t reach unhelpful endpoints.

When you first build your procedures, chances are big that most of your branches will end in escalation, with only the obvious, predictable and less complex ones reaching a resolution in the AI Agent flow itself.
As you gain experience and you start finding regular patterns in the escalated conversations, you can come back to your procedure and start handling those scenarios within the AI Agent too. E.g. a lost package can be reordered from within the AI Agent conversation in certain scenarios. Or you could add a list of recent orders for an authenticated user, skipping the order number step. This removes all the escalations of customers that don’t know their order number.

This feedback loop of identifying bottlenecks, understanding when and how they occur, fixing them in the process by either modifying the flow or building out new automations is core. It's only by monitoring what your AI Agents are doing and using that data to improve, that you'll go from low automation rates all the way to 60-80%.

Agent Copilot Procedures

Where AI Agent procedures are all about automating the conversation and resolving the conversation before it reaches your human agents, Agent Copilot lives on the escalation side of the interaction. Its procedures are there not to replace your team, but to help them.

How do Agent Copilot procedures work?

Agent Copilot has an auto-assist mode. This means that Agent Copilot lives alongside your ticket conversations and continuously tries to suggest agents the next best steps to take.

These can be comments in the form of suggested replies:

• Asking the customer for required information.
• A comment generated by the next step in a procedure.
• A comment based on a knowledge source.
• Informing the customer on actions taken.

These can be automated actions done by the system, to be confirmed by the human agent before they run:

• Actions that Agent Copilot should take on the ticket (e.g change status, update ticket fields e.a.)
• Running a specific macro
• External API actions to be executed by Agent Copilot like updating data, submitting changes e.a
• Launching specific Action Builder workflows

Instructions

While the goal of Agent Copilot is to provide as much automated assistance as possible for the agent to confirm, some actions can not be done by the system. Physical actions like sending a package or printing and posting an invoice. Actions to be done in systems that don’t have an API (yet). Phone calls an agent should make. Or build-in delays like “confirm a package is returned before moving forward”.

Agent Copilot can’t do these steps, but it can show instructions to the human agent to complete. This has two benefits. On one side this means your Agent Copilot procedure contains the entire process. There’s no other manual or guideline for your team to reference and the entire use case is handled or suggested by Agent Copilot.

Secondly, these instructions are a great placeholder for future development work. Instead of waiting for that “Update order” API integration, you can write the entire procedure with manual agent instructions. The agent can go to your order system, update the order and confirm. Agent Copilot can then move forward in the process. If and when you decide to build an actual API you can replace the instruction step with an API action or Action Builder flow.

Macros

One capability of Agent Copilot’s procedures that kinda baffled me when it came out was macro support. I kinda consider them static remnants of an older Zendesk, the one that relies on views, triggers and tickets. Not the new Zendesk that runs on omnichannel routing, actions and conversations.

But from a reusability standpoint, having access to macros within procedures is actually kinda nice. Instead of repeating the same ticket steps (update fields, add internal comment, change status) across multiple similar procedures, we can use a single macro that gets reused across all of them. It’s ideal for scenarios where you want to flag tickets for review, apply reassignment logic, or store the same customer context against the ticket. Macro updates also happen all at once, whereas ticket actions in tickets have to be approved and run one by one.

However, I would still recommend moving as much of the comment blocks out of your macros and move them directly into a procedure. It allows for replies that are written specific to the customer with slight variations in each response, without the need for complex placeholder logic.

Setting up an Agent Copilot procedure

Writing procedures for Agent Copilot is similar to writing articles for your Help Center. It lives in the same Help Center Admin Center, and the editor has the same features, layout and experience as article do, minus the AI capabilities like expand or simplify.

While this makes it easier to read and reference an entire procedure as if it were an internal guidebook, it lacks the flowchart preview that its AI Agent counterpart offers, making it a bit more complex to grasp the entire logic at a glance.

Custom Action

Similar to our AI Agent procedure we need to be able to retrieve the order status via API. This is done by setting up a custom action in Admin Center.

This requires the same input order_number and customer_email, and calls an identical API endpoint, returning that same order_status or error code.
The main difference between the two is basically the UI. Where AI Agent integrations live within their dashboard (for now), Agent Copilot is tightly integrated in the Zendesk Admin Center, leveraging the same custom actions that Action Builder uses.

Writing an Agent Copilot procedure

A procedure writes itself as a single document that contains all the logic of our process in logical steps. Here too, it’s important to write specific logical flows, and make sure to close out all open hooks in your logic.

Since some of your API integrations might not be available on day one, you can either resort to a placeholder Custom Action, or in case development is not planned yet, you can add instructions for manual steps to be taken by your team. These, as noted earlier, give the benefit of guidance to your team, while removing the complexity of creating full API integration for every step.

As your procedure evolves, and as metrics come in, you can then take manual instruction steps and replace them with API actions when applicable.

Measuring impact

Both AI Agent Advanced as well as Agent Copilot procedures have built in versioning. This way you can keep track of changes overtime, and revert back to a prior version when issues occur, or when the automation rates of a procedure drop.

Agent Copilot has a nice built-in performance dashboard on top of its versioning capabilities. This shows how each version performs. You can see how many tickets it ran against, how many times its steps are suggested, and how many suggestions are edited by your team before submitting them.

Agent Experience

Since Agent Copilot lives and works alongside your team, it’s not only important to focus on the editing experience to create procedures, but also on the way your team interacts with them on a daily basis.

Generally, the auto-assist suggestions from Agent Copilot replace the classic comment field in a ticket view. Agents get a suggested comment, and a set of suggested next actions listed, based on the current conversation and customer reaction.

An agent can decide to approve the suggestions, which will send the comment to the customer, and run all actions, updating ticket fields, making API calls e.a.

They can also choose to edit the suggestions. They can remove some actions, or edit the suggested reply, and then submit the updates on the ticket. It’s these edits, or approvals, that show up in the version performance dashboard that shows up when editing a procedure.

While agents can approve a comment blindly, auto-assist does offer a way to see why the suggestions where made. It shows the reasoning, the used procedure, or referenced knowledge sources, making it clear to the agent why this comment is the right one.

At any time an agent can also leave feedback about the suggested comment. They can tag it as a wrong reply, bad tone, or leave a specific comment. This data feeds back to Zendesk, giving it the right data to improve the quality and accuracy of these suggestions.

The auto-assist comments aren’t the only interaction point for agents though. Copilot offers summaries, intent detection, sentiment, entities, and suggested knowledge articles in the sidebar.
Additionally, if your procedures contains them, there’s the instructions that appear in the context panel, giving the agent a view on steps to take before the Agent Copilot resumes its logic.

What’s next

Within our Resolution Platform, we’ve got knowledge, procedures, data and insights as the four big pillars. Procedures drive your automation by turning your processes into reusable elements that remove manual actions for agents, guide customers throughout decision processes and interact and connect with the other tools in your platform.

For now, fully autonomous procedures for AI Agents, and assistive suggestions via Copilot live separately on each side of the escalation wall, with each its own logic and actions. As the platform evolves and the different acquired technologies integrate tighter with the core platform, we’ll probably see these similar features merge closer too.

I do expect API integrations for AI Agents to be replaced by the Custom Actions in Admin Center. Similarly, Action Builder should be leveraged more. It can take reusable complex decision flows out of the procedures, and wrap them within one workflow which gets called from the procedure.

But my holy grail is a unified procedure builder that starts with the customer and ends in resolutions, dynamically pushing elements in the procedure to either an autonomous AI Agent, or towards human agents depending on the context. This would give your team and admins a full view of how an entire use case is handled, removes overlapping logic and allows for deeper insight in bottlenecks and optimisation options. It's not there today, but I hope it'll be here someday.

But while the future will always be brighter, what we have today serves as a very solid basis to turn manual steps into structured automation.

If I can leave you with one piece of advice, it’s this: start simple and build your processes one efficiency gain at a time. If you aim for a perfect, complex procedure on day one, you’ll be chasing a moving goalpost you’ll never quite reach. Instead, focus on small wins; each incremental improvement provides a concrete, measurable benefit the moment it goes live.

So that’s procedures. Next time we’ll dive into Data. Custom Actions, workflows, Action Builder.