Skip to main content
DoneThat

AI Adoption GuideLegalRequest

Risk tier assignment at intake

ML model scores incoming request by deal value, counterparty, and jurisdiction before legal touches it.

Legal processRequestAssessDraftNegotiateApproveSignStoreDispute

By Don, DoneThat’s AI coach · updated

Overview

Legal teams lose hours on requests that look urgent in email but are routine on paper, and on the reverse: low-priority tickets that carry hidden exposure. Risk tier assignment at intake applies a model at submission time so the first human view is already ranked by structured signals, not subject line tone or who sent the Slack ping.

The goal is quality at the front door. A tier is not a routing shortcut around legal; it is a consistent read on value, counterparty, and jurisdiction so reviewers spend attention where mismatch cost is highest. When any input is absent, the tier leaves that slot empty rather than guessing, and legal still opens every request before work proceeds.

Signals the model uses

Three inputs drive the tier. Each appears explicitly on the intake record so reviewers can confirm or override with context the model did not see.

Deal value. The model maps amount (and currency, when normalized) to internal bands aligned with approval policy: thresholds for manager sign-off, legal-only review, executive involvement, or external counsel. Value alone never sets the final tier; it anchors severity when other flags are quiet.

Counterparty risk. Counterparty identity is matched against firmographic and compliance data. Dun & Bradstreet supplies business verification, financial stress indicators, and hierarchy linkage so "Acme LLC" is not confused with a similarly named entity. Refinitiv (World-Check and related datasets) supports sanctions, PEP, and adverse-media style screening where policy requires it. The tier cites a counterparty risk flag (clear, elevated, or restricted per your taxonomy), not a opaque score, so legal can see what triggered elevation.

Jurisdiction. Governing law, place of performance, and data residency hints feed a jurisdiction risk flag. Some teams maintain an allow list (home country plus standard commercial hubs), a watch list ( emerging regulatory change, unfamiliar dispute forums), and a restricted list (export control, blocking statutes, or non-negotiable policy exclusions). The model assigns jurisdiction contribution to the tier from that matrix, not from geolocation of the submitter.

Where intake forms capture only one of these (value in the ERP hook but counterparty as free text), enrichment jobs backfill before tiering when identifiers exist; otherwise the corresponding tier line stays empty.

How the tier is computed and shown

Architectures vary, but a practical pattern is a rules-plus-ML stack: hard stops (sanctions hit, restricted jurisdiction) cap the tier regardless of value; a gradient model or weighted table combines the remaining signals into Low, Medium, High, or Critical labels your team defines.

The displayed tier is always accompanied by citations:

  • Value: band and raw amount (e.g., "Band 3 — USD 420,000")
  • Counterparty: flag and match confidence (e.g., "Elevated — D&B linkage 0.91, Refinitiv review queue")
  • Jurisdiction: flag and rule id (e.g., "Watch — governing law SG, policy rule JUR-12")

If deal value was not provided, the value line is blank. Same for counterparty when no confident match exists, or jurisdiction when governing law is missing. The overall tier may still compute from available fields, or show "Incomplete — legal to classify" depending on policy; either way, empty slots signal what intake must fix next time, not silent defaults.

This transparency matters for audit. When someone asks why a request jumped the queue, the answer is in the tier card, not in model weights legal never sees.

Fitting intake platforms and adjacent automation

Triage usually lives in a CLM or service portal. Ironclad and similar CLMs can run tier logic on workflow start: webhook from the intake form, enrichment call-out, tier write-back to the request object, then queue rules send High/Critical to senior reviewers or parallel compliance.

ServiceNow Legal Service Delivery is a common entry point when business users file "need a contract" tasks. A mid-tier integration pattern stores tier and citations on the task record, uses flow designer for hard-stop routing, and syncs to CLM when a matter converts to a draft. Keeping tier assignment in the system of entry avoids re-keying and preserves timestamps for metrics.

Downstream, tier at intake complements clause risk classification on the draft document. Intake tier answers "should we worry before we read?"; clause models answer "what in the text triggers playbooks?" Both feed quality, at different lifecycle moments. Teams should not double-count the same risk (jurisdiction flagged at intake and again in boilerplate) without clear precedence rules.

Measuring whether tiering improves quality

Track leading indicators tied to outcome quality, not just speed:

  • Percentage of requests with all three citations populated within 24 hours of submit
  • Override rate by tier (High override on Low tiers suggests model drift; Low override on High tiers suggests good calibration)
  • Time to first qualified legal touch on Critical vs Low (should separate without starving Low entirely)
  • Rework rate: requests that change tier after initial assignment due to missing data at intake

Pair these with auto-priority scoring metrics only where SLA and risk tier align; when they diverge, policy should state whether risk or SLA wins for queue ordering.

Risk tier assignment at intake turns scattered intake fields into a cited, review-ready classification. Value, counterparty, and jurisdiction each earn a line on the record; gaps stay visible; Ironclad, Dun & Bradstreet, Refinitiv, and ServiceNow are typical anchors in the stack. Legal keeps judgment on every file, but spends it where the tier, and its citations, say the exposure actually lives.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first