Quick note right from the jump - obviously we think Phin is the best platform for MSPs. Built specifically for them, based on insights and feedback from them. But this article is going to be written completely impartially - straight down the middle and objective. We’re going to resist the urge to add “like with Phin” or “that doesn’t happen when you use Phin” although you can feel free to include them in your head while reading. Anyway…
If you’re running phishing simulations for your clients, you’re already ahead of other organizations. But are those simulations actually doing what they’re supposed to? Sure, they run, reports get generated, boxes get ticked, but behaviour doesn’t really change. And behind the scenes, they often create more manual work than they’re worth.
Phishing simulations shouldn’t just support cybersecurity compliance. They should actively reduce risk by changing how people respond to real threats. And they should do it in a way that doesn’t add hours of extra admin for the MSP managing it all.
Let’s be real - if it’s not improving behavior, or it’s creating operational drag, it’s not working.
Before getting into what goes wrong, let’s define what success actually means. A successful phishing simulation program does more than track clicks. It should be changing habits, too.
You should see:
And on the backend:
If users are “passing” simulations but still falling for real phishing emails, the program isn’t doing its job.
It’s tempting to make simulations obvious. You don’t want to “trick” users. You don’t want complaints or extra support tickets. So the emails end up being… obvious. Only a fool would click them!
That’s the problem.
Real phishing attacks aren’t like that. Especially nowadays, they’re well written, contextual, timed properly, and trick even the savviest of cyber professionals. They’re also increasingly personalized, especially with AI tools making it easier to mimic real communication styles at scale. It used to be that poor spelling and weird formatting meant the subject line of a phishing email might as well have been “THIS IS A SCAM, DO NOT CLICK!” That’s no longer the case, and if your simulations don’t reflect that, you’re not training users for reality. You’re training them to tick a box and pass a pop quiz that is nothing like the final.
It’s like singing into a hairbrush with an audience of one (your cat) to prepare for the finale of American Idol with an audience of millions. It’s just not even remotely the same and unfortunately, your end-users are not on Kelly Clarkson’s level (that’s not an insult - nobody is).
If you want behavior to improve, simulations need to challenge people without being unkind.
This is one of the fastest ways to make a program fail. A user clicks a simulated phishing email, and what happens? They get assigned a long training video. Maybe 10 minutes. Maybe 20 or longer. From the user’s perspective, they made a mistake and immediately got punished with more work.
That does two things:
And it usually misses the most important point - the training isn’t tied to the actual mistake they made. They don’t know what they missed in that specific email, so they don’t learn how to avoid it next time.
What works better is immediate, contextual feedback.
And on the flip side:
If someone reports a suspicious email and nothing happens, they stop reporting. If they get recognition, even something small, they’re far more likely to do it again. That’s how habits form, and to quote Rocky Balboa, “that’s how winning is done.”
If you run them too infrequently, users forget what to look for. Awareness drops off, and you’re back to square one. If you run them too often, they just become noise. Users get fatigued and annoyed. They start rushing through emails just to get on with their actual job. Ironically, that often leads to more mistakes rather than fewer - and that’s the opposite of what you’re aiming for.
The sweet spot for most organizations is around one to two simulations per month. Frequent enough to reinforce awareness, not so frequent that it becomes disruptive. For MSPs managing multiple clients, consistency matters more than intensity. A steady, predictable cadence is far easier to maintain and far more effective over time.
Click rates are the default metric for phishing simulations, and for good reason - they’re easy to understand, easy to report on, and easy to compare over time. But on their own, they don’t tell the full story. What really matters is what users do when they see something suspicious.
Reporting is one of the most valuable habits you can build. If a phishing email goes unreported, your team doesn’t know it exists. It can sit in inboxes, get forwarded, or be clicked multiple times before anyone notices. If one user reports it quickly, IT can investigate and remove it from every inbox before it spreads. That’s where it goes from a training win to a bona fide operational success.
A strong phishing simulation program should measure both sides of the equation:
Without both, you’re only seeing half the picture.
Creating realistic phishing templates sounds simple until you actually try to do it well. They need to feel believable, relevant, varied, and up to date with current attack trends. That takes time. For MSPs managing multiple clients, that time adds up quickly.
So what usually happens? Templates get reused. Patterns emerge. Users start recognizing the simulation instead of analyzing the email. Or worse, simulations become inconsistent because there just isn’t time to build new ones properly. Neither of those outcomes helps improve behavior.
Using a platform that provides and regularly updates realistic templates removes that burden. You get variety and relevance, and you free up time (which, as we all know, is money!)
It’s rarely done on purpose, but sometimes the person managing the training just gets carried away. Phishing simulations should be realistic, but they should never be malicious. What do we mean by that if malice is the whole point of phishing?
Your simulations should never include messages that will completely crush the team’s morale. No fake raises, no fake lay offs, and definitely don’t imitate any government entities like say… the IRS. (Seriously, don’t do it.)
This issue isn’t always visible, but it can cause a lot of damage - like Randall from Monsters, Inc. or unspoken tensions at a family BBQ. If phishing simulations aren’t reaching users’ inboxes, the entire program falls apart. Email filtering tools can block or quarantine simulation emails if they’re not properly allowlisted.
Manual allowlisting:
The result is inconsistent delivery, unreliable data, and wasted effort.
Automated allowlisting removes that friction. It ensures simulations reach users as intended, without requiring manual setup across every tenant, and eliminates one more operational headache for MSP teams who already have enough to manage.
A phishing simulation program should do more than exist.
It should:
If it’s too easy, it won’t prepare users. If it feels like punishment, users disengage. If it’s inconsistent, it loses impact. If it creates more work than it saves, it won’t last.
Remember, the goal is making people better at responding to real world threats - not just tripping them up.
If you want to see how this works in practice, including what end-users actually experience when they click or report a phishing simulation, it’s worth looking at a platform built specifically for MSPs.
The difference isn’t just in the features. It’s in how those features come together to improve behaviour while reducing the time it takes to manage everything behind the scenes.
Because the best phishing simulation program is the one that actually makes users safer without making your job harder.