A long-standing debate inside the go-to-market teams of B2B businesses is when, and how, to route a user to the sales team, and when it is not worth spending a salesperson’s time on that user at all, letting them go through a self-service path instead.
It is not your ICP
Several problems arise in these conversations. One of the most common is mistaking the ICP for the answer, when the ICP was never meant to answer this. The ICP exists to influence acquisition, the product roadmap, and the communication strategy. It describes who we want. The question here is different: the user has already arrived, has already shown interest, and what we do not know is the best way to engage them now that they are here.
To make that decision, usage-based B2B SaaS businesses usually apply a threshold to their pricing metric, whatever it happens to be: volume of sessions, users, workers, tracked events, data stored, and so on. And more often than not, that threshold is set by heuristic or plain guesswork. What follows is one of two failure modes. Either the bar is too low, and the commercial team drowns in calls with users who were never worth a human’s time, or the bar is too high, and the same team sits with one or two calls a week while real opportunities pass by untouched.
In moments like this a CMO or CRO tends to raise a flag, turn to their teams and to the data team, and ask what should be done, usually expecting it to be fixed fast. And here the problem thickens. The data team often lacks the context to approach the dilemma well, the stakes are high because it directly affects sales capacity and financial projections, and the whole thing is handed over as if it were a self-contained modelling task rather than the cross-functional decision it actually is.
Why your own history lies
The usual first move is to pull every historical lead the company has, bucket the accounts into tiers of the pricing metric, see how conversion differs across the tiers, and place the threshold where conversion jumps. It is a reasonable instinct, and it is also a trap. The data is already contaminated by the company’s own past decisions. Sales has, for years, been working the accounts above whatever line existed at the time, so of course conversion rises where humans have been intervening. The jump you find is not a discovery about your customers. It is the fingerprint of your own prior rule, and if you set the new threshold from it, you simply relearn the decision you already made.
Measure the lift, not the conversion
The way out begins with a sharper question. You do not actually care how likely an account is to convert. Plenty of accounts will convert with or without a call, and a salesperson spent on them buys nothing you did not already have. What you care about is the lift: how much more likely the account is to convert because a human got involved, and whether that extra conversion is worth more than the touch costs.
At its simplest this is a unit-economics problem. Suppose a thirty-minute sales call costs the company around one hundred euros in loaded time. Then it is only worth routing an account to sales when the additional revenue that call is expected to produce, the lift multiplied by what the account is worth, clears those hundred euros. Note the word additional. The gate is not “will this account convert”, it is “will the call change the outcome by enough to pay for itself”, and that is a harder thing to measure, because it is precisely what the contaminated history cannot tell you.
Two experiments that find the number
To measure it honestly you have to create data your old rule did not write, and that means experimenting. There are two ways to do it, and mature teams use both.
The first uses the threshold you already have. Because sales assignment jumps at the current line, accounts sitting just above and just below it are almost identical, alike in size and in most other respects, separated only by whether a human was assigned. Comparing what happens on either side of that boundary gives a clean read on the effect of the touch, a method known as regression discontinuity. It is cheap, it uses data you already own, and its limitation is that it only speaks about the effect near the cutoff. It answers the question “is our current line in the right place”.
The second is a deliberate randomized holdout. You take a slice of accounts and route them against your own rule on purpose, sending some below-the-line accounts to sales and letting some above-the-line accounts self-serve, all chosen at random. It feels uncomfortable to route “wrong” deliberately, and that discomfort is the price of information, because randomization is the only thing that fully severs the link between account size and sales assignment. Unlike the discontinuity, it tells you about lift across the entire range, not just at the boundary. It answers the bigger question: where should the line be at all.
From a threshold to a ranked list
Experiments give you the lift band by band, but the accounts inside a band are not all alike, and a single number per tier still throws away most of what you know. This is where a data-science team can go further, with what is called uplift modelling. Instead of training a model to predict who converts, which only relearns the old bias, you train it on the experimental data to predict the incremental effect of a sales touch for each individual account, given everything you know about it. The modern tooling for this, meta-learners and causal forests and the like, exists precisely to estimate that per-account effect rather than a raw probability. Once every account carries an estimate of how much a touch would move it, and of what it is worth, you no longer have a threshold at all. You have a ranked list, and you route sales down that list until their finite hours run out. The cutoff becomes wherever capacity happens to stop, falling when you hire and rising when you shrink, without anyone having to defend a number.
Two further refinements make this durable. If you genuinely cannot run a clean experiment, you can still approximate the lift from observational data by matching touched and untouched accounts on their characteristics, a propensity-based comparison, though it is only ever as good as the things you managed to measure and it never fully escapes the bias. And if you want the system to keep learning rather than freezing after one study, you can route with a contextual bandit, which continuously balances exploiting what it already believes against exploring the accounts it is unsure about. That last part matters more than it sounds, because the moment you only ever send humans above the line, you go blind to everyone beneath it and the model slowly rots on data it can no longer see. A little permanent, deliberate uncertainty is what keeps the estimates alive.
The number is an output, not a decision
Which is the real answer to the question we started with. The threshold was never something to decide in a meeting. It is an output. It is wherever your latest experiment says the lift stops paying for the touch, and it moves as the product changes, as the market shifts, as the sales team grows or contracts. It updates because the evidence updated, not because someone was outvoted. So when the CRO asks for the number to be fixed fast, the honest reply is that you cannot hand them a number and mean it. What you can hand them is the machine that produces a defensible number this quarter and a better one the next, and that finally stops the company relitigating the same meeting every year.
