Written by Krisztián Stark
Key takeaways
- A good reason names the requirement that was missed and what the proof shows instead, so anyone can check it in seconds.
- Pick a quick reason, then add one specific detail. The user reads it word for word and can dispute it for 72 hours.
- If you would accept a dispute anyway, approve now: it costs the same and saves both sides days of waiting.
What makes a rejection reason users accept?
A reason users accept points to one requirement from your instructions and says what the proof shows instead, in words anyone can check by looking at the screenshot. “The screenshot shows the sign-up form, not the welcome screen” leaves nothing to argue about. “Invalid” leaves everything to argue about.
This matters because the user reads your reason word for word and can dispute it for 72 hours. A clear reason usually ends the matter there. A vague one tends to come back as a dispute, keeps the price of the completion on hold, and may end up in front of Sharklio staff.
Where your reason ends up
When you click Reject on a completion (How to approve or reject completions shows where), a dialog opens with two fields. Quick reason is a list of common reasons, and Reason for the user is the text that is actually sent. It needs 10 to 500 characters, and the hint below it says what happens next: the user sees this reason and can dispute it for 72 hours.
From there, your words travel further than most advertisers expect:
- The user sees the completion in the offerwall History as Rejected, you can dispute, with your reason in the details, a countdown, and a Dispute this result button. To dispute, they must explain in 15 to 2,000 characters why the proof is correct, and they can add a screenshot.
- You then answer the dispute with Accept and pay or Keep the rejection. If you keep it, you explain why in at least 15 characters, and both the user and our staff see that answer.
- Sharklio staff decide if you keep the rejection or do not answer in time. They read the whole thread, starting with your original reason, and their decision is final.
- The publisher whose site sent the user sees the reason in their reports once the rejection is final.
The full timeline is in How to handle completion disputes. The point here is simpler: write every reason as if a neutral person will read it next to the proof, because one may.
The six quick reasons, and when each fits
Picking a quick reason puts its text into the reason box, where you can add to it before sending. These are the six options, word for word:
| Quick reason | Use it when | Detail worth adding |
|---|---|---|
| The screenshot does not show the step we asked for. | The proof shows something, but not the screen or result your requirement names. | Which step was required, and what the screenshot shows instead. |
| The account was not created through our link. | Your own records show the sign-up did not come from the task link. | What you checked, for example that no account was created from the link at that time. |
| You already sent this offer before. | The same person, account or screenshot was already used for this task. | That the same screenshot or username appears in an earlier completion. |
| The username does not match the one in the proof. | The username typed as text proof differs from the one in the screenshot or in your records. | Which two values differ. |
| The proof is unreadable or cut off. | The part that matters is blurred, cropped or missing. | Which part you could not read, such as the username or the date. |
| The task is only partly done. | Some steps are done, but not all of them. | Which step is missing. |
The quick reasons are a starting point, not a full answer. A sentence of detail turns “The task is only partly done.” into something the user can act on.
Good and bad reasons, side by side
The examples below are illustrative. Each weak reason has the same problem: the user cannot tell what to fix, and a reviewer cannot check it.
| Weak reason | Stronger reason |
|---|---|
| Invalid proof. | The screenshot does not show the step we asked for. We need the order confirmation page, and this shows the cart. |
| Fake. | You already sent this offer before. The same screenshot was used in an earlier completion of this task. |
| Not done. | The task is only partly done. The profile picture is set, but the bio from step 3 is empty. |
| Wrong. | The username does not match the one in the proof. You entered sam_writes, and the screenshot shows samwrites22. |
| Bad screenshot. | The proof is unreadable or cut off. The username at the top of the page is cropped out. |
Illustrative pattern: requirement, what you saw, what would pass
“Step 2 asks for a screenshot of your profile page with your username visible. This screenshot shows the home feed, so we cannot see the username. A screenshot of the profile page would have passed.” Three short sentences: the requirement, the gap, and the fix. A user who reads it knows whether a dispute makes sense, and so does anyone reviewing it later.
What never belongs in a reason
- New requirements. Judge the proof against the instructions the user saw when they sent it. If you want something extra from now on, edit the campaign for future users. Proof requirements for every task type helps you ask for the right proof up front.
- Budget reasons. “We have enough sign-ups” is not a reason to reject finished work. Use caps or pause the campaign instead.
- Accusations and tone. “Cheater” or “Nice try” helps nobody. If you suspect fraud, state the fact that made you suspicious. Fake proof screenshots: how to spot them lists facts worth pointing to.
- Private details. Write about the proof, not about the person. Nothing in a reason should identify or describe the user beyond what they sent.
Keep your reasons consistent
Users who do several of your tasks notice when the same problem gets different answers. Consistency builds trust, and it also protects you: when a dispute reaches staff, a reason that matches how you treated similar completions is easy to uphold.
- Use the same quick reason and the same kind of detail for the same mistake.
- Keep a short list of your own standard sentences for problems specific to your task, and paste them in after the quick reason.
- When one reason keeps coming up, read your instructions again. Many users making the same mistake usually means the step is unclear.
The reject dialog warns that rejecting valid work again and again can get your account suspended, and the Terms of Service say every rejection needs a reason and may only be used when a completion clearly fails the requirements your campaign stated.
When to approve instead
A reason that is hard to write is often a sign the completion should be approved. Approve when:
- The user clearly did the task, even if the screenshot is plain, small, or not framed the way you imagined.
- Your instructions could fairly be read the way the user read them.
- The missing detail is something you can check yourself in a few seconds, such as an account in your own records.
- You would accept the dispute if it came. Approving now costs the same price and skips up to 72 hours for the user to dispute and up to 72 hours for your answer, with the money on hold the whole time.
Remember too that you can only reject while the review window is open. A completion still undecided when it ends is approved automatically, so do not hold borderline cases back for later. How review speed and approval rate affect your traffic explains why fair approvals also help your task on the offerwall.
Reviewing that is fair to both sides
On Sharklio you check every task completion yourself and pay only for work you approve, and clear reasons keep that process quick. You can create a free account today and set up your first task campaign with a proof requirement that makes reviewing easy.
Frequently asked questions
Can I write my own reason instead of a quick reason?
Yes. The quick reasons are optional. You can write your own text from scratch, or pick a quick reason and add to it. Either way it needs 10 to 500 characters.
Who can see my rejection reason?
The user sees it right away in the offerwall History. If they dispute, Sharklio staff see it with the rest of the thread, and the publisher who sent the user sees it in their reports once the rejection is final.
Can I change a reason after I sent it?
No, the reason is saved with the rejection. If the user disputes, you can add context in your answer when you keep the rejection, or accept the dispute if they were right.
What happens if the user does not dispute?
After 72 hours the rejection becomes final, the completion is never charged, and its hold is released. A final rejection also no longer stops that user from starting the task again, so a clear reason gives a genuine user the chance to do it right next time.
Should I reject if I only suspect fraud?
Only if you can name a fact, such as a reused screenshot or a username that does not exist in your records. A suspicion without a checkable fact is hard to defend in a dispute.
