You Sold to a Committee. Now You Have to Win Over a Thousand Strangers

In B2B software, the people who evaluate a product and the people who live in it are usually different populations.

The trial is run by a small group — an evaluation team, a technical lead, a sponsoring executive. They're motivated. They want it to work; often they proposed it.

Then it ships:

"We now have to roll out to maybe thousands of individual users at the customer. How do we train those people? How do we ensure those people use the value of the product?"

Nothing you learned in the sales cycle tells you much about these people. They didn't choose the product. They may not know why it was chosen. Their default position isn't hostility — it's indifference, which is harder to overcome.

The value you demonstrated during evaluation now has to be re-demonstrated to a much larger audience with none of the motivation. That's a different job, and most companies staff it as though it were a continuation of the same one.

There's a version of this problem that's easy to miss, because it hides behind a real relationship. Your champion — the person who sponsored the deal, who sat through the demos, who has something to prove internally — doesn't disappear after signature. They get the quarterly business review. They get the check-in call. Someone on your team, whether that's an account manager or a dedicated customer success role, is actively managing that relationship.

None of that tells you anything about user number four hundred and twelve. The champion's satisfaction is real, and it's also almost entirely disconnected from whether the rest of the organisation adopted the product. I've sat in renewal conversations where the champion was still enthusiastic, still telling us it was going great, while half the licensed seats hadn't logged in for months. They weren't lying. They genuinely didn't know.

Onboarding the champion and onboarding the population are two different projects, running on two different tracks, and most companies only resource one of them.

The adoption phase — typically the first 30 to 60 days — matters more than its share of the relationship suggests.

"If those users are highly engaged, getting great value, they'll probably renew."

That's the defensive case, and it's the one people focus on. The offensive case gets less attention:

"The more users inside the customer are getting value, the chances are the more they'll refer internally and then the seat count — if that's important to you — or the usage count will go up."

Expansion inside an enterprise account rarely comes from a purchasing decision. It comes from someone telling a colleague this is useful. That only happens if enough individual users reached genuine value, and it compounds over years.

I've made the broader case for connecting analytics to lifetime value elsewhere, and the logic holds here at a more granular level: expansion revenue and renewal revenue are both downstream of the same population of individual users, which is also why how you structure pricing around seats and usage matters more than most rollout plans account for — a seat-based contract and a usage-based one fail differently when adoption stalls, but they both fail for the same underlying reason.

So this window does two things at once: it protects revenue you've already booked, and it determines whether the account grows. Both are decided before anyone has thought about the renewal.

Here's the practical obstacle, and it isn't effort.

"The main problem most ISVs have is that their infrastructure isn't instrumented particularly well."

Most companies know something about aggregate usage — the product marketing team has numbers. What they don't have is per-user, feature-level visibility available to the people doing the onboarding.

I've gone into the mechanics of what usage analytics actually needs to capture to be useful for this kind of work in more detail elsewhere. The short version: aggregate is not the same axis as individual, and most instrumentation projects stop at aggregate because that's what's easy to build first.

So the CS rep responsible for making eight hundred strangers successful cannot see which of them has done anything. And when you can't see individuals, you're forced to treat everyone identically:

"Almost all of us send some educational material to our customer once they are in the onboarding phase... but the problem with that is it's fairly generic. It doesn't really focus in on the individual."

Generic material is the rational response to having no information. It's also close to useless, because it asks every recipient to work out which parts apply to them — and they won't. They'll skim it, or delete it.

The alternative isn't more content or more meetings. It's less, aimed better.

"I know that Seth has not used the top five features that they have purchased. And those top five features are critical to maximizing the value from my product. I will engage specifically with Seth and I won't waste Seth's time training him on three of the five features. I'll only give him information about the two he's not using."

This is the specific gap a tool like Zengain is built to close — not by replacing the CS team's judgment, but by giving them the per-user, per-feature signal to apply it to eight hundred people instead of guessing.

Consider what that does for everyone involved.

The user gets a short, relevant message about two things, rather than a comprehensive guide to twenty. They're far likelier to act on it, because it's obviously about them.

The CS team stops spending effort on people who are already fine. At eight hundred users, the difference between contacting everyone and contacting the two hundred who need something is the difference between a programme that runs and one that quietly gets abandoned.

And the relationship changes character. Someone who receives a message referencing what they've actually been doing concludes that somebody is paying attention. That perception is worth more than the content of the message.

Let me make this concrete, because targeted enablement sounds abstract until you've actually run the numbers on a real rollout.

