Routing Stack

Seven stages, one pipeline: capture to assigned rep in under ten seconds, with the config and the failure behaviour written down.

Every form fill, ad conversion and chat message goes through the same seven stages: validation, dedupe, enrichment, scoring, routing and assignment. This pack is the buildable version of that pipeline. Stage by stage, with the keys you set and the way each stage fails.

One unified webhook endpoint accepts form fills, chat transcripts and ad conversions. Payloads get normalized and schema-checked before anything else happens. From there the lead moves left to right, then writes back and notifies.

Plain module sequence. Treat it as the shape of the build. The config above is what you copy into it. Put error handlers on every module that writes.

Inbound capture (source to your endpoint)

Normalized internal contract (every source maps here)

Post-stage record (what the CRM receives)

Measured per stage rather than guessed at the end. Each stage gets a hard ceiling. If a stage blows its ceiling, that is the alert.

Headroom to the ceiling is deliberate. It absorbs one retry cycle and a cold enrichment cache without failing the promise.

Thresholds are configuration. Set them before launch, write down who they page, and review them after the first month of real traffic.

Weekly review checklist

• Every dead-letter item from the week has an owner and a decision: replay, fix, or drop.
• Duplicate merges reviewed, each one logged with its inputs.
• Escalations counted, with the rule that fired each time.
• Scoring model inputs still match the fields you capture.
• Owner roster checked against active users in the CRM.
• Latency budget reviewed stage by stage.

• Capture and validation. One endpoint, one contract, rejects visible.
• Dedupe. Search before create beats every downstream cleanup.
• Assignment and notification. Even a crude router beats no router.
• Failure path. Dead-letter queue, correlation log, alerts that page.
• Enrichment and scoring. Add once the boring layers are trusted.

What happens next. When the pack is not enough, the same systems ship as client engagements. The work covers speed-to-lead builds, CRM and API workflow overhaul, lead qualification systems and monitored production workflows.

I wrote this routing layer for a firm running twelve intake channels across three offices. You get the contract payload and the priority order. The decision object comes out of them, and the failure queue catches whatever stays unresolved.

This is the routing layer I rebuild so every lead that reaches your CRM has an owner attached to it. Same contract, same priority order, same decision object I install for clients. Work the sections in order. The order is the architecture.

Every unplaced lead surfaces in the failure queue with its reason. The form fires, the CRM creates a contact, the dashboard shows activity. Then the owner field stays empty, the deal opens in another pipeline, and the follow-up sequence waits on a routing field that arrived as null. The failure queue catches it before the follow-up window closes.

I wrote this layer for Meridian Legal Group, a firm running twelve intake channels across three offices. Their HubSpot instance had become a data graveyard, with duplicate contacts in the thousands, leads assigned at random, and SLA timers that ran on paper. The rebuild starts one layer below the alerts. It starts with the contract.

Routing starts before the CRM. Every source, from a Typeform to a chat widget to a referral spreadsheet, has to land in one stable payload. The routing engine routes only what the form sends. Lock the field names first. Everything downstream keys on those names.

Table 1A · Routing contract fields (fill the gaps)

Stable API names that outlast display labels. The CRM UI label changes whenever someone renames a property. The contract stays fixed.

The payload every source has to produce

One shape, regardless of where the lead entered. Tally can feed it, Meta Lead Ads can feed it, a manual import can feed it. The routing engine receives the same clean structure every time.

Table 1B · Source audit: does each channel honour the contract?

Walk every intake channel and mark what it sends. A channel that cannot fill a required field goes to the failure queue path in Section 5.

Most stacks have five routing rules fighting each other. Territory says one owner, service line says another, the campaign says another, round robin says another. Without a fixed priority order, routing becomes random with extra steps. This is the hierarchy I install. Read it top to bottom. The first rule that matches wins.

Table 2A · The priority hierarchy

Table 2B · Your rule map (fill this in)

List every routing rule currently live in the stack, then assign it a row in the hierarchy. Overlaps become visible the moment two rules claim the same lead.

Rule merge checklist

• One winner per lead: every test case resolves to exactly one owner, one pipeline, one stage.
• Existing customer and open deal sit above every distribution rule: round robin never steals a live relationship.
• Critical severity outranks campaign source: an urgent lead does not wait behind a nurture path.
• Round robin pool contains active users only: a departed rep is not a fallback owner.
• Every rule has a written reason string: the CRM will store it as routing_reason in Section 3.
• Unmatched leads have a destination: the manual review queue is rule 9 by design.

Build the decision before any CRM action runs. The rules engine produces one object against one schema. Whatever executes consumes it, whether that is Make, Zapier, n8n, a HubSpot workflow, a GoHighLevel flow or a custom API layer. The executor does not decide. It carries out a decision that already exists.

Routing decision object schema

Table 3A · Decision object fields

Table 3B · routing_reason templates (fill one per hierarchy row)

Sales needs to know why the lead landed there. A written reason turns a mysterious assignment into an inspectable decision. Use one sentence per row, naming the evidence that fired.

Order matters more than speed here. Deduplicate before assignment, never after. Validate the owner and the pipeline before the write. Send the alert only after the CRM confirms. An alert that fires before the write is a lie the sales team will believe.

Table 4A · Owner and pipeline validation matrix

Table 4B · CRM execution order

Run these in sequence. No step may start before the previous one confirms.

A failed route should never disappear. It lands in a review queue with the raw payload and the decision attempt. The error reason and a replay option sit beside them. This is the section that turns "the lead went missing" into a five-minute lookup.

Table 5A · Failure queue rules

Idempotency key format

One key per source event. The key is what makes a replay safe: same key, same decision, no second assignment. Compute it at the edge and thread it through every write.

Table 5B · Audit trail fields (what every run stores)

Failure policy block

Replay and review checklist

• Every failure lands somewhere visible: raw payload, decision attempt, error reason, named queue owner.
• Replay is idempotent: re-running the same idempotency_key never creates a second owner assignment.
• Max attempts are bounded: a stuck event moves to the dead-letter queue instead of retrying forever.
• Rate limits slow the queue: CRM 429 responses back off instead of dropping payloads.
• Manual review has an SLA: a human reads the queue on a schedule.
• The routing reason is stored with the record: sales can read why the lead landed there without asking ops.

Start here if the pipeline does not exist yet: the Speed-to-Lead Blueprint Pack is the entry blueprint. It covers capture, validation, dedupe, enrichment, scoring, routing and assignment as one pipeline. This kit is the routing layer written out in full.

If duplicates are the real problem: reach for the CRM Automation Repair Kit. Merging duplicate contacts, fixing associations and correcting field maps all sit under routing. Fix the data layer before you add more rules.

For the production build: Fix your pipeline is the engagement that ships the scoring model, the routing layer and the failure queue as one system. The proof is the Meridian Legal Group case study: twelve intake channels, three offices, assignment inside ten seconds.

What happens next. Run the free workflow diagnostic, or read the Meridian Legal Group case study, then decide. When you want the build done for you, the same systems ship as client engagements: routing rebuilds, lead qualification, CRM and API overhaul, and monitored production workflows.

Everything above is yours to read. The workbook adds the empty worksheets, so you fill them in on your own stack with your own owners, fields and failures. It opens in any browser, on any device, and it saves as you type.