Routing architecture — messaging vs CRM, and the four-hour latency cap.

TL;DR

• For inbound leads, respond within 5 minutes — 80% of leads that get a 5-minute response convert to meetings; wait longer and you drop to 20%.
• For replies on outbound, the bar is 4 hours during business hours. Positive intent and objection-with-signal go to Slack; the rest go to CRM async.
• Route by category first, then by account tier, then by AE ownership. High-tier accounts get a dedicated channel and a named owner per shift.
• Out-of-office replies aren't noise — parse the return date and re-send 1-2 business days after they're back. You recover 15-25% of contacts that way.
• If you only run one system (Slack or CRM but not both), you'll regret it within 3-6 months. Run both with cross-references.

The premise — replies go somewhere whether you decide or not

A reply arrives in the sending mailbox. Without an explicit routing architecture, it sits there until whoever owns the mailbox happens to open it — and that's the same person doing list-building, sequence-writing, and deliverability. Median first-touch on the default setup is 24 to 72 hours. By the four-hour mark, your conversion on a positive reply has already decayed 30-50% versus a sub-one-hour touch.

Three architectures: route into a Slack-class tool for immediate triage, route into a CRM-of-record for async processing, or do both with cross-references. The right answer is almost always both — but the per-category and per-tier rules for what goes where are the actual substance.

The 5-minute rule for inbound leads

Inbound leads — anyone who filled out a form, requested a demo, or replied to a campaign with positive intent — have a steeper decay curve than anything else in your funnel. Respond within 5 minutes and roughly 80% convert to meetings. Wait longer and the rate drops to about 20%. That's a 4x swing on a single operational variable.

The mechanism: at minute zero the lead is actively thinking about your product, your tab is still open, and the comparison set hasn't re-opened. By minute 30 they've moved on to the next thing. By hour 4 a competitor has called them back. By hour 24 you're cold-outbounding a lead you already paid to acquire.

The implication: inbound-lead routing should bypass every shared queue and go direct to the on-call AE's phone or Slack DM. Treat the 5-minute window as non-negotiable during business hours and have an explicit after-hours owner.

The Slack-class routing pattern

Route every reply into a dedicated channel within 30 to 90 seconds of arrival. The middleware — either a feature of the sequencing platform or a thin webhook handler — parses the inbound message, applies a classification tag (positive, negative, objection, soft-pass, auto-responder — Chapter 01), and posts to the channel with context: prospect name, account, campaign, the original sequence message, and the full reply body.

Structure channels by urgency tier, not by campaign or AE: one for high-tier accounts needing sub-one-hour response, one for mid-tier on a four-hour target, one for auto-responders and low-priority traffic. Each post carries a category tag, an at-mention of the on-call owner, and a thread for the draft reply. The on-call rotation is explicit — one named human per channel per business hour, with a documented handoff at the boundary. Without an explicit rotation, the channel is “owned” by five people and therefore by no one, and your first-touch latency looks like no routing at all.

The CRM-of-record routing pattern

The CRM-of-record pattern routes replies to the prospect's contact record. Each reply is attached as a timeline activity, classified by category, and surfaced in the contact's interaction history. The reply does not generate an immediate notification — the asynchronous model assumes the AE who owns the account reviews the timeline as part of their regular cadence.

The pattern has two non-substitutable properties. First, a permanent historical record of every reply on every account, searchable months and years later — the AE who picks up an account after the previous owner departs can reconstruct prior outreach in a single query. Second, reply patterns surface at the account level rather than the contact level: five soft-pass replies from five different contacts at the same account, viewed in aggregate, is a different signal than five soft-passes individually. The search-and-recall value compounds over the lifetime of the CRM, which is why any reply-handling architecture without a CRM-of-record component is structurally incomplete regardless of how good the immediate-triage layer is.

The both-channels pattern — the operational compromise

The both-channels pattern routes every reply to the messaging tool for immediate triage and to the CRM-of-record for asynchronous processing, with explicit cross-references. The messaging-tool post links to the CRM contact record; the CRM activity links back to the messaging-tool thread where the reply was triaged. The on-call human triages in the messaging tool; the AE reviews in the CRM; the historical record lives in the CRM; the response draft lives in the messaging-tool thread until sent, at which point a copy is logged to the CRM activity.

The both-channels pattern carries an integration cost — the middleware must post to two systems — but the cost is one-time engineering, not per-reply overhead. The operator who skips this pattern by choosing one system or the other consistently rediscovers, three to six months in, that the chosen system does not serve the use case the other system was designed for.

Per-category routing rules — Slack vs CRM async

Two categories go to Slack for live triage. Three go to CRM async. The split:

