Plan requirement
| Subscription | Suite Professional or higher, Support Professional or higher |
| Also required | Copilot |
| Access | Admin |
Test the awkward cases, not the clean one. The clean case is the one you already had in mind while writing.
Test it
- Narrow who can see auto assist first, under Who has access, to the group doing the testing.
- Create a real ticket carrying the tag
agent_copilot_enabled, by email or messaging. - Send the email from an address that belongs to no agent in your account. Auto assist does not respond to agent comments, so a test sent from your own account produces nothing and looks like a fault.
- Work the ticket with auto assist's help: the straightforward case once, then the awkward ones.
- Note where it proposes something wrong, fix the wording, publish and test again.
There is no separate test mode. You are working a real ticket in your real account, which is why the first step matters: without it, an unfinished procedure is suggesting things to everybody.
The cases that find the problems
- Information missing. No order number, no date, no account.
- On the boundary. Exactly thirty days, exactly the threshold amount.
- Two things at once. A return and a complaint in the same message.
- Outside scope. Something the procedure does not cover at all.
- A customer who refuses. Will not give the information, wants a person.
Read what it proposes, not whether it proposed
The failure mode is a plausible step that is subtly wrong: the right action with the wrong condition, or a step in the wrong order. That reads as working unless you check it against what you meant.
Fix the procedure, not the ticket
When a step is wrong, change the wording rather than working around it in that case. Vague instructions produce inconsistent behaviour, and the inconsistency is the thing to remove.
Test on real tickets before widening
Enable it for one ticket type and watch actual cases. Real customers phrase things in ways nobody testing would think of, and that is where the last set of gaps appears.
Retest after every change
Including changes to the underlying process. A policy change makes a procedure wrong without anything in Zendesk changing.
Comments
0 comments
Article is closed for comments.