Say a customer buys eight hundred seats. In week one, maybe three hundred and fifty people have logged in at all — that's normal, and it isn't yet a problem. What matters is what happens next, and that depends on having usage data that's actionable at the individual level, not a dashboard that only tells product marketing how the account is doing in aggregate.

From that data, the population splits into cohorts almost on its own. There's a group that hasn't logged in at all — call it a hundred people, and the question for them is whether anyone told them the product exists. There's a much larger group that logged in once or twice, poked around, and stopped — maybe three hundred, and the question is whether they hit the key features before they gave up. And there's a smaller group that's using two or three of your five core features regularly but not the ones that actually justify the purchase price.

Three cohorts, three different messages, and none of them is the generic onboarding email everyone else sends. The first group needs a nudge that the license exists and works. The second needs a fast path to the specific feature that would have made session two worth returning for. The third needs exactly the kind of individually targeted note I described with Seth.

This is also where the implementation team earns its keep past the go-live date — they're often the people closest to how the rollout was actually configured for that customer, and they can tell you which of the five key features this particular account bought for, which is the difference between generic advice and useful advice.

I use three questions:

"Are those users engaged, how often are they engaged, are they using the key features? ... If the answer to that is yes, yes, and yes, we have a go on activation."

Engaged, engaged regularly, engaged with the features that matter. All three, because any two without the third is a false positive. Someone logging in daily but never touching your core capability is not activated — they're in a habit that will break the moment something changes.

Applied at user level rather than account level, this becomes an operational instruction: it tells you exactly who needs attention and what they need it for.

I'm deliberately keeping this simple, because the metrics rabbit hole is deep and most teams don't need to go down it to get value from this. Three honest questions beat a scorecard with thirty inputs nobody trusts.

I'm not going to repeat the health-scoring mechanics — that's covered properly elsewhere. But at the population level, across a 60-day rollout, there's a short list of things worth checking every week that the standard playbooks don't usually surface.

What percentage of licensed users have logged in at all, and is that number moving or flat.

Of the users who have logged in, what percentage have touched at least one of the key features — not any feature, the ones that matter.

Whether the never-logged-in cohort is shrinking, growing, or static. Static after week three usually means nobody has actually reached those people.

How many users moved from logged-in-once to using-a-key-feature that week. That's the leading indicator, not total logins.

Whether the CS rep working the account can see these numbers themselves, or whether they're sitting in a report nobody opens.

That last one matters more than it looks. This kind of visibility only changes behaviour if it's tied to how usage actually gets tracked and valued in the account — otherwise it's just another number nobody acts on. Weekly, not monthly, because by the time a monthly report lands, you've lost three weeks of a sixty-day window you can't get back.

Without visibility, poor adoption doesn't announce itself:

"Seth gets a million emails a day. He gets his training email on all the features. He deletes it and then he kind of walks around the UI and does the best he can to get value. Nobody's tracking that value. Leave it a year. Go back to Seth. He's not even using the product anymore."

Nothing breaks. No ticket is filed. No complaint is made. The account looks fine, because the contract is paid and the champion who bought it still likes the idea.

Then the renewal arrives, and someone discovers the product was never really adopted. At that point there's nothing to fix — twelve months of habit formation didn't happen, and you can't retrofit it in a renewal cycle.

That's why I call it a silent killer. Every other churn cause gives you a signal. This one is defined by producing none.

Treat rollout as a second sale. You've convinced the buyer. Now convince the users, who have different motivations and no investment in the decision. Plan for that as a distinct exercise.

Get visibility down to the individual. Not aggregate dashboards for product marketing — feature-level usage in the hands of the CS reps doing the work.

Define your key features and measure against them. Which three to five capabilities deliver the value the customer bought? Adoption of those is what matters; total logins tell you nothing.

Replace broad enablement with targeted enablement. Fewer messages, each about the specific gap for that specific person.

Set the activation bar at the user level. Engaged, regularly, with key features. Track the percentage of the user base clearing it, not whether onboarding tasks were completed.

None of this replaces the relationship-based work good CS teams already do — if anything, it's what makes proactive customer success possible at a scale that relationship-building alone can't reach. You can't personally know eight hundred people. You can know which of them need something from you this week.

You sold to a committee and now you have to win over strangers, most of whom will decide how they feel about your product in their first few sessions — largely unobserved.

If you can see what each of them is doing, that's a solvable problem. You help the people who need it, leave the rest alone, and build a base of users who found real value.

If you can't, you'll send everyone the same email and hope. And you won't find out it didn't work until it's a year too late to do anything about it.

That's the conversation worth having before your next enterprise rollout, not after the renewal number comes in lower than expected — and it's usually where we start when a prospective customer decides to book a demo and describes exactly this problem.