The most common failure is no category-based routing at all — every reply lands in one channel and the on-call spends the same triage budget on a soft-pass as on a positive intent. The second most common failure: routing positive intent to CRM-only because “the AE will see it.” They will, 12 to 36 hours later, after the window has closed.

Routing by account tier

Routing rules layer per-account-tier prioritization on top of per-category rules. The empirical structure that produces the best first-touch latencies under bounded triage capacity:

• High-tier accounts (target enterprise accounts, named-account lists, strategic territories) route to a dedicated channel with a named human owner per account or per territory. The on-call human for high-tier is the AE who owns the account, not a shared SDR pool. The latency target is sub-one-hour for positive intent and sub-four-hours for objections.
• Mid-tier accounts (the meaningful working volume) route to a shared channel with an on-call rotation across the SDR or BDR team. The latency target is sub-four-hours for positive intent and end-of-business-day for objections.
• Low-tier accounts (volume territory, spray-and-pray segments, low-fit ICP edges) route to the CRM-only asynchronous pathway with no messaging-tool notification. The latency target is end-of-week.

Per-AE prioritization

When the CRM already has an assigned account owner, override the channel default and route the reply directly to that AE's DM. The shared channel doesn't see it. This preserves relationship continuity, prevents the SDR pool from drafting on accounts where the AE has context, and kills the most common source of cross-team friction.

Implementation: lookup in the CRM on every inbound reply. Account has an owner → route to the owner's DM with the standard tags. Account is unowned or in the SDR pre-sales pool → route to the shared channel under per-tier rules. The lookup happens in the middleware.

OOO-aware re-send

An auto-responder carries no intent signal but it carries something useful: a return date. Parse it from the body, schedule a re-send of the original message for one to two business days after the return, and log both the OOO and the scheduled re-send in the CRM.

The parse is straightforward — “until [date]”, “returning [date]”, “back on [date]” covers roughly 80-85% of English-language B2B auto-responders — and the re-send recovers 15-25% of contacts who'd otherwise drop out at the OOO boundary. Skip it and you're losing one to three meetings per hundred sequences to this failure alone.

Don't re-send on the return date — that lands on top of their post-vacation inbox triage, the worst possible moment. Wait 1-2 business days for the dust to settle.

Rate-limiting on routing

At sustained reply volume, the messaging-tool routing layer can exceed the team's triage capacity — the on-call human cannot draft responses faster than the channel produces them. The rate-limiting rules, applied at the middleware layer rather than at the messaging tool:

• Positive intent is never rate-limited. The conversion economics of a positive reply are too sensitive to first-touch latency to delay under any circumstance.
• Objections are rate-limited last. The conversion-rate-on-objection (Chapter 04) is sufficient to justify protecting this category from delay.
• Soft-passes and auto-responders are routed straight to CRM-only. These are the categories that absorb the rate-limiting overflow, because their first-touch latency target is days to weeks rather than hours.
• Negative-intent replies are routed to suppression-list automation with no human triage required. The category does not consume triage capacity at all.

The routing-latency metric

The operational discipline that distinguishes well-run reply handling from the default architecture is the measurement of routing latency: the time between reply arrival at the sending mailbox and first-touch by the assigned human. The metric is logged at three checkpoints — mailbox arrival, middleware ingestion, messaging-tool post — and reported daily as a per-category p50 and p95.

The middleware-to-messaging-tool segment is typically under 60 seconds and stable. The variable segment is messaging-tool-post to first-touch, which is governed entirely by the on-call rotation discipline. A team whose p50 first-touch latency is creeping above the per-tier target is the leading indicator of every downstream conversion problem in the reply-handling stack; the metric is the canonical operational dashboard for the reply layer.

The four-hour empirical window for first-touch

The empirical finding, observed across reply-handling operations at multiple B2B sending estates: operators with sub-four-hour first-touch on positive-intent replies convert reply-to-meeting at 15 to 25%; operators above eight-hour first-touch convert at under 5%. The four-to-eight-hour band converts at 7 to 12% and is the most common production state.

The mechanism: a prospect who replied with positive intent is, at the moment of reply, the highest-context they will be in the entire sales cycle. The original message is still in working memory, the calendar still has the space the prospect was implicitly assuming, and the competitive consideration set has not yet re-opened. By 24 hours the original message is no longer salient; by 48 hours the prospect has had three other vendor conversations and the original positioning competes against fresher inputs. The four-hour window is not a hard threshold but the inflection point where the decay curve becomes steep; Chapter 03 operationalizes it.

The integration pattern

The end-to-end integration pattern for the production-grade routing architecture:

sequencing platform
   ↓ (inbound reply webhook, ~5-30s post-arrival)
