Routing rule library for common multi-market patterns

Routing logic looks different across organizations but the underlying patterns are limited. Most multi-market routing rules are compositions of a few core patterns. Knowing the patterns lets the operations team design routing rules cleanly rather than reinventing each one.

Here is the library.

Pattern 1: round-robin within market

The most common pattern. Leads route to the team that owns the market; within the team, round-robin assigns to the next available rep.

When to use: similar-profile reps within the team, similar-profile leads, goal of even distribution.

The rule:

• WHEN lead.created
• WHERE market = X
• THEN assign(round_robin(team:X-inside-sales))

Failure mode: assigns to unavailable reps if the platform does not check availability. Always pair with an availability check.

Pattern 2: capacity-weighted within market

Better than naive round-robin when reps have different load. The rotation favors reps with more remaining capacity.

When to use: meaningful capacity variation across reps, different deal sizes within the same team, mix of senior and junior on the team.

The rule:

• WHEN lead.created
• WHERE market = X
• THEN assign(weighted_round_robin(team:X-inside-sales, weight_by:remaining_capacity))

Capacity is computed from active opportunity count, untouched lead count, and PTO status. The platform handles the computation.

Failure mode: capacity data has to be accurate. If your platform does not know a rep is on PTO, the weighting is wrong. Use this pattern only when the platform has reliable capacity data.

Pattern 3: vertical-specialized routing

When reps within the same market specialize by vertical (healthcare specialist, financial services specialist, manufacturing specialist), routing should consider the lead's vertical.

When to use: teams with vertical specialization, leads where vertical is detectable at ingestion.

The rule:

• WHEN lead.created
• WHERE market = X
• THEN assign(specialist_or_generalist(team:X, vertical:lead.vertical))

The function tries to find a specialist for the lead's vertical; if none available, falls back to a generalist on the team.

Failure mode: the vertical detection has to be reliable. If you cannot detect vertical at ingestion, do not pretend you can. Skip this pattern or route to generalists.

Pattern 4: account-based routing

When the lead's prospect company already has an account-owner relationship (a rep has been working that account), the lead routes to the existing owner regardless of round-robin.

When to use: enterprise sales with named accounts, account-based marketing motion.

The rule:

• WHEN lead.created
• WHERE lead.company_id matches existing account
• THEN assign(account_owner(lead.company_id))

If no existing account-owner, fall back to standard market-routing.

Failure mode: account matching has to be conservative. Aggressive matching assigns leads to the wrong owner. Use strong match keys (canonical company ID, normalized domain).

Pattern 5: partner-led with deal registration

When a partner has registered the deal, the lead respects the registration. Direct sales does not "claim" the lead away from the partner.

When to use: any organization with a meaningful partner channel.

The rule:

• WHEN lead.created
• WHERE lead.partner_registered = true
• THEN assign(channel_team) + tag(partner_owned:lead.partner_id)

The lead goes to the channel team for partner coordination. The partner is recorded as the primary relationship.

For non-registered leads, fall back to standard market routing.

Failure mode: direct sales sometimes resents the constraint and tries to bypass. The platform should refuse: an assignment that contradicts deal registration fires an audit event and a manager review.

Pattern 6: qualification-gated routing

For regulated industries (financial services, healthcare, insurance), the lead should not route to sales until compliance pre-checks complete.

When to use: regulated industries where sanctions screening, KYC pre-check, or compliance review is required before outreach.

The rule:

• WHEN lead.created
• WHERE compliance_status != cleared
• THEN route_to(compliance_review_queue) + hold(sales_routing)

Once compliance clears, the lead unblocks and the standard market routing fires.

Failure mode: the compliance check has to be reliable and fast. A slow compliance check creates a backlog and frustrates the field.

Composing the patterns

Real routing rules compose multiple patterns:

Composed example: multi-market enterprise with verticals and partners.

1. WHEN lead.created
2. WHERE lead.partner_registered = true: route to channel team (Pattern 5).
3. ELSE WHERE lead.company_id matches existing account: route to account owner (Pattern 4).
4. ELSE WHERE market = X AND vertical = V: route to specialist (Pattern 3).
5. ELSE WHERE market = X: capacity-weighted round-robin (Pattern 2).

The composition is layered. Each layer is its own pattern. The platform evaluates in order; the first matching layer wins.

Routing data requirements

Each pattern requires specific data:

• Round-robin: team membership.
• Capacity-weighted: active opportunity count, untouched lead count, PTO status.
• Vertical-specialized: rep vertical specialization, lead vertical detection.
• Account-based: company ID, existing account-owner relationships.
• Partner-led: deal registration data.
• Qualification-gated: compliance check results, integration with screening systems.

A routing pattern that does not have its data is theater. Make sure the data is reliably populated before relying on the pattern.

Audit and versioning

Every routing rule should be:

• Documented (what does it do, why does it exist).
• Versioned (when the rule was created, when last modified, by whom).
• Audited (every routing decision records the rule version that fired).

Six months from now, a dispute about why a lead was assigned to Rep X is resolved by reading the audit. Without versioning, the dispute has no answer.

Operationalizing

Three things to do:

1. Document your routing rules. One page per rule: what triggers it, what it does, what fallback applies.
2. Configure in the platform. Express the rules as workflow rules in the platform's engine.
3. Test in shadow mode. Before turning a new rule on, run it in shadow for two weeks comparing outcomes to the existing rule. Only cut over after validation.

For how MegatronLead's workflow engine expresses these patterns, see workflow automation and how to route leads by market and team.