From Gut Estimates to Ground Truth

Before diving into the data, it's worth spending two minutes on context — because the questions we're trying to answer with this analysis only make sense if you understand what's been in flux.

6sense brought in BCG at the start of the year to redesign pricing and packaging. BCG's recommendation was a good/better/best framework — three tiers with 16 price points, built around accounts and contacts. For a while, that's what we were building toward.

The Product & Engineering offsite in mid-March forced the reckoning. BCG's framework was formally abandoned. Three pivots in one month — each one narrowing scope, each one increasing clarity. Here's where we ended up:

The guiding principle that survived every pivot: Intelligence at Rest = Free. Intelligence in Motion = Credits. Passive data sitting in the platform doesn't consume credits. Active processing, exports, API calls, and agent-driven queries do.

Why revenue bands? Not FTE, not accounts?

The previous model used FTE employee count to tier customers into five price bands. Stuart's analysis showed the problem: a 1,000-person nonprofit at $40M revenue and a 1,000-person SaaS company at $350M revenue sit in the exact same FTE tier — but have wildly different ability and willingness to pay.

Revenue is a cleaner proxy for willingness-to-pay. It's also less gameable — companies can hire contractors, but they can't easily misreport annual revenue to their CRM vendor. The data validates this, as we'll see.

The first thing you notice when you apply the bands to real data is the shape of the distribution. It's not what you'd expect if you came from the enterprise software playbook.

The 60% finding — and why it's actually fine

60% of the customer base — 1,273 accounts — lands in Band 1. At first glance that sounds alarming. But it's not, once you understand what Band 1 represents: this is the segment 6sense is not actively selling into. Renewal rates in the low-40s. 57% Red health. Approximately $48M ACV. Eitan has been explicit that none of our direct reps should be selling under $75K.

This cohort is in natural decline. The pricing model doesn't need to serve them — it needs to not get in the way of natural churn while protecting the bands that actually matter for growth.

Where the growth business actually sits

When the credit system was being designed, someone had to pick allotment numbers — how many credits each band gets per year before hitting overages. Those numbers (5K / 15K / 40K / 100K) were gut estimates. No one had looked at what customers actually consume.

Now we have the data. And the gaps are meaningful enough that going to market with the prior numbers would be a mistake.

The methodology: P80 as the allotment target

We looked at all annualized usage events per customer — API calls, AWF, DWE, SI events — and computed the 50th, 80th, and 90th percentile by band. The P80 becomes the recommended allotment: it covers 80% of active customers in that band without hitting overages.

One important caveat: Company ID API calls are excluded from this analysis. We'll explain why in the next section — it's the most consequential issue in this entire document.

Reading the numbers: where the risk is

Band 3 is the one place the gut estimate was roughly right. P80 usage is 29K; prior allotment was 40K. There's a modest buffer there, not a crisis.

Visualizing the allotment gap

When you look at total credit-consuming activity across the customer base, one signal overwhelms everything else: Company Identification (CoID) API calls. These are the API events where 6sense's identity graph resolves a web visitor or a contact record against a company.

How much does CoID dominate?

86% of Band 4's total usage is CoID calls. If we included CoID in allotment sizing, Band 4's P80 wouldn't be 43K — it would be many multiples of that. This is why the 45K recommendation explicitly excludes CoID. But that exclusion needs to hold up.

The accounts driving Band 4's CoID volume

The problem: two behaviors, one metric

Here's what makes CoID so complicated. There are two fundamentally different types of Company ID calls, and they're currently reported as a single number:

The user band modifier: a near-zero revenue lever (for now)

The pricing model includes a "user band modifier" — an uplift if a customer exceeds 50 platform users. The intent is to replace per-seat SI revenue with a scalable user-count mechanism. The data shows a problem: the threshold almost never triggers.

Only 36 customers total — 1.7% of the entire base — have more than 50 platform users. In Bands 1–3, the modifier is essentially never triggered. Even in Band 4, only 11% of customers would hit it.

Meanwhile, SI users run 3–5× higher than platform users at every band. CrowdStrike has 2,000 SI seats. HPE has 1,853. Okta has 1,210. If the user band modifier only counts platform users, those accounts contribute near-zero modifier revenue. That's a big miss if SI seat revenue is what we're trying to replace.

The Tier 3 migration landmine

When we move from FTE-based pricing to revenue-based pricing, most customers migrate cleanly. Tier 1 (5,000+ FTE) maps almost entirely to Band 4. Tier 5 (<200 FTE) maps almost entirely to Band 1. The extremes are fine.

The problem is Tier 3 — the 500–1,999 FTE band. 467 customers. They spread across all four revenue bands because mid-market companies have wildly different revenue-per-employee ratios.

Tier 3 is 22% of the customer base, and it maps to every band. Some of these customers will see pricing go up under the new model. Some will go down. The migration plan needs explicit guidance for this cohort — grandfather pricing for X months, a blend, or a hard cutover with proactive outreach — before we can go to market.

Here's the honest map of where we are: the data has given us enough to move on Bands 1–3. Band 4 is gated on CoID. The user modifier and Tier 3 migration are decisions, not data problems.

The five questions for Friday