Four analysts. Four hundred alerts a day. The math does not work. We've seen this configuration at more mid-market companies than we can count, and the outcome is always the same: either the team burns out within 18 months, or they start auto-dismissing alert categories wholesale. Which is just a different kind of failure.
Alert fatigue is the right name for it but the wrong frame. Fatigue implies the problem is stamina. It isn't. The problem is decision overhead. Every alert in a traditional SIEM queue asks the analyst to reconstruct context from scratch: raw log lines, sender metadata, user history, threat intel lookups, maybe a sandbox verdict. That reconstruction work takes 8 to 12 minutes per alert on average, based on what we track across customers. At 400 alerts a day, you're asking four analysts to collectively do 53 to 80 hours of reconstruction. Every day.
Something has to give. It usually gives in the direction of speed over rigor. Analysts develop pattern-matching shortcuts. Those shortcuts are fine when they're right and catastrophic when they aren't.
What Makes Mid-Market SOCs Structurally Different
Enterprise security teams can throw headcount at the problem. A 20-analyst SOC rotates shift coverage, runs a dedicated threat-hunting function, and still has capacity for deep investigation. The mid-market can't do that. Companies in the 200 to 2,500 employee band are running security operations with one to four people. Full stop. Those same analysts are also handling endpoint response, access reviews, vendor risk questionnaires, and whatever compliance framework the company happens to be pursuing at any given moment.
The alert volume doesn't scale linearly with company size. A 500-person company with Microsoft 365 and Okta generates nearly as much raw security telemetry as a 2,000-person company running the same stack. The signal-to-noise ratio is similar. The team size is not.
This is the gap most security vendors don't design for. They build products optimized for the SOC team that can absorb a 90-day tuning period and dedicate an FTE to dashboard management. In our experience, mid-market analysts don't have 90 days. They have today's queue, and it's already full.
Why False Positives Destroy Analyst Trust Faster Than False Negatives
Here's the thing most alert systems get wrong: they optimize for recall over precision, because missing a real threat is scary. Generating a false positive just wastes analyst time. Right?
Wrong. The math on false positives is worse than it looks at the individual alert level. An analyst who dismisses 200 consecutive false positives before encountering one real threat develops a dismissal reflex. That reflex is rational under the circumstances. It is also the exact mechanism by which real threats get missed.
We've found that analysts are more likely to miss a true positive after a high-false-positive session than after a low-volume session. Not because they're negligent. Because the cognitive cost of sustained skepticism in a noisy queue is high, and the brain takes shortcuts it doesn't announce. The relevant number isn't the false-positive rate in isolation. It's the cumulative false positives before the analyst encounters the next true positive. If that number regularly exceeds 50, you have a trust problem that volume management alone won't fix.
Real talk: the answer isn't training analysts to stay vigilant against their own cognitive adaptation. That's not a systems solution. The answer is reducing the reconstruction work so that each alert decision costs less cognitive effort, not more.
Evidence Summaries: What the Change Actually Looks Like
An evidence summary is not an alert with a risk score attached. A risk score is still asking the analyst to do the reconstruction. It's just giving them a number as a starting point instead of raw log lines.
A genuine evidence summary presents the decision in pre-structured form: what the email was, who sent it, whether that sender has appeared in this recipient's communication history, what the LLM evaluation found about the message's intent, and which specific indicators triggered the alert. The analyst reads one paragraph. They approve or dismiss. They move on.
In the Phishaver queue, each alert surfaces with exactly that structure. A single paragraph covers sender reputation and relationship context, LLM-evaluated message intent, any payload or link indicators, and the combination of signals that triggered the flag. An analyst can read it in under 90 seconds. That's not a best-case demo scenario. That's the median review time across our active customers.
The time arithmetic shifts considerably. At 90 seconds per alert instead of 10 minutes per alert, a four-analyst team processing 400 daily alerts spends roughly 600 analyst-minutes on triage, not 4,000. Ten hours versus sixty-seven. The difference between a team that handles the volume and a team that structurally cannot.
Practical note: the 90-second figure assumes the summary is doing the reconstruction work, not just reformatting the same raw data in a different layout. A dashboard that shows the same log fields in a card grid isn't an evidence summary. It's a UI change.
Integrations Matter: Splunk, PagerDuty, and the Alert Routing Problem
Evidence summaries only change the math if they show up where analysts are already working. A separate console that requires a context switch introduces its own friction. Analysts triaging in Splunk or responding to PagerDuty pages don't want a third tool to check. They want the evidence in the workflow they already have open.
This is why the integration question is not optional. Phishaver pushes structured evidence summaries directly into Splunk as enriched events and into PagerDuty as formatted alert descriptions. The analyst sees the one-paragraph summary in the tool they already have open. No tab switching. No re-authentication. No "open in platform" redirect that drops their current context.
Access control matters here too. The SOC queue operates under Okta SSO, which means the same identity governance your organization uses for everything else controls who sees what in the alert queue. Analysts don't manage a separate credential. Permissions inherit from existing Okta groups. In mid-market companies where IT and security roles overlap, the access model stays coherent even when the org chart gets complicated.
What to Measure After You Change the Model
Shifting from raw-alert triage to evidence-summary triage changes which metrics actually matter. Mean time to triage per alert is the obvious starting point, but it isn't sufficient on its own.
In our tracking, the metrics that best predict sustained SOC health after an evidence-summary implementation are:
- True positive rate on dismissed alerts — how often a dismissed alert turns out to be a real threat in retrospect. A well-tuned evidence queue should show near-zero dismissal errors on high-confidence alerts.
- Analyst review distribution — whether all analysts are reviewing at roughly similar rates, or one analyst is carrying the queue while others lag. Uneven distribution usually means one analyst internalized the model and the others haven't yet.
- Time from alert to disposition — not triage time alone, but the full cycle from alert generation to analyst decision. This surfaces delays in the routing layer that evidence summaries don't fix on their own.
- False positive escalation rate — how often analysts send alerts to secondary review that turn out to be false positives. Persistently high escalation on false positives means the summary isn't providing enough context for confident dismissal.
Honestly, most mid-market SOC teams aren't tracking any of these. They're watching total alert volume and whether they're keeping pace with the queue. That's survival-mode measurement. The metrics above are sustainability-mode measurement. The difference matters when you're making a resource case to leadership and need numbers that reflect operational health rather than just workload.
The Staffing Conversation This Changes
Evidence summaries don't eliminate the need for skilled analysts. They change what those analysts spend their time on. Worth stating clearly, because we've seen the efficiency numbers misused as a justification for keeping a team deliberately understaffed.
What evidence summaries remove is reconstruction overhead from routine triage. That frees analyst capacity for the work that actually requires human judgment: investigating confirmed threats, running threat hunts, tuning alert rules to reduce noise, handling incident response. A four-analyst team running an evidence-summary queue can do all of those things. A four-analyst team drowning in raw reconstruction cannot reach them at all.
The internal benchmark we use: if your analysts are spending more than 40% of their time on routine triage and less than 20% on proactive investigation, the triage model is consuming capacity that belongs elsewhere. That ratio is fixable without adding headcount. But it requires changing the model, not just the staffing number.
Four analysts processing 400 alerts a day is a solvable problem. Seriously. It just requires that each alert arrive as a decision, not as a reconstruction project waiting to happen.