Rewarding the Reporters: The Thank-You That Stops the Next Click

Friday afternoon at Northgate Retail, store fourteen. Bea, a till supervisor, gets a message about an "updated staff discount scheme" with a link. She thinks it looks off and forwards it to the desk address on the poster in the stockroom. She gets an automatic reply: "Ticket 5817 has been created." Nothing else, that day or any other. Three weeks later a similar message arrives about "holiday rota changes". Bea deletes it. Her colleague on the next till, who never saw the first one, clicks it and types her password. The desk finds out on Tuesday when the store manager asks why the rota mailbox is sending everyone gift-card offers.

Owen, who runs the desk, reads the two tickets side by side the following week, ticket 5817 and the one for the click. He sees the whole thing in one glance. The desk had been told. It had even done something about the first message, quietly, in the background. What it had not done was tell Bea. So Bea had learned, correctly, that reporting things to the desk produced an automated number and nothing else. She did not report the second one because the desk had taught her not to. Owen changed one template that afternoon, and it is the one at the end of this article.

Rewarding the reporters means making sure that every person who reports a suspicious message is better off for having done it. They are thanked by a person, told what the message was, and never blamed. That holds even when the message turned out to be real and even when they clicked before they reported. The reward is almost never a prize. It is the experience of being taken seriously, which is cheap to give and expensive to withhold. This article is part of our Phishing Reports & Security Tickets series. And it is about the only security control a help desk fully owns: whether people tell it things.

It covers why the thank-you is the whole lever, thanking every reporter including the wrong ones, and the outcome message that teaches. Next come the monthly note of what the reports caught, the no-blame rule stated and kept, and the leaderboard question. Then it covers simulated phishing, handled carefully, and small rewards that work and ones that backfire. It finishes with a short war story and the thank-you message to copy.

Why the Thank-You Is the Whole Lever

The desk cannot make people spot phishing. It can make reporting cheap, pleasant and visibly useful, and that is enough, because the report is the signal everything else depends on. Behaviour follows what happens afterwards. A report that gets a warm reply and an answer happens again. A report that gets silence, an automated number, or "that's just spam" does not. Every other control, the filter, the training, the second factor, is owned by someone else. The reply to the reporter is owned by the desk, entirely, and it costs a minute.

Put it in the desk's own terms. A phishing campaign that reaches forty people is a race between the first report and the first click. The desk wins the race only if someone reports quickly. The person most likely to report quickly is the person who reported last time and was thanked for it. Over a year the organisation sorts itself into people who tell the desk things and people who do not. The sorting is done almost entirely by what the desk said back the first time. That is the lever. It is not subtle, and it is not optional.

The thank-you also does something the training course cannot. Training tells people what phishing looks like in general. The outcome message tells one person what the specific thing they just saw was and whether their instinct was right. "You were right that the address was wrong" is one sentence of training delivered at the exact moment the person was paying attention, about a message they actually received. (The slide deck, meanwhile, was delivered in a meeting room in March to people thinking about lunch.)

Thank Every Reporter, Including the Wrong Ones

Every reporter is thanked, and "every" includes the three categories that tempt a tired desk to skip it. The first is the false alarm. That is the message that turned out to be a real invoice, a real newsletter, or a real colleague with an odd writing style. The reporter did something valuable: they paused before acting on a message that asked for something. The desk wants them to pause again next time. "That one was real, sorry for the delay, and thank you for checking" is the whole reply. The phrase "you wasted our time" is never said, implied, or allowed to leak through tone. The one reporter who hears it tells four colleagues what happens when you report things.

The second category is spam. A person who reports junk mail is a person who has not yet learned the difference between a nuisance and an attack. And the desk's job is to thank them, say which this was, and give the junk-folder tip, not to teach them to stop reporting. The line between spam and phishing is the desk's to draw, in the triage described in The Phishing Triage Flow. A reporter who tries to draw it themselves before reporting will get it wrong in the dangerous direction, and skip the one that mattered.

