How to Automate Phishing Report Triage

Your phishing report button works. That is the problem. Every time someone clicks it, a message lands in a shared mailbox and waits for a human to open headers, copy URLs into a scanner, decide whether it is a real threat, open a ticket, and tell the reporter something useful. Do that thirty times a day and your security team stops doing security. When you automate phishing triage, you move the mechanical part, the fetching, extracting, enriching, classifying, and ticketing, onto a workflow that runs in seconds, and you keep the judgement calls where they belong: with a person.

This guide walks through building that workflow in Skopx, where you describe the automation in plain English in chat instead of dragging boxes around a canvas.

What manual phishing triage actually costs

The cost is rarely one big number. It is a hundred small ones.

A single report typically involves: opening the reported message, viewing original headers, checking SPF, DKIM and DMARC results, noting the sending domain and reply-to mismatch, extracting every URL and expanding shorteners, hashing attachments, checking those indicators against a threat intelligence source, searching the mail platform for other recipients of the same message, deciding a verdict, opening a ticket, and replying to the reporter so they know clicking the button was worth it.

Most of those steps have no discretion in them at all. A header is a header. A hash is a hash. Yet each one costs a context switch, and context switches are what actually drain an IT or security team. The second cost is inconsistency: the same message triaged by two analysts on two different days produces two different write-ups, which makes your reporting useless later.

The third cost is the quiet one. When triage is slow, people stop reporting. A queue that takes two days to answer trains employees that the button does nothing, and the one report that mattered arrives late or never.

Why automate phishing triage before you hire more analysts

Adding headcount to a queue of repetitive lookups scales the cost linearly and scales the inconsistency with it. Automation attacks the shape of the problem instead. The point is not to have a robot decide whether your CFO is being impersonated. The point is that by the time a human looks at the report, every fact they would have gathered manually is already gathered, formatted the same way every time, and attached to a ticket.

There is a second reason to automate phishing triage early: it produces structured data. Once every report flows through the same workflow, you have a consistent record of sending domains, verdicts, and reporters, which is what you need to spot a campaign hitting five people in one department rather than five unrelated annoyances.

The workflow design

Start with the simplest version that produces value. A webhook trigger fires when your report button or mail rule forwards a message. The workflow fetches the message, extracts indicators, enriches them, asks an AI step for a classification, and opens a ticket with everything attached.

Basic phishing triage

Report button fires

Fetch reported message

Extract indicators

Enrich URLs, hashes

AI classify report

Create triage ticket

Post to security channel

Skopx gives you exactly three triggers: manual, schedule, and webhook. For phishing triage, webhook is the right one, because you want the workflow to run the moment a report arrives rather than on a timer. Skopx generates a unique URL with a per-workflow secret, and your mail rule, report add-in, or SOAR-adjacent forwarder posts to it.

If your reporting path cannot post a webhook, the fallback is a schedule that polls the phishing mailbox. Schedules run at a 15 minute minimum, hourly, daily, or weekly in the timezone you pick. Fifteen minutes is fine for triage. Just know that if a run is missed and more than the two hour grace window passes, Skopx records it as failed rather than firing it late, which is the honest behaviour you want in security tooling: a silent late run is worse than a visible failure.

What to automate and what stays human

This is the part most phishing automation guides get wrong. They wire the workflow straight into blocking, quarantining, and auto-replying, then act surprised when an automated verdict pulls a legitimate vendor invoice out of the finance team's inbox.

Skopx has no human-approval step, and that constraint is genuinely useful here. It forces the correct design: the workflow prepares and notifies, a human acts. Anything that touches a mailbox other than the reporter's, blocks a domain, disables an account, or sends a customer-facing message gets packaged up and routed to a person with a one-click path to execute it. The workflow never pulls the trigger itself.

The same principle shows up in the sibling workflows: prepared decisions with a named human owner beat automatic execution. See How to Automate Access Reviews Without Rubber Stamping for the access-grant version of this argument, and How to Automate Vulnerability Triage and Assignment for the same pattern applied to scanner output.

Build it in Skopx to automate phishing triage step by step

Skopx workflows are built by describing them. There is no builder canvas. You connect the tools first, then say what you want in chat, and Skopx assembles the trigger, the steps, and the data expressions between them.

Step 1: connect the tools. In Skopx, connect your mail platform, your threat intelligence source, your ticketing system, and your chat tool. There are nearly 1,000 integrations available, so the usual suspects for a security stack are covered, but check yours before you design around it.

Step 2: add your provider key. AI steps run on your own API key with zero markup. Without a key on the account, the AI classification step will not run, so add it before you build.

Step 3: describe the workflow. Open chat and write one sentence that contains the trigger, every step, and the destinations:

When a webhook fires from our phishing report button, fetch the reported message from our mail platform using the message ID in the payload, extract the sending domain, reply-to address, SPF and DKIM results, every URL and any attachment hashes, look each URL and hash up in our threat intelligence tool, then use an AI step to classify the report as confirmed malicious, suspicious, or benign with a two sentence rationale and a confidence value, create a ticket in our SECOPS project with the classification in the title and all extracted evidence in the description, and post a summary with the ticket link to our #security-triage channel.