classification + routing middleware
   ↓ (category tag, account-tier lookup, owner lookup)
   ├──→ messaging tool channel or DM (per-tier + per-category rules)
   ↓
CRM-of-record (activity log + cross-reference back to messaging thread)
   ↓ (suppression-list sync, nurture-cadence assignment, OOO re-send scheduler)
sequencing platform (re-send queue, suppression enforcement)

The middleware is either a feature of a sequencing platform with reply-routing built in, a no-code integration stringing together published webhooks, or custom code the operator maintains. The build-vs-buy decision is governed almost entirely by the operator's CRM-of-record system: standard systems admit no-code patterns; idiosyncratic or self-hosted CRMs require the custom-code path.

The deduplication problem

When the same recipient is in two parallel campaigns — the most common cause is overlapping list builds in a multi-product or multi-territory program — a single reply can be ingested twice, once per campaign. Without deduplication: two messaging-tool posts, two CRM activities, two AE-assignment lookups, predictable downstream confusion.

The deduplication rule is implemented at the middleware: a reply is uniquely identified by (sender email, inbound-message-id, recipient mailbox), and the first ingestion per tuple is canonical. Subsequent ingestions update the original CRM activity to note the campaign overlap and produce no additional messaging-tool posts. The operator who skips deduplication discovers the problem the first time two AEs draft conflicting responses on the same reply.

Common operator failures observed in production

• Email-inbox-only routing. The default. Replies sit in the sending mailbox until the operator opens it. P50 first-touch: 24 to 72 hours. Reply-to-meeting conversion: under 5%.
• No per-category routing. Every reply lands in the same channel with the same urgency tag. The on-call spends the same triage budget on a soft-pass as on positive intent. The conversion-window discipline collapses under volume.
• No per-account-tier prioritization. High-tier accounts route through the same shared channel as low-tier volume territory. The named-account AE never sees high-priority replies in time to act.
• No latency monitoring. The metric is not measured, the rotation is not held accountable, and latency drifts upward 30 to 60 minutes per quarter until it crosses the four-hour inflection and the conversion economics collapse without an obvious root cause.
• No OOO-aware re-send. Auto-responders are logged as soft-passes or ignored; the 15 to 25% of contacts who would have re-engaged on return drop out of the cadence at the OOO boundary.
• CRM-only routing on positive intent. The AE sees the positive reply 12 to 36 hours later in timeline review. By then the prospect has moved on or lost the calendar window that motivated the reply.
• Messaging-tool-only routing with no CRM sync. The reply is triaged in the channel and never logged anywhere durable. Three months later, no one can reconstruct what happened on the account.
• Deduplication absent across parallel campaigns. Two AEs draft conflicting responses on the same reply; the prospect concludes the sender is disorganized.

Pre-deployment checklist

• Middleware in place between sequencing platform and downstream systems, with per-category classification (Chapter 01) operational before routing rules activate
• Dedicated messaging-tool channels structured by urgency tier rather than by campaign or by AE
• Explicit on-call rotation per channel per business hour, with documented handoff at the rotation boundary
• CRM-of-record integration writing per-reply activities with category tag and cross-reference to the messaging-tool thread
• AE-ownership lookup performed on every inbound reply, with DM routing override when ownership is assigned
• OOO-aware re-send parser deployed with logging of unparsed auto-responder formats for ongoing tuning
• Routing-latency metric instrumented at three checkpoints, reported daily as p50 and p95 per category
• Rate-limiting rules documented and applied at the middleware, with positive-intent and objection categories protected from delay
• Deduplication keyed on (sender email, inbound-message-id, recipient mailbox), with conflict logging for cross-campaign overlap
• Suppression-list sync from negative-intent classification back to the sequencing platform, with verification that suppressed contacts are excluded from future sequences

Where routing fits in the broader reply-handling stack

The routing layer is the architectural bridge between classification (Chapter 01) and triage (Chapter 03). Classification tells the system what kind of reply this is; routing tells the system where it goes and how fast; triage describes what the human on the receiving end does with it. The decay curve in this chapter is the empirical motivation for the four-hour window that Chapter 03 operationalizes — a routing architecture that lands replies in the right channel within 60 seconds is the necessary infrastructure for the triage discipline to be possible at all.

The operator who has built the routing architecture correctly has the operational substrate to absorb whatever reply volume the upstream campaign produces. The remaining chapters describe what the on-call human does, what response patterns convert under what conditions, and how the resulting pipeline rolls up to the per-stage conversion economics that anchor the entire upstream investment.

Related chapters

• How to Classify Cold Email Replies — the upstream signal that determines which routing rule applies.
• Reply Triage — The Four-Hour Window — the human discipline routing enables.
• Meeting Booking Mechanics — Reply to Calendar to Show — where positive replies route to.