The third category is the person who clicked first and reported second, and they are thanked most of all. Telling the desk "I think I've done something stupid" is the hardest message anyone sends. It is the message that lets the desk fix the problem in an hour instead of finding it in a month. The reply to that person opens with gratitude, carries no lecture, and treats the click as a thing that happened rather than a thing they did. The first hour after that message is described in When Someone Clicked: The First Hour. The tone of the reply is this article's concern, and the tone is warm, every time, without exception. Nobody reports a second click to a desk that made them feel small after the first.

The Outcome Message That Teaches

The thank-you has two halves, and the second half is the one that builds skill. The first half is the acknowledgement within the hour, which says "we've got it, you did right, don't click, I'll tell you what it was". The second is the outcome message, sent the same day when the verdict is in, which says what the message was and, in one sentence, what the reporter got right. "It was a fake, and you were right that we'd never ask you to sign in through a link in an e-mail." "It was junk, not an attack, but the thing you noticed, the odd sender address, is exactly what to look for." "It was real, from the new person at the supplier, and you were right to check because it asked about money."

That one sentence is the most efficient security training the organisation runs, because it is specific, immediate and about something the person already cares about. Over a year, a reporter who hears it ten times has been taught ten real lessons about ten real messages. They have also been told ten times that their judgement is good. People who are told their judgement is good use it more. The outcome message is also where the loop closes. The reporter now knows the report went somewhere and did something, which is the fact that Bea at Northgate never learned.

Make the outcome message easy to reply to, because reporters often have a follow-up. It might be "I've just had another one", or "my colleague got the same thing", or "what should I do with the first one?". If you run QuerySolv, the reporter's reply to the outcome message reopens the ticket and lands in the same thread. That way, the second report of the day arrives with its history attached and nobody has to search. Most tools thread a reply onto the ticket somehow; what matters is that the reporter's "and another thing" is welcome and goes to the right place. A reporter who is told to "raise a new ticket" for their second report has been given a small piece of homework. They will remember it.

The Monthly Note of What the Reports Caught

Once a month, the desk sends a short note to the whole organisation saying what the reports achieved. This is the reward that reaches the people who have not yet reported anything. The monthly note is four or five sentences. It says how many messages were reported and how many turned out to be phishing. It gives one plain example of what a reported message tried to do and what the reports allowed the desk to stop. And it thanks everyone who sent one. It is not a statistics report and it is not a warning bulletin. It is a note from a colleague saying "this is what you did, and it worked".

The example is the part people read. "Three people in the warehouse reported a message pretending to be from the payroll provider within twenty minutes of it arriving, and because they did, we warned everyone else before anyone signed in" is a sentence that tells the whole organisation three things at once. The desk wants reports, reports work, and the warehouse is good at this. Nobody is named without their permission, and nobody who clicked is ever named at all, in any month, for any reason. The note names outcomes, not people.

Keep the note's "what to look for" to a single line and a link, because a monthly note is not the place to teach triage. The place for that is one knowledge base article that everyone can read, written once and kept current. It shows the three looks in plain words with a picture. The note points at it. A note that tries to be the training course gets long, and a long monthly note is a monthly note that is not read.

The No-Blame Rule, Stated and Kept

The no-blame rule is one sentence, written down and said aloud at induction. Nobody is ever worse off for telling the desk about a suspicious message or a click, whatever the message was and whatever they did with it. It has to be written, because a rule that lives in the desk lead's good intentions does not survive the desk lead's holiday. It has to be said, because the people it protects are the ones who would never think to look for it. It sits on the desk's scope page, in the induction pack, and at the bottom of the thank-you message, where the reporter can see it every time.

"No blame" needs defining, because it is often misheard as "no consequences", and it is not that. The organisation can still train people, still run its security programme, still decide that a pattern of clicks in one team needs attention. What the rule says is narrower and firmer: the act of telling the desk never makes anything worse for the teller. A person who clicked and reported is treated better than a person who clicked and hid it, visibly and every time. That difference in treatment is the entire reason people report. The desk's role in training is the thank-you and the outcome message, and nothing else. The training programme belongs to the security function and happens elsewhere, later, kindly.

