Phishing simulation programs that actually change behavior, not just generate a click-rate number

The default phishing simulation program looks like this: send a batch of fake phishing emails quarterly, record who clicked, put a click-rate percentage in a slide for the client's leadership, and repeat next quarter. It produces a number that looks like security work, and in a lot of cases it produces almost no durable change in how anyone actually behaves when a real phishing email lands in their inbox six weeks later.

The reason is that click-rate-as-KPI optimizes for the wrong variable. A single quarterly simulation measures a moment, not a habit, and it rewards a program for looking better on paper — lower click rate — over actually building the reflex that matters, which is a person pausing, noticing something off, and reporting it before they've clicked anything at all.

What actually changes behavior

• Frequency and unpredictability over one big quarterly event — spaced, varied simulations that don't arrive on a predictable schedule build a standing habit of scrutiny instead of a one-time cram session.
• Measuring report rate, not just click-avoidance — a program that tracks how often people flag a suspicious email, even ones that weren't simulations, is measuring the behavior you actually want, which is vigilance, not just luck.
• Immediate, specific feedback at the moment of the click — a generic 'you failed the test' email a week later teaches nothing; showing the exact tell in that exact email, right when someone clicks, is what actually transfers to the next real attempt.
• Difficulty that escalates with demonstrated skill — sending the same obvious fake-invoice template to someone who's caught the last five doesn't test anything; a program that adapts difficulty is testing the skill you're trying to build, not the training's memorability.

A click-rate number in a quarterly report tells a client's leadership that a security program exists. It doesn't tell them whether anyone would actually catch the phishing email that isn't a simulation.

This connects to a broader pattern worth naming: click-rate-as-report-metric is convenient because it's a single number an MSP can hand a client without much explanation, but convenient-to-report and actually-effective aren't the same property, and conflating them is how a security line item survives a budget review without doing much security.

Where Nexus stands on this today: phishing simulation as a fully wired, adaptive, report-rate-tracked capability is design direction, not something live in our own MSP practice yet — the honest status is that it sits on the roadmap behind the security-module capabilities that are further along. When it ships, the standard we're holding it to is the one above: report rate as a tracked metric alongside click rate, not instead of it, and simulations frequent and varied enough that a client can trust the number reflects a habit rather than a single lucky or unlucky Tuesday. If we ship it and it's still just a quarterly click-rate report, that's a fair thing to call out.