Support metrics are collected by the system being measured, which is the structural problem with all of them. A macro sent in ninety seconds that answers nothing counts as a fast first response.
What to put in the public brief
- Which channel, and roughly when they need to be reachable
- That they may need to reply over several hours
- That the scenario will be supplied
- Roughly how long in total
Keep the company, the channel details and the scenario private.
What to put in the private instructions
Give one realistic scenario, written out
Ambiguous enough to need a real answer, ordinary enough to be plausible. Not an emergency, not a refund, not anything that consumes a scarce queue.
Say to use their own words
A worker pasting your scenario verbatim tests how your team handles a scripted message, which is not a thing that happens.
Ask them to record times, not durations
When they sent, when each reply arrived. You can compute durations; you cannot recover timestamps they estimated.
Ask one question about tone
"Did you feel like a person or a ticket, and what made the difference." That sentence is the whole reason to run this rather than read the dashboard.
Proof worth requiring
Ask for
Screenshots of the full exchange with timestamps visible, and their written answers. Redact nothing: it is your own support queue.
Do not ask for
A rating of the agent. You are testing a system, and turning it into a judgement of an individual is how this becomes something your team is right to resent.
When this task type is the wrong tool
If you want to test a competitor's support, do not. It consumes another company's paid staff time under false pretences, and this marketplace will not carry it.
If your problem is that customers cannot find support at all, a first-impression test will find that faster and for less.