The rule gets tested, and the test usually arrives as a manager. "Who clicked it? I want to have a word." The desk's answer is that the ticket records an account and the person has already been told what happened and what to do. The security function decides whether anything further is needed. The desk does not hand over names for a word to be had. That is a no said upward. It is said in the form that works: naming what the manager needs, confirming what the desk cannot do, and routing the decision to its owner. That is the shape described in Saying No Upward. A desk that gives up the first name has told the whole building what reporting costs. It will not need to say it twice.

The Leaderboard Question

At some point someone will suggest a leaderboard, and the suggestion comes in two forms. The friendly form is a ranking of reporters: most reports this quarter, a name at the top, perhaps a prize. The unfriendly form is a ranking of clickers, usually proposed as "accountability", occasionally as a joke. In one organisation I knew of, it appeared as a laminated sheet in the kitchen. The second form is never done, under any name, and the reasons are the whole of this article. A public list of who clicked is a public lesson in staying quiet, and the next click goes unreported for a month. The friendly form needs more careful handling, because it is well-meant and it still goes wrong.

A reporter leaderboard rewards volume rather than judgement. The person at the top of it reports everything, including every newsletter, because the ranking counts reports and not useful ones. The people in a quiet department look as if they are not trying, when in fact they receive less phishing. The moment a prize is attached, the reports become a game that some people play and others resent. The desk also inherits a new ticket type, "why is my count lower than hers", which is not a ticket anyone wants to work. Counts by team, thanked in the monthly note, carry most of the benefit and none of the mechanics.

If leadership insists, and sometimes it does, settle for the version that cannot hurt. That version uses team-level counts, no individual ranking, and no clicker numbers anywhere. It allows voluntary name-checks for people who are happy to be thanked publicly. It offers no prize that could be won by reporting more rather than better. The thinking about measures that motivate against measures that surveil applies to this exactly as it does to the desk's own numbers. And it is laid out in Dashboards That Motivate Instead of Surveil. The short version is that a number on a wall changes behaviour. And the desk had better like the behaviour it is going to get.

Simulated Phishing, Handled Carefully

Many organisations run simulated phishing: fake phishing messages sent by the organisation itself, or a service on its behalf, to see who clicks and who reports. Whether to run it is the security function's decision, not the desk's. But the desk is the place the reports land, so the desk needs three things in place. It needs to know, in advance, that a simulation is going out and what it looks like. That way, the triage card is not run in earnest on it and the security function is not phoned about its own test. It needs to treat every report of the simulation as a real report, with a real thank-you and a real outcome message. That message says "that one was our own test, and you did exactly the right thing". And the desk needs to hold the line that simulation results are never used to shame anyone, by the desk or by anyone the desk talks to.

The failure mode is the "gotcha": a simulation designed to be as cruel as possible. It might be a payslip, a redundancy notice, or a message from the chief executive. It is followed by a note to everyone who clicked that reads like a summons. People learn from it, but what they learn is that the organisation is trying to catch them out. The reporting rate falls afterwards, which is the opposite of the point. The desk has standing to say so, because it owns the reporting channel and sees the rate fall first. Say it early, in writing, before the simulation is designed. The thank-you goes to everyone who reports it, and no names of clickers leave the test. The follow-up to clickers is a kind note with a link, not a list on a wall.

One more thing about simulations: count their reports separately from real ones. That way, the monthly figures are not inflated by a test. Say in the monthly note which was which. A month with forty reports of which thirty-five were the simulation is a good month for the simulation and an ordinary month for the organisation. Both facts are fine. Mixing them is not.

Small Rewards That Work, and Ones That Backfire

The rewards that work are the ones that cost attention rather than money. A thank-you by name in the team meeting, with the person's permission. A one-line note to the reporter's manager saying what they caught, copied to the reporter. A sentence in the monthly note that names the department. Being the first person a reporter hears from, within the hour, by name. The "you were right" sentence in the outcome message. None of these can be gamed, none creates a ranking, and all of them are the kind of thing people mention at home. The best reward I have seen was a desk lead who walked to the warehouse to thank three people in person. It took twelve minutes and was talked about for a year.

