1. The Inheritance: What Growth Through Acquisition Leaves Behind

1.1 The Business Context

The company operates across North America, EMEA, and APAC, with multiple product lines serving enterprise, mid-market, and SMB segments. It grew primarily through acquisition (a common path for enterprise SaaS), which meant that each region had its own GTM motion, its own CRM configuration preferences, and its own quietly held definition of what "urgent" meant when an inbound lead arrived.

The routing process, such as it was, had been built incrementally. North America had a spreadsheet that worked reasonably well for the original US territory structure. EMEA had a different spreadsheet, maintained by a different person, with different column conventions. APAC had a hybrid of both, plus a set of Slack channels where regional ops managers handled the exceptions that neither spreadsheet could accommodate. When a lead arrived outside office hours in its originating region, the fallback was effectively "someone will pick it up eventually."

This wasn't negligence. It was engineering under constraint. Real people building real workarounds to keep inbound moving when the underlying system couldn't do the job. The problem is that workarounds calcify. What starts as a temporary patch becomes institutional knowledge. And institutional knowledge is invisible to anyone who wasn't there when the patch was applied.

1.2 The Moment It Became Undeniable

There was no single breaking point. There rarely is with operational drift. What there was instead was a slow accumulation of signals that finally crossed a threshold. In Q1 2025, we ran our first formal SLA audit across all three regions. The results were stark: global SLA attainment was running at 43%. That meant more than half of inbound leads were not being touched within the agreed response window. In North America, the number was better. In APAC, it was worse. In EMEA, it varied so much by country that aggregating it into a single number was almost meaningless.

At the same time, the sales ops team surfaced a duplicate assignment analysis showing an 11.8% rate, meaning roughly one in nine inbound leads was being assigned to more than one rep, either simultaneously or sequentially after a reassignment nobody had logged. Reps were arguing over ownership on Slack. Customers were getting outreach from two different people on the same day, both of whom appeared to have no idea the other had reached out. One prospect had actually replied to the second rep asking why the company kept contacting them. That one made it all the way to the CRO's inbox. That was the week the project moved from "RevOps initiative" to "executive priority."

We mapped it to revenue impact using a conservative model: average contract value, estimated conversion rate differential between leads contacted within one hour versus those contacted after 24 hours, plus the cost of duplicate-handling and the estimated percentage of leads that were routed but simply never followed up on because ownership was ambiguous. The number that came out was approximately $2M in annual pipeline leakage. Not worst-case. Middle estimate.

1.3 Diagnosing the Five Root Failures

Before we could design a solution, we needed to understand exactly where the process was failing. Working with the sales ops leads from each region, we identified five distinct failure modes that were present consistently across the global footprint:

• Manual queue checks. Response time averaged 24 hours on certain routes because the queues were checked by humans on their own schedules, not monitored in real time. If the person who owned the routing spreadsheet was in a meeting, travelling, or simply overwhelmed, leads sat.
• Rule ambiguity at regional boundaries. Routing accuracy sat at roughly 71% because the edge cases (leads from multinational accounts, leads with incomplete geo data, leads matching multiple product lines) had no clear rule. The human fallback was inconsistent by definition.
• No de-duplication layer. The spreadsheet process had no mechanism for detecting whether a lead was a duplicate of a contact already in active sequence. The result was a 11.8% duplicate assignment rate and the rep conflict and customer friction that came with it.
• Retrospective SLA monitoring. Leaders learned about SLA misses after the fact, usually through weekly reporting. By that point, the leads had long since gone cold. There was no mechanism to catch a breach in real time and trigger escalation while the lead was still warm.
• Ownership living in too many places. Because the process spanned spreadsheets, CRM fields, Slack threads, and individual email inboxes, there was no single authoritative record of who owned a lead and when it was assigned. Reporting was unreliable. Audits were painful. Disputes were unresolvable.

2. Designing the Routing Engine

2.1 The Core Design Principle: Deterministic First

The most important design decision we made was architectural, not technical: every lead would follow a deterministic rule path, and manual intervention would only occur as a documented exception. Not the other way around.

This sounds obvious. But the existing process was essentially the inverse: a human made the primary decision and the system recorded the outcome. Flipping that relationship, so the system makes the decision and the human can only override it with a documented reason, is a bigger cultural shift than it sounds. It means the system has to be trusted enough that reps and regional ops managers don't feel compelled to route around it. Getting there requires both technical robustness and stakeholder buy-in. We needed both.

The second principle was equally important: every decision needed an audit trail. Not just a log of the outcome, but a log of which rule fired, in which order, against which enriched fields, with which timestamp. That audit trail was the answer to every future dispute. It was also the foundation for the governance model. You cannot version-control a rule you cannot read.

