How Strkr's lead routing actually works

Lead routing is one of the highest-leverage sales ops projects any team can run. Speed-to-lead compounds across every deal, every quarter. Harvard Business Review research found teams that contact leads within 1 hour convert 7x higher than those contacting after 24 hours. The delta between good and bad routing is almost entirely about the first hour after capture.

This post is a product tour of how Strkr’s lead routing actually works: the mechanism, the configuration surface, the fallback shape, and the audit log that makes it debuggable in production.

The design target

Strkr’s lead routing was designed around one principle: a sales ops lead at Series A should be able to build the full lead routing engine of the business without a developer, without an admin certification, and without a dedicated routing tool. Three structural consequences:

1. It runs on the same no-code flow builder as the rest of the automation surface. If you know how to build a flow, you know how to build routing.
2. It covers the full multi-criteria shape on every paid tier. Boolean logic, capacity awareness, fallback chains, auto-notification, audit log. No tier gating.
3. It fires in seconds, not minutes. Lead capture to assignment to notification is sub-second in typical setups.

How it works

Every lead routing flow follows the same shape:

1. Trigger: lead captured

The flow fires on either an inbound webhook (a form submission from your website, a portal, a trade show tool) or a record-create event (a lead added manually, imported, or created by another flow). The lead data lands in the flow as context.

2. Enrichment (optional)

If the inbound data is thin (just email and name), the flow can enrich before routing. Look up the account by email domain, call an enrichment API (Clearbit, Apollo, ZoomInfo), and merge the enriched data onto the lead record before routing decisions fire.

3. Branching logic

The flow’s branch tree evaluates assignment criteria. Typical criteria include:

• Firmographic: account.employee_count, account.industry, account.region, account.annual_revenue, account.tier
• Behavioral: lead.source, lead.utm_campaign, lead.form_name, lead.lead_score
• Contextual: current_user.role, current_time (for business-hours routing), lead.priority
• Related-record: lead.account.existing_opportunity_count, lead.account.last_touch_date

Branches combine with AND / OR / NOT boolean logic. A single branch can express “enterprise lead” (amount estimate > $50K OR employee count > 500) AND “regulated industry” (industry in Healthcare, Finance, Government) AND “not currently owned by anyone” (lead.owner is null).

4. Pool selection and capacity-aware round-robin

Each branch selects a rep pool and an assignment rule. Pools are configured lists of reps (by role, team, territory, or explicit membership). Assignment rules include:

• Round-robin: each rep in the pool gets the next lead in rotation
• Weighted round-robin: some reps get a higher share than others (useful for new hires ramping, or performance-based distribution)
• Capacity-weighted: reps with fewer open leads get prioritized until the pool is balanced
• Explicit cap: reps with more than N open leads are skipped
• Shortest response time: the rep with the fastest historical first-touch time gets the lead

Any combination works. A pool can be capacity-weighted with a cap of 50 open leads, weighted so new hires get 1.5x the standard share, round-robin within the eligible subset.

5. Fallback chain

If no rep in the target pool is eligible (all over cap, all out of office, all offline), the flow cascades to the next pool in the fallback chain. The default pattern:

• Target pool (e.g., enterprise AE pool)
• Secondary pool (e.g., senior AE pool, used as backup)
• Manager queue (if everything else fails, the manager gets it)
• Catch-all queue (if even the manager is unavailable, the lead lands in a shared queue)

Leads should never land in nobody’s hands. The fallback chain is what guarantees that.

6. Auto-notification

Once assigned, the flow fires notifications on the configured channels for that rep. Standard options:

• In-app: notification appears in the rep’s Strkr inbox
• Slack: DM or team channel post, configurable per rep
• Email: notification sent via Strkr’s email layer
• SMS: text message via the Messaging module
• Mobile push: if the rep uses the Strkr mobile app

Reps configure their preferred channels in their settings. The flow respects those preferences, so one rep gets Slack while another gets SMS, with no change to the routing flow itself.

7. SLA timer

