On paper, a phishing simulator inside an inventory and help desk tool makes no sense. Let me explain why it is in here anyway.
First, the practical reason. Edventory already had all the infrastructure for sending email, because the help desk sends email, notifications send email, invoices send email. Once you have a reliable sending system, running phishing simulations is a natural extension of it rather than a whole new thing to build. The hard part was already done.
Second, the honest reason. I was paying for KnowBe4, and building this into Edventory let me eliminate that bill. When you run technology for districts on a tight budget, every recurring subscription is a target. If I can fold a capability into a tool I already run, I do, because that is one less invoice to justify and one less login for my staff to manage.
Third, and this is the real one, phishing is a daily threat in schools. Education staff get targeted constantly. The attackers know schools are understaffed, that the people are busy and trusting, and that there is valuable data behind those accounts. Awareness training is not optional anymore. So having it live in the same place I already manage everything else means I actually run it, instead of letting it slide because it is one more separate system.
One detail worth explaining in plain terms. The simulations send from a reputation isolated domain. That means the fake phishing emails go out on a separate sending identity from your real district mail. If a simulation ever looked suspicious to a mail provider, it cannot drag down the reputation of the domain you use for actual school communication. You get to test your people without putting your real email deliverability at risk.
I live in this system every day. Phishing belongs in it because protecting my staff is part of the same job as everything else I do here.