2.2 What the Routing Engine Actually Considers

The routing engine evaluates eight dimensions in order of priority before making an assignment. Order matters enormously. The classic mistake in global routing design is allowing regional preferences to override strategic account logic, which produces exceptions that permanently erode the integrity of the system. We built the hierarchy deliberately, with explicit sign-off from Sales leadership on which criteria could override which others.

The fallback queue deserves specific mention because it's where most routing systems quietly fail. It's tempting to treat the fallback as a safety net that you hope never gets used. In practice, the fallback fires on every lead that does not fit cleanly, which in a global enterprise with incomplete enrichment data is a meaningful percentage. We built the fallback queue as a first-class owned object with an assigned manager, a 2-hour SLA, and its own reporting. If the fallback queue SLA is slipping, something is wrong with the rules above it.

2.3 The Logic Stack in Practice

Here is the actual decision flow that fires for every inbound lead, in sequence. Each step either produces an assignment or passes the lead to the next step. The process completes, one way or another, in under 90 seconds for 99% of leads.

Step 7, the immutable log, is non-negotiable. It took some political capital to enforce this, because some regional managers initially wanted the ability to reassign leads quietly without a record. We pushed back on that. Hard. An unlogged reassignment is indistinguishable from the old spreadsheet process. It's just a new tool doing the same undocumented thing. The log is what makes the whole system defensible.

3. Building It Without Breaking the Business

3.1 Phasing the Rollout

We rolled out the new routing engine in three phases over fourteen weeks. The sequencing was deliberate: we started with the region that had the clearest territory structure and the least political complexity (North America) validated the system there for four weeks, then expanded to EMEA and APAC simultaneously in a second wave. Running everything at once would have been faster on paper. In practice it would have produced a flood of edge cases, regional exceptions, and confidence-eroding early failures. Phased rollout meant the first region served as a live test environment, and the lessons it generated fed directly into EMEA and APAC configuration.

3.2 The Enrichment Problem

The single biggest technical challenge was not the routing logic itself. It was the enrichment data quality that the routing logic depended on. A routing engine that evaluates eight dimensions is only as good as the field values it's evaluating against. In our case, approximately 34% of inbound leads arrived with incomplete geo data, 22% had company size fields blank or unreliable, and a meaningful percentage had firmographic data that had been enriched at some point in the past but not refreshed since the contact last engaged.

We made a deliberate architectural choice not to block routing on missing enrichment. A lead with incomplete geo data should still route somewhere , to the best available regional fallback, rather than stall in a pre-routing queue waiting for a human to clean it. The routing engine therefore has two paths for every dimension: a primary path that fires when the field is populated and reliable, and a secondary path that fires when it is not. Every secondary-path assignment is flagged in the log as an enrichment-contingent routing decision, which feeds a weekly enrichment quality review.

This also forced an honest conversation about our enrichment vendor coverage for APAC markets, where our primary provider's accuracy was significantly lower than it was for North America and Western Europe. We built a custom fallback enrichment layer for APAC that ran secondary geo matching against domain and IP data when the primary enrichment failed. It's not elegant. It works.

3.3 Handling Exceptions Without Letting Them Multiply

Every enterprise routing implementation accumulates exceptions. There are always accounts that need to be handled differently: a strategic relationship that routes directly to a named CSM regardless of territory, a language exception for a rep covering a secondary market, a temporary capacity override for a rep returning from leave. that routes directly to a named CSM regardless of territory, a language exception for a rep covering a secondary market, a temporary capacity override for a rep returning from leave. These are legitimate. The question is whether you handle them in a way that keeps the system legible or in a way that gradually turns it into a more sophisticated spreadsheet.

We built a formal exception framework from the start. Every exception required four things: a named business reason, a system owner by role, an effective date, and a sunset date. No permanent exceptions. If a sunset date expired and no one renewed the exception with a new business reason, the rule reverted to default. In the first three months, we processed 41 exception requests. Seventeen had sunset dates that expired without renewal. Of those seventeen, twelve had stopped being relevant: the rep had left, the account had progressed, the territory had changed. The sunset mechanism was the single most effective tool we had for preventing the system from re-accumulating the legacy complexity we'd just removed.

3.4 Change Management: What Actually Created Adoption

I want to be direct about something. The hardest part of this project was not building the routing engine. The routing logic, once we had the hierarchy agreed, took less time to configure than any of us expected. The hard part was the reps. Specifically, the reps who had learned to work the spreadsheet system in ways that benefited them, understanding which combinations of Slack message and personal relationship would get a high-value lead reassigned in their direction, and who perceived the new system as a threat to that informal advantage.