The flow starts an SLA timer per lead with a configured duration (default: 1 hour for inbound, 4 hours for other sources). If the rep has not touched the lead within that window, the flow fires an escalation: notify the manager, reassign to the next rep in the pool, or both.

8. Audit log

Every assignment writes a row to the lead’s audit log. The row includes the rule name that matched, the branch criteria that evaluated, the pool selected, the eligibility checks that ran, the fallback chain traversed (if any), the final rep assigned, the timestamp, and the SLA timer configured.

“Why did this lead go to Sarah?” is a two-click answer. Open the lead’s audit log, read the row.

Configuration example

A real configuration for a mid-market B2B SaaS team:

Flow: Inbound Lead Routing
Trigger: webhook /inbound-lead

Action 1: Enrich via Clearbit (company_size, industry, revenue)
Action 2: Create or update account by email domain

Branch 1: ENTERPRISE
  Condition: account.employee_count > 500 OR estimated_amount > 50000
  Pool: enterprise_pool
    Rule: capacity-weighted round-robin, max 50 open leads
    Fallback: senior_ae_pool → sales_vp
  Notify: Slack + email, SLA 1 hour

Branch 2: REGULATED INDUSTRY
  Condition: account.industry IN ["Healthcare", "Finance", "Government"]
  Pool: regulated_pool
    Rule: round-robin, max 40 open leads
    Fallback: enterprise_pool → sales_vp
  Notify: Slack + email, SLA 2 hours

Branch 3: FALLBACK (SMB)
  Condition: all other
  Pool: smb_pool
    Rule: weighted round-robin (new hires at 1.5x), max 60 open leads
    Fallback: smb_manager_queue
  Notify: Slack + email, SLA 4 hours

On SLA breach: escalate to manager, mark lead as "touch-overdue"

Three branches, three pools, three SLA tiers, cascading fallbacks everywhere. Configured in the flow builder in about 30 minutes.

What gets exposed in the UI

Four surfaces where routing is visible:

1. The flow builder

Where routing flows are configured. Visual branch tree, condition editor, pool picker, fallback chain editor, notification channel picker, SLA configuration.

2. The lead record

Shows the assignment history: who the lead was assigned to, when, by which rule, what the SLA deadline is, whether SLA was met or breached.

3. The team dashboard

Shows real-time pool capacity: how many open leads per rep, how close each rep is to their cap, who is currently receiving new leads based on the active rotation. Managers use this for load balancing conversations.

4. The audit log

The full history per lead. One click from the lead record. Powers compliance review, routing debugging, and “why did this lead get here” questions.

What routing does not do

Three things worth being explicit about:

1. It does not qualify leads

Routing is “who gets this.” Qualification is “is this worth working.” Those are separate problems. Strkr supports lead scoring and qualification frameworks (see Lead qualification framework: BANT, MEDDIC, and when each fits) that run upstream of routing. Routing takes the output.

2. It does not fix bad lead quality

If marketing is sending unqualified leads, routing them faster to the right rep does not help. The lead quality problem has to be solved upstream.

3. It does not replace the manager’s judgment

Managers still have to pay attention to pipeline, coach reps on response time, and balance the team’s workload beyond what automation covers. Routing automates the first-touch assignment; the rest is still management.

How to try it

Lead routing is available on every paid Strkr tier at no gated-feature upcharge. The 14-day free trial covers the full feature so you can build a real routing flow against sample data before any charge. See strkr.io/pricing.

Related reading: CRM with lead routing: capacity, territory, speed covers the broader category, and How Strkr’s no-code flow builder actually works covers the automation surface that routing is built on.

Conclusion

Strkr’s lead routing was built so that a sales ops lead can configure the full engine (multi-criteria branching, capacity-aware pools, fallback chains, auto-notification, SLA tracking, audit log) without a developer or admin certification. Routing is a flow in the no-code flow builder, which means it inherits the same debuggability, visibility, and iteration speed as every other automation in the workspace.

For teams where speed-to-lead is the lever, that structural choice is the difference between routing that works at scale and routing that becomes a maintenance tax.