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

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.