We addressed this in three ways. First, we made the equity argument explicit. Under the old system, reps in time zones adjacent to the routing admins had a structural advantage over reps in APAC, because response time to exceptions was faster during business hours for the admin's timezone. The new system was genuinely fairer. We showed that data in the first town hall we ran after Phase 1 launch, and it landed with the APAC team in a way that nothing else could have.

Second, we gave reps visibility into their own routing status for the first time. A dashboard that shows you how many leads you've been assigned this week, where they came from, and what your current load is relative to peers is a surprisingly powerful adoption tool. People are more willing to trust a system when they can see what it's doing.

Third, and this is the one I'd most encourage others to prioritise, we made the escalation path fast and clear. If a rep believed a routing decision was wrong, they could flag it in under 30 seconds through the CRM, and a RevOps analyst would review it within two hours. We logged every escalation, tracked the outcomes, and fed the patterns back into rule refinement. In the first month, we received 63 escalations. Forty-one were confirmed as correct routing and the rep was shown the log. Seventeen led to rule refinements. Five were confirmed routing errors we hadn't caught. A system that handles 63 escalations cleanly and improves from seventeen of them is building rep trust faster than any communication campaign could.

4. What Changed, and What We're Honest About

4.1 The Performance Numbers

Three months after global rollout, here's where the key metrics landed relative to baseline. I want to present these alongside the context that makes them meaningful, because the number in isolation doesn't tell you whether you're looking at a real improvement or a statistical artifact of the measurement change.

4.2 The $2M Number, Breaking It Down Honestly

The pipeline leakage estimate was always the headline. It's also the number most likely to be challenged, so I want to be explicit about where it came from and how much confidence to attach to each component.

The honest version of this number is: somewhere between $1.4M and $2.8M, depending on how aggressively you model conversion rate differentials and how much of the routed-but-never-worked category you attribute to routing versus rep prioritisation. We used the middle estimate for the business case because we wanted the CFO to be able to defend it under scrutiny, not just agree to it in the room.

4.3 The Number That Mattered Most to the Sales Team

Here's the result I wasn't expecting to matter as much as it did: escalation volume dropped to near-zero by month two. In the old process, ownership disputes were a daily operational cost. Reps escalated to their managers, managers escalated to regional ops, regional ops pulled in RevOps to adjudicate. It was noisy, time-consuming, and corrosive to the relationship between the GTM team and the RevOps function. Within six weeks of launch, that noise had dropped by roughly 85%.

The reason was the log. When a rep challenged an assignment, we could point to the exact rule path, the exact enriched fields it fired on, the exact timestamp, and the exact reason the system chose one rep over another. Most challenges stopped at that point. Not because reps were forced to accept it, but because the explanation was satisfying. "The system assigned this to your colleague because they have the named account relationship on record and your colleague's capacity was lower at the time of assignment" is a complete sentence. It ends the conversation. It builds trust in a way that "the spreadsheet said so" never could.

5. Keeping the System Honest

5.1 The Routing Governance Council

I want to tell you something that is not in any vendor documentation for any routing tool: routing rules multiply on their own. You don't have to do anything for this to happen. A new market launches and someone adds a rule. A product team changes the demo request flow and someone patches the routing to compensate. A high-performing rep negotiates a capacity exception with their manager, who adds it to the system without telling RevOps. Within six months of any routing system going live, you have ten or fifteen rules that nobody who currently works at the company fully understands. Within a year, you're back to the same problem you fixed, except now it's wearing better-looking clothes.

We established a Routing Governance Council specifically to prevent that. It meets weekly, includes RevOps, Sales Ops, Sales Enablement, and one regional sales leader per major theater, and it owns three things: all rule change requests, all exception renewals, and the quarterly rule audit. Nothing changes in the routing logic outside of the Tuesday review window. Full stop. The first few weeks, regional managers pushed back on this. They were used to getting routing changes made same-day with the right Slack message. We held the line. By week six, the same managers were filing structured requests in advance because they'd learned that a well-argued request gets approved at the Tuesday meeting, and an ad hoc escalation gets put in the queue anyway. The cadence created a habit. The habit created predictability. Predictability is what a governance model is actually for.

5.2 The Weekly KPI Framework

There is a version of a KPI dashboard that is, essentially, a list of numbers that all say "things are fine" until suddenly they don't. We built something deliberately different. Every metric on the weekly dashboard was chosen because it can catch a specific type of failure before that failure becomes visible in revenue data. I want to walk through why each one earned its place, because the reasoning matters as much as the metric.

