Creating generative procedures

You describe the case in free text and Zendesk generates the procedure and a map of it. It hangs off a use case rather than standing alone.

A generative procedure shapes how an AI agent handles a case, as an alternative to a scripted dialogue. Two things set it apart from a scripted dialogue: you describe the case in free text and Zendesk generates the procedure and a map of it, and the procedure hangs off a use case rather than standing on its own.

Create one

1. In the AI agents workspace, select your AI agent, click Content in the sidebar and select Use cases.
2. Click the use case this procedure is for.
3. Under Reply method, make sure Use procedure when use case is triggered is selected.
4. On the Procedure tab, click Create procedure.
5. Describe in free text how the agent should solve the issue, then click Generate procedure.
6. Adjust through the same free-text field and click Update procedure.
7. Click Publish procedure.

Client admins and client editors can do this. What you get back is a procedure map showing the logic the agent will follow, which is where you check whether it understood you.

The map opens with four steps, and that is not a ceiling. There is no limit on how many steps a generative procedure may have: describe the next part in the same free-text field, click Update procedure, and the map is redrawn. Repeat until the case is covered. The first map looks finished, which is what makes four read as a limit.

You are writing a brief, not steps

Because the map is generated from your description, the description is the artefact that matters. Write it as you would explain the case to a new colleague, including the things that seem obvious, because the agent has no context beyond what you write.

Be explicit about order and conditions

"Check the order status first. If it has shipped, give the tracking link. If it has not, tell them the expected date." Sequence and conditions carry the logic, and vagueness here is what produces confident wrong behaviour.

Say what not to do

No promises about delivery dates you cannot verify, no refunds, no exceptions. Prohibitions matter more here than in most writing, because a generative system will otherwise find a helpful-sounding way to say yes.

Handle the missing case

What happens when the order number is not found, when the customer will not give one, when the answer is not covered. Every procedure needs those, and they are where the real failures happen.

No buttons or carousels

Generative procedures do not currently support rich-text formatting such as buttons or carousels. Where a case genuinely needs those, a scripted dialogue is still the tool.

One case per procedure

Since each procedure belongs to a use case, that boundary is largely drawn for you. Resist widening it: when a transcript goes wrong you want to point at one procedure, and a procedure covering several situations is hard to debug and hard for the agent to follow.

Test the ugly paths

Not the happy one. Give it a wrong number, an unrelated question mid-way, and a refusal to answer. That is where you learn what you wrote.

See also

• Writing a good procedure: where it usually goes wrong
• Creating use cases
• What actions are and what an AI agent can do with them