Step 4: check the generated steps. Skopx builds this from four step types: integration actions on your connected tools, AI steps, if/else conditions, and field transforms. Confirm the data expressions point where you expect. The fetch step should read {{ trigger.message_id }}. The enrichment step should read {{ steps.extract.output.urls }}. The ticket description should reference {{ steps.classify.output.verdict }} and {{ steps.classify.output.rationale }}. If an expression is pointing at the wrong step, say so in chat and Skopx rewires it.

Step 5: test with the manual trigger. Run it by hand against a known-benign test message first, then a known-bad sample from a sandbox. Every run is inspectable: each step records its real output, its duration, and its exact error text. Read the actual output of the extract step rather than trusting that it worked.

Step 6: pin down the AI step. Tell it to return a fixed set of verdict values and nothing else. Free-form verdicts break the condition you are about to add.

Step 7: add the branch. Once the linear version is stable, add the condition that separates urgent from routine.

Phishing triage with escalation

maliciouslow risk

Report button fires

Enrich indicators

AI classify report

Malicious verdict?

Prepare containment pack

Page on-call analyst

Log and acknowledge

Conditions support the operators you would expect: equals, contains, greater_than, is_empty and similar. A verdict equals "confirmed malicious" check, or a confidence greater_than threshold, is enough to split the paths.

The containment pack is the honest part of this design. It is a ticket or message containing the affected recipient list, the exact indicators, and the prepared quarantine action, sitting in front of a named human. The workflow does not quarantine anything. For the paging half, How to Automate Incident Alerting and On-Call Handoffs covers routing that escalation to whoever is actually awake.

Keep an eye on the limits while you build: workflows are acyclic with no loops, and cap at 20 steps. Twenty is plenty for triage if you resist the urge to enrich seven different ways. If you need more, split it into a second workflow triggered by a webhook from the first.

How to tell it is working

Look at the run history, not your feelings about the queue.

• Every run has a verdict. If AI steps are returning empty or malformed verdicts, the condition is silently sending everything down one branch. Open a few runs and read the classify step output directly.
• Enrichment steps are not quietly failing. A rate-limited threat intel API returns an error that Skopx records exactly. If half your runs show that error, your verdicts are being made on thin evidence.
• Time from report to ticket is measured in seconds. The run duration on each step tells you where the time goes if it is not.
• Analysts are editing verdicts, not writing them. If humans rewrite the AI rationale every time, tighten the prompt in the AI step.
• Reporters get acknowledged. A receipt with a ticket number, not a verdict, keeps the reporting habit alive.

Give it two weeks, then compare the tickets your workflow produced against what your team would have written. The gap tells you exactly which step to improve.

Common mistakes

Auto-quarantining on an AI verdict. The single fastest way to lose trust in security automation is to delete a legitimate message. Prepare, notify, let a person execute.

Telling the reporter it was safe. An automated all-clear on a message that turns out to be a real spear-phish is the worst possible outcome. Acknowledge receipt only.

Free-form AI verdicts. If the classification step can return "probably fine?" your condition will not match anything. Constrain the output values.

Enriching before extracting properly. Garbage URLs in means garbage reputation data out. Test the extract step against real reports with tracking links, shorteners, and quoted-printable encoding.

Building all 20 steps at once. Get five steps working end to end, then add. Debugging a 20 step workflow you have never run is miserable.

Ignoring failed schedule runs. If you are polling a mailbox rather than using a webhook, a failed run means reports sat unread. Treat the failure record as an alert, not noise.

No dedupe. Ten people report the same campaign and you get ten tickets. Add a condition that checks for an existing ticket on the same sending domain before creating a new one.

Frequently asked questions

Can Skopx quarantine or delete the phishing email automatically?

It could technically call that action on a connected mail platform, but you should not design it that way. Skopx has no human-approval step, so there is no safe pause between an automated verdict and a destructive action. The correct pattern is to prepare the containment details and route them to an analyst who executes. That is a design choice, not a workaround.

What if my phishing report button cannot call a webhook?

Use a schedule instead. Poll the phishing mailbox at the 15 minute minimum and process anything unread. Just remember that a run missed beyond the two hour grace window is recorded as failed rather than fired late, so watch your run history.

Do I need my own AI provider key?

Yes. AI steps run on your own provider key with zero markup, so the classification step will not execute without one on the account. Integration actions, conditions, and transforms run without it.

How many reports can one workflow handle?

The constraint is your integrations, not Skopx. A workflow is capped at 20 steps and must be acyclic, but each webhook call runs independently. If your threat intelligence provider rate limits you, that error shows up in the run record with its exact text, which is where you will see the ceiling first.

What does this cost?

Solo is $5 per month, Team is $16 per seat per month, and Enterprise is $5,000 per month. Every plan bills from day one. Most security teams want Team so that on-call analysts share the same run history and connected tools.

Start with one report

Pick the last phishing report your team triaged by hand. Write the plain-English sentence, connect the four tools it touches, and run it manually against that exact message. When the ticket appears with every indicator already attached, you will know what to automate next. Build it at skopx.com/workflows.