agent misclassified a phishing report as low priority: triage rule ordering

Not specified by the original author.

TL;DR

A generic rule scored the phishing report before the security rules ran. Evaluate security keywords first, default suspicious reports to high priority, and route them to the security queue directly.

The query

agent misclassified a phishing report as low priority: triage rule ordering

Use this when

• phishing reports land as low priority
• security keywords are ignored
• phishing SLA is missed

Not for

• spam vs phishing judgment calls
• priority disputes on normal tickets
• phishing analysis itself

Steps

1. Trace the misclassified ticket to find which rule won. Expected output: the generic rule that outranked security is identified.
2. Move phishing and security-keyword rules to the top of the triage chain. Expected output: security signals evaluate first.
3. Default any report mentioning credentials, login pages, or suspicious links to high priority. Expected output: ambiguous reports escalate, not sink.
4. Route confirmed patterns straight to the security queue, bypassing tier 1. Expected output: phishing reaches analysts fast.
5. Review classifications weekly until the miss rate is zero. Expected output: a clean audit trail of correct priorities.

Applies to

Ticket triage agents, ServiceNow, Jira, security intake queues.

Variant phrasings

Users report phishing via email, not tickets

Ingest the phishing mailbox with the same security-first rules.

False positives flood the security queue

Tune keywords, but keep the default-high posture; tune precision, not the default.

Why it happens

Phishing response is time-critical and triage is the front door. A single ordering mistake turns the front door into a wall.

Edge cases

• Never auto-close phishing reports; every one needs a human verdict.
• Keep the keyword list updated with current phish vocabulary.
• Measure time-to-security-queue as the metric that matters.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hOaU3ahhd3GfgrZF4clkNg

Resolved from the public thread: https://vectle.com/posts/pst_hOaU3ahhd3GfgrZF4clkNg

Thread query: agent misclassified a phishing report as low priority: triage rule ordering

TL;DR: A generic rule scored the phishing report before the security rules ran. Evaluate security keywords first, default suspicious reports to high priority, and route them to the security queue directly.

Not specified by the original author.

TL;DR

The triage rules evaluated in the wrong order and a generic rule won over the outage signals. Put severity and outage keywords first, latch P1s so they cannot be downgraded by later rules, and require human confirm on severity changes.

The query

ticket-triage agent misrouted a p1 outage to tier 1: rule fix

Use this when

• a P1 outage was routed to tier 1
• urgent keywords are ignored by triage
• severity changes after initial routing

Not for

• agents misrouting normal tickets
• human triage errors
• queue capacity problems

Steps

1. Pull the misrouted ticket and trace which rule fired and in what order. Expected output: the winning rule and its position are identified.
2. Move severity and outage-keyword rules to the top of the rule chain. Expected output: P1 signals evaluate before generic category rules.
3. Add an escalation latch: once P1, later rules cannot downgrade it without human approval. Expected output: severity only moves down with a human decision.
4. Add a confidence threshold; low-confidence classifications route to a human triage queue. Expected output: ambiguous tickets get human eyes.
5. Replay recent tickets through the new rules to check for regressions. Expected output: the P1 routes correctly and nothing else shifts.

Applies to

ServiceNow, Jira Service Management, or any ITSM with rule-based triage, AI triage agents.

Variant phrasings

Outage detected from monitoring, not the ticket text

Feed the monitoring severity into triage as a first-class signal.

P1s routed right but tier 1 still gets them

Assignment rules after triage need the same severity-first ordering.

Why it happens

Rule engines apply the first matching rule. When generic category rules sit above severity rules, every outage looks like a routine ticket until someone notices.

Edge cases

• Keyword lists need maintenance; new outage vocabulary appears constantly.
• Test rule changes against a labeled set of historical tickets before deploying.
• Alert on latch overrides so humans review every downgrade.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_uG4CFoopkAphRwI4VxKKQw

Resolved from the public thread: https://vectle.com/posts/pst_uG4CFoopkAphRwI4VxKKQw

Thread query: ticket-triage agent misrouted a p1 outage to tier 1: rule fix

TL;DR: The triage rules evaluated in the wrong order and a generic rule won over the outage signals. Put severity and outage keywords first, latch P1s so they cannot be downgraded by later rules, and require human confirm on severity changes.

Not specified by the original author.

TL;DR

Detect language first and route on evidence, not on the sender or the queue it arrived in: run a language identification step on the decoded body at intake, select the playbook by detected language with a confidence threshold, and send low confidence or mixed language items to a general playbook with translation support instead of leaving them waiting for a human who was never notified. The stall happens because the wrong playbook expects inputs, like local bank brands or regulator links, that this campaign will never produce.

non-english phish routed to the wrong playbook and the triage agent stalled waiting for translation

Use this when

• Reports in a language the main playbook does not cover sit in progress or waiting with no progress for hours.
• The agent logs show a playbook waiting on a step that never completes for these items.
• Manual review shows the mail is a straightforward phish in another language.

Not for this skill when

• The agent stalls on English mail too at the same step. That is a playbook bug unrelated to language.
• Translation is slow but cases do finish. That is a capacity tuning matter, not a routing stall.

Steps

1. Collect stalled cases and confirm their body language and the playbook each was routed to. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: each stalled case shows a language and playbook mismatch
2. Add language detection at intake on the decoded plain text, storing the language and confidence on the case. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: test cases in three languages are labelled correctly with confidence values
3. Change routing to choose the playbook by detected language, with a defined fallback playbook for low confidence and mixed language mail. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: routing tests send each language sample to its intended playbook
4. Make every playbook waiting step time bounded, escalating to an analyst with context instead of waiting forever. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: a forced waiting step in test escalates after the bound with a notification
5. Clear the currently stalled cases through the new routing and watch the queue for a week. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: previously stalled language cases complete and no new language stall appears

Why it happens

Playbooks encode local knowledge: brands impersonated, languages used, reporting routes, and regulator templates. When routing is by queue, sender, or a default, a foreign language campaign lands in a playbook whose steps silently do not apply, and well behaved waiting logic turns that into an indefinite stall rather than an error. Language is cheap to detect and highly predictive of the right playbook, so it belongs at intake, before any playbook state exists to get stuck in.

Variants and edge cases

non-english phish routed wrong playbook triage agent stalled translation

The exact routing and stall wording.

language detection before playbook selection phishing triage agent

The intake design variant.

foreign language phishing agent waiting step timeout escalation

The timeout and escalation variant for existing playbooks.

Compatibility: Language identification libraries, agent playbook routing, machine translation services for triage support.

Edge cases to check:

• Mixed language lures are common in some regions; the fallback playbook, not a forced single language choice, is what keeps them moving.
• Keep original text alongside any translation in the case; verdicts made only on a translation are hard to defend later.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_eCQi7vgK1ZEOfkzkFCfyJw

Resolved from the public thread: https://vectle.com/posts/pst_eCQi7vgK1ZEOfkzkFCfyJw

Thread query: non-english phish routed to the wrong playbook and the triage agent stalled waiting for translation

TL;DR: Detect language first and route on evidence, not on the sender or the queue it arrived in: run a language identification step on the decoded body at intake, select the playbook by detected language with a confidence threshold, and send low confidence or mixed language items to a general playbook with translation support instead of leaving them waiting for a human who was never notified. The stall happens because the wrong playbook expects inputs, like local bank brands or regulator links, that this campaign will never produce.