The rewards that backfire are the ones with a mechanism. Prizes for the most reports produce the most reports, which is not the same as the most useful ones. Public click-shaming produces silence. "Phish-proof" badges, certificates or titles for people who have not clicked produce overconfidence and a particular unwillingness to admit it when the badge-holder finally does. Competitions between departments produce a month of enthusiasm and a quarter of resentment. The pattern is that anything which turns reporting into a score changes what people optimise for, and the desk wanted honesty, not a high score. Honesty does not have a leaderboard. (It barely has a logo.)

The honest opinion, then: give a thank-you by a person within the hour and an outcome message with the "you were right" line. Send the monthly note naming teams, and keep the no-blame rule under pressure. Everything else is optional, and most of it is worse than nothing. The desk that does those four things consistently for a year will have an organisation that reports more and clicks less. And it will have spent nothing on it but minutes.

A Short War Story: The Kitchen Wall at Bluewater Bank

In a simulation at Bluewater Bank, four of branch manager Callum's nineteen staff clicked. Afterwards, he printed the four names under the heading "Let's do better" and pinned the sheet above the kitchen kettle. It stayed there for a fortnight. The desk, which had not been consulted, watched the branch's reports go from five or six a month to none at all for the next four months. During that time, a real message imitating the bank's own card-services team reached the branch. It was clicked by a cashier who had been on the sheet and said nothing about it for nine days. The clean-up involved a contracted security firm, the compliance team and a review of every account the cashier's sign-in could reach. It took something over sixty hours and a conversation with the regulator that nobody enjoyed. The desk lead's note in the review said that the sheet had cost more than every click in the simulation put together. It also recorded the cashier's answer when asked afterwards why she had not reported it. She had said she did not want to be on the wall again. The lesson written into the desk's scope page the same week was five words long: no list of names, ever.

The Thank-You Message

The message below is Owen's, rewritten after ticket 5817, and it replaces the automated "ticket created" reply as the first thing a reporter hears. It is sent by a person, within the hour, with the reporter's name and the one specific line filled in. And it is followed the same day by the outcome version that fits. The no-blame line at the bottom is not decoration; it is the rule, visible every time. And it stays in every version including the one for the person who clicked.

THANK-YOU MESSAGE — SENT BY A PERSON, WITHIN THE HOUR
Ticket: ________   Reporter: ______________   Sent by: ______________   At: ______

Subject: Thank you for reporting that message

Hi ________,

Thank you for sending that in. Reports like yours are how we find out about
these before anyone is caught, so please keep doing it.

The thing you noticed, ____________________________, is exactly the right
thing to look for.

Please don't click anything in it or reply to it, and leave it where it is.
I'll tell you what it was by ________ today.

If you did click, open or type anything, just tell me; there is no trouble
either way, it only changes what I do next.

________ (name), IT desk

Nobody is ever worse off for reporting a message to us, whatever it turns
out to be. That is a rule, and we keep it.


OUTCOME — SENT THE SAME DAY, ONE OF FOUR

[ ] PHISHING: "It was a fake, pretending to be ________. You were right
    about ________. It has been blocked and the other people who received
    it have been warned. Nothing more for you to do. Thank you again."

[ ] SPAM: "It was junk rather than an attack, so nothing to worry about.
    Marking it as junk teaches the filter. Thank you for checking; the
    thing you noticed is still the right thing to look for."

[ ] LEGITIMATE: "That one was real, from ________. Sorry for the delay it
    caused you. You were right to check, because ________, and we would
    always rather you asked. Thank you."

[ ] OUR OWN TEST: "That was a test message we sent ourselves, and reporting
    it is exactly what we hoped for. Thank you. Please treat the next one
    the same way."

[ ] IF THEY CLICKED (any version above, plus): "Thank you for telling me
    straight away; that is the part that matters most. Your password has
    been changed and you have been signed out everywhere, so please sign
    back in on your devices. Tell me if anything looks odd this week."

Bea at Northgate got the new message the next time she reported something, which was five weeks later. The outcome message told her that the "holiday rota changes" message she had reported was a fake. It also told her she had been the first in the store to spot it. She told the till team. Reports from store fourteen went from one or two a quarter to one or two a week, most of them junk, two of them not. The desk has never once said that any of them was a waste of its time.

Frequently Asked Questions