The most valuable metric in practice turned out to be lead-to-meeting conversion by route type. It was the only metric that could surface a routing problem that had nothing to do with speed or accuracy, specifically, cases where the right rep by territory logic was the wrong rep by product knowledge or segment experience. The routing engine doesn't know if a rep is well-suited to sell a particular product to a particular segment type. That's a qualitative judgment that only shows up in conversion data. Tracking it weekly meant we caught three route configurations in the first quarter where the logic was technically correct but commercially suboptimal.

6. Honest Lessons

6.1 We Underbuilt the Enrichment Layer

We made a reasonable assumption early in the design: that our primary enrichment provider would cover enough of the global lead volume to make the routing engine reliable at launch. That assumption was accurate for North America and Northern Europe. It was not accurate for Southern Europe, Southeast Asia, or any market where company registration data is less digitised or where our provider's coverage was thin. We spent the first six weeks of Phase 2 building enrichment fallbacks that should have been designed in Phase 1. The lesson: map your enrichment provider's coverage against your actual lead volume by market before you design the routing logic that depends on it. If coverage is below 70% in a market, build the fallback before you build the primary path.

6.2 The Coverage Hours Configuration Took Three Iterations

Modelling global coverage hours sounds simple. In practice it involves time zones, public holidays, regional leave patterns, part-time arrangements, and the reality that "available" in your CRM and "actually checking their queue" are not the same thing. Our first configuration was technically correct and operationally naive, it showed reps as available based on their contract hours, not their actual engagement patterns. Two weeks in, we discovered that APAC SLA miss rates at certain hours were driven entirely by a gap in coverage we hadn't mapped. We rebuilt the coverage model from actual login data rather than contract hours, and the gap closed. If you're building a routing engine with time-zone-aware coverage, use behavioural data to validate the coverage model before you go live.

6.3 The Governance Council Should Have Launched with Phase 1

We launched the governance council in Phase 3, after the system was globally live. My reasoning at the time was that we needed stable rules before we introduced a review body that would be changing them. That logic was exactly backwards, and I should have known better. The period between Phase 1 launch and Council formation was the highest-pressure window of the whole project, which is precisely when ad hoc decisions get made and informal precedents get set. We received 28 exception requests in those six weeks. We handled all 28 through a mix of Slack messages, emails, and verbal agreements with regional managers. When the Council convened in Phase 3 and started reviewing the rule set, five of those 28 had created rule configurations that conflicted with each other. Two of them had been made with direct stakeholder commitments attached. Reversing them cost us three weeks and one difficult conversation with a senior sales leader who felt they were being overruled on a commitment that had been made in good faith. That cost was entirely avoidable. Launch the governance structure at the same time as the system.

6.4 Do Not Mistake Low Escalation Volume for High Confidence

In month two, escalation volume dropped 70% from the month-one level and someone on the team sent a Slack message saying "reps are trusting the system." I responded with "maybe" and made a note to investigate. In month three, I ran a quick pulse check with three reps in different regions. Two of them said, independently, that they had stopped filing escalations because the last two had taken four hours to get a response and the lead had gone cold by the time the reassignment came through. They had not lost confidence in the routing logic. They had lost confidence in the escalation process, which is a different thing, and they had responded to that loss of confidence by simply absorbing the bad assignment rather than fighting it. We had fixed one trust problem and quietly created another. We reinstated the two-hour SLA, communicated it explicitly to reps, and escalation volume recovered before settling at a genuinely lower level that reflected actual routing confidence rather than learned helplessness. Check whether your escalation path is being used before you conclude that it doesn't need to be.

7. If You're Building This Today

Here is the sequence we'd follow, knowing what we know now. The ordering is specific and deliberate, several of the mistakes we made came from doing things in the wrong sequence, not from doing the wrong things.

Appendix A: Common Routing Failure Modes

These are the failure patterns we've seen most consistently across global routing implementations. Use this as a pre-project diagnostic to identify which are present in your environment, and as a post-launch monitoring reference.

Appendix B: The Revenue Leakage Estimation Model

This is the framework we used to build the $2M estimate. It's deliberately conservative, every assumption should be defensible, not optimistic. Run it against your own data before presenting to finance.

One additional note on this model: the most common mistake is running it on aggregate numbers and missing the regional distribution. A global average delay of 12 hours may look tolerable. That same 12-hour average driven by a 48-hour average in APAC and a 2-hour average in North America represents a much more serious problem in one market than the aggregate suggests. Always segment by region, source, and segment tier before presenting the number.