Skip to lesson
Exit
GTM Systems Design1 / 3

2 min lesson

SLAs and escalation

Start at the first move in "SLAs and escalation" and carry it through to the proof.

Step 1 of 3

SLAs and escalation

Assignment without a clock is a wish. An SLA defines what "actioned" means and what happens when it isn't met.

  1. 1Define the SLA. A 75+ lead gets a first touch within, say, 15 minutes during business hours. The number is the team's; the mechanism is yours.
  2. 2Track the clock. Stamp assigned-at and first-touch-at, so the SLA is measurable and not a feeling.
  3. 3Escalate on breach. No touch in time, reassign to a backup or notify a manager. The lead never just sits.
  4. 4Surface it. A breach should page or post to a channel before a stakeholder notices the lead went cold.
Learn more

Full explanation

Permissions and data access

Permissions and data access

Across startup, ecosystem and partnership programs, not everyone should see or act on every lead. Permissions are part of the routing design, not an afterthought bolted on later.

  • Scope visibility by program and segment, so a partnerships lead isn't visible to the whole sales floor.
  • Separate who can see a record from who can act on it; read access is cheaper to grant than write.
  • Keep partner-sourced data walled appropriately when a data-sharing agreement requires it.
  • Make permission grants data-driven (role + program membership), not hand-edited per user, so they scale with the team.

Fallbacks and dead-letter handling

Some leads won't route cleanly: no matching territory, ambiguous segment, a tie no rule breaks. Borrow the dead-letter queue from messaging systems - an unroutable lead goes somewhere visible, never nowhere.

Unowned segment

No territory matches the account.

Route to a default queue a human triages and flag the gap in the ownership map.

Ambiguous match

Lead could belong to two accounts.

Hold for review rather than guess; a wrong owner is worse than a short delay.

Learn more

Full explanation

Auditability

Auditability

When a rep asks "why did I get this lead?" you need an answer in seconds. Log every decision the router makes.

One structured log line per routing decision - replayable and debuggablejson
{
  "lead_id": "ld_8f2a",
  "account_id": "ac_311",
  "score": 82,
  "band": "route_now",
  "strategy": "account_owner -> territory -> round_robin",
  "matched_rule": "account_owner",
  "assigned_to": "rep_kim",
  "sla_minutes": 15,
  "decided_at": "2026-06-15T14:03:22Z",
  "trace_id": "rt_5d9c"
}
Watch out

"It's in the CRM somewhere" is not auditability. If you can't reconstruct exactly which rule fired and why a specific lead landed where it did, reps stop trusting routing and route themselves - and the system you built becomes shelfware. A structured decision log per lead is the cheap insurance.

QA new high-scoring lead arrives at a company that's already an open opportunity owned by Rep A. Pure round-robin would assign it to Rep B, next in rotation. What's the right design and why?