✦ Task type · Research and checks
What your support queue looks like from the other side
Your dashboard shows median first response. It cannot show what the reply felt like to receive, and that is usually the number that matters.
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.
Common questions
Should I tell my support team?
Have the conversation before you run it, not after. A test run without warning produces cleaner data and a worse working relationship, and the second cost outlasts the first. Tell them a test is happening this quarter without saying which tickets, and you get most of the honesty and none of the ambush.
Is it acceptable to send fake tickets?
To your own support team, with a scenario that is realistic and not an emergency, yes. Never to another company's, and never a scenario that consumes a scarce resource such as a callback slot, a refund process or a safety queue.
What reward is fair?
Eight to eighteen dollars, priced on the waiting rather than the writing. A worker who has to stay reachable for a reply over several hours is committing more than the ten minutes of typing suggests.
What should I measure?
Time to first human reply, whether the first reply answered the question or deflected, how many exchanges to resolution, and one sentence on how it felt. The last one is the finding your dashboard cannot produce.
Thinking of taking this task?
The same job, from the other side. Rewards are set by the poster, so treat these as the range this task type usually sits in rather than a promise.
- Usually pays
- $8 to $18
- You need
- An email address and availability across a few hours
- Proof expected
- Screenshots of the whole exchange with timestamps visible
You are contacting the poster's own support, never a third party's. Use your own words rather than pasting the scenario, and record times as they happen.
Create a worker accountTest your support
Set the reward and how many contacts you need. Workers reserve a spot; your channels and scenarios stay private until they do.
Post this task