Testing a procedure

Test the awkward cases, not the clean one. The clean case is the one you already had in mind while writing.

Test the awkward cases, not the clean one. The clean case is the one you already had in mind while writing.

Test it

1. Open the procedure and start a test.
2. Run the straightforward case once.
3. Then run the awkward ones.
4. Note where it proposes something wrong, and why.
5. Fix the wording and test again.

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.

See also

• Writing a procedure
• Viewing and managing procedures
• Auto assist gives no suggestions from my procedures or articles