01 / 13
6sense Pricing Transformation

Credit Consumption Analysis

2,115 active accounts analyzed against finalized revenue bands. Data-backed allotment recommendations + a clear list of what we can't decide yet.

For Stuart · Maggie · Amir
Date April 1, 2026
Context Input for Fri Apr 4 Credit Call
Dataset

2,115 Active Accounts — Full Base

2,115
Active Accounts
99.9% have company revenue data
$235M
Total ACV
FY26 annualized
16%
Churn Rate
vs. 8–10% benchmark
82%
Net Revenue Retention
Target: 110%+
Segment # Accounts ACV % of Total ACV Notes
Commercial 1,159 $62M 26% Largest account count, lowest ACV density
Enterprise 605 $103M 44% Primary growth segment
Strategic 238 $70M 30% Top-of-house; includes Autodesk, NVIDIA, SAP
Power Users 786 $163M 69% ABM + SI + Predictive — high-value retention target
What this is Full active customer base — 2,115 accounts, FY26 data across all segments
Takeaway 786 power users (ABM+SI+Predictive) generate 69% of ACV. That's the cohort the pricing model must protect.
Revenue Bands

The Finalized Bands Applied to the Real Customer Base

Band Revenue Range # Customers % of Base Red Health % Renewal Rate
Band 1 Sub-$50M 1,273 60% 57% Red ~Low 40s
Band 2 $50M–$200M 403 19% 37% Red —
Band 3 $200M–$500M 193 9% 30% Red —
Band 4 $500M+ 244 11% 29% Red —
Band 1 is 60% of customers — the catch-all Eitan flagged as not actively sold into. Renewal rate in the low-40s. "None of our direct reps should be selling a deal under $75K." This cohort is naturally declining. The pricing model needs to not get in the way of natural churn while protecting Bands 2–4.
What this is All 2,115 accounts mapped to the 4 finalized revenue bands (Sub-$50M / $50-200M / $200-500M / $500M+)
Takeaway 60% of accounts land in Band 1 — the naturally declining cohort. Don't build a pricing model to serve them; build one that doesn't block natural churn.
Validation

Revenue Is a Better Retention Predictor Than FTE

Band 1 · Sub-$50M
57%
Clean gradient B1→B4. Revenue correlates with customer health in a way FTE tiers never did. Independent data validation that revenue is the right tiering variable.
Band 2 · $50–200M
37%
Band 1 churn is structural, not a pricing problem. 57% Red health isn't something a lower price point fixes. These customers are declining; design the model around that reality.
Band 3 · $200–500M
30%
Bands 2–4 are worth protecting. 37% of customers, better health, and the segment that will generate most future ACV growth.
Band 4 · $500M+
29%
Band 4 is healthiest at 29% Red. Revenue and health correlation holds even at the top. Strategic accounts in Band 4 are your highest-value retention target.
What this is Gainsight Red health % for each revenue band — lower is healthier
Takeaway Clean 57%→29% gradient validates revenue as the right tiering variable. FTE tiers never showed this correlation.
Allotment Analysis

The Prior Framework Was Wrong for Bands 1 & 2

Band
P80 Usage
excl. CoID
Prior Allotment
Rec. Allotment
Assessment
Band 1 · Sub-$50M
15K
5K
15K
⚠ Prior covers only P30
Band 2 · $50M–$200M
21K
15K
25K
⚠ Prior covers ~P65
Band 3 · $200M–$500M
29K
40K
30K
✓ Roughly right
Band 4 · $500M+
43K
100K
45K
↓ Prior 2× too generous
Bands 1 & 2 underallocated. Prior 5K allotment would put ~35% of Band 1 customers into overage at go-live. Wrong signal for a band you're not actively selling. Band 2 (your growth tier) hits the same problem.
Band 4 over-allocated. 100K covers P93 — real monetization headroom being left on the table. 45K covers P80 without being punitive. Note: excludes CoID — see Slide 6.
What this is P80 of actual Usage_excl_CoID per band vs. prior gut-estimate allotments
Takeaway Prior Band 1 (5K) covers only P30 — 35% hit overage day one. Prior Band 4 (100K) covers P93 — real revenue left on the table.
The CoID Problem

Company ID Is 86% of Band 4 Usage — and It's Misleading

CoID % of Total Usage by Band
Band 1
36%
Band 2
72%
Band 3
74%
Band 4
86%
Driven by 5 accounts. Autodesk alone = 13.1M CoID calls/year. NVIDIA 3.4M. SAP 2.4M. Smartsheet 1.6M. GitLab 1.0M. These aren't typical Band 4 customers — they've embedded 6sense into their own tech stacks.
Top 5 CoID Consumers
AccountCoID Calls/yrBandSegment
Autodesk13.1MBand 4Strategic
NVIDIA3.4MBand 4Strategic
SAP (AMER)2.4MBand 4Strategic
Smartsheet1.6MBand 4Enterprise
GitLab1.0MBand 4Enterprise
These are Programmatic Access customers — they call APIs programmatically, not through the UI. The metering question for them is fundamentally different from a standard credit allotment.
What this is Company ID API calls as % of total usage by band, plus the 5 accounts driving the extreme numbers
Takeaway CoID is 86% of Band 4 usage — but it's 5 programmatic accounts, not typical customers. Allotments can't be set until web-tag vs. match calls are split.
Kim's Ask · Still Unresolved

The Split We Need Before Band 4 Can Be Finalized

Web-tag De-anonymization · Passive
Auto-fired when a visitor hits a customer's website. The customer doesn't initiate this — our tag triggers it. The "intent" to consume is passive. Cost-to-serve is real, but the usage pattern is fundamentally different from a programmatic API call.

Open question: Should passive web-tag calls meter against credit allotments at all?
Match Calls · Intentional
Programmatic lookups where a customer explicitly calls the CoID API with an API token. Autodesk, NVIDIA, SAP — these are match calls. The customer is building something that runs on 6sense intelligence.

These should meter. The customer is making a deliberate choice to consume credits as part of their product or workflow.
Until this split exists in the data, Band 4 allotments are guesswork. The 45K recommendation on Slide 5 explicitly excludes all CoID. We need Maggie to pull CoID volume by whether the call included an API token (match call) vs. not (web-tag). Is this available in Hex?
What this is Two fundamentally different types of CoID call — passive web-tag de-anonymization vs. intentional programmatic match calls
Takeaway Maggie needs to pull CoID volume by API token presence in Hex. Band 4 allotments are guesswork until this split exists.
User Band Modifier

The Modifier Is Measuring the Wrong Users

Platform Users vs. SI Users by Band
BandAvg Platform UsersAvg SI UsersRatio>50 Platform
Band 14143.2×0.1%
Band 29343.8×0.7%
Band 315634.3×3%
Band 426923.5×11%
Only 36 of 2,115 customers have >50 platform users. The modifier threshold is effectively never hit for Bands 1–3. Even in Band 4, only 11% trigger it. Current design generates near-zero additional revenue.
SI users are 3–5× higher at every band. CrowdStrike: 2,000 SI seats. HPE: 1,853. Okta: 1,210. Red Hat: 1,204. These aren't platform users — they're SI users. If the modifier doesn't count them, it's dead weight.
Decision needed: Count platform users only, SI users, or both combined? This is a definitional choice that changes the modifier's revenue impact by an order of magnitude.
What this is Platform users vs. SI users per band — and how many customers exceed the 50-user modifier threshold
Takeaway Only 36 of 2,115 customers have >50 platform users. If the modifier doesn't count SI users, it generates near-zero additional revenue.
Migration Risk

Tier 3 FTE Is the Landmine

Current FTE Tier
# Customers
→ Band 1
→ Band 2
→ Band 3
→ Band 4
Tier 1 · 5,000+ FTE
131
3%
5%
5%
87%
Tier 2 · 2,000–4,999
158
10%
15%
25%
50%
⚠ Tier 3 · 500–1,999
467
25%
37%
29%
7%
Tier 4 · 200–499
441
63%
32%
2%
2%
Tier 5 · <200 FTE
916
93%
5%
0%
0%
Tier 3 is the problem: 467 customers (~22% of base) spread across all 4 revenue bands. A 1,000-person nonprofit at $40M and a 1,000-person SaaS firm at $350M both land in Tier 3 FTE today — but belong in completely different revenue bands. Migration plan needs transition guidance for this cohort specifically.
What this is Cross-tab: how today's 5 FTE-based tiers distribute across the 4 new revenue bands
Takeaway Tier 3 (500-1,999 FTE) is the landmine — 467 customers spread across all 4 revenue bands. A 1,000-person nonprofit and a 1,000-person SaaS firm both land here today.
SI Seat Migration

66,000 SI Seats — Not a Rounding Error

Top SI Seat Accounts
Account
SI Seats
Band · Segment
CrowdStrike
2,000
Band 4 · Strategic
Hewlett Packard Ent.
1,853
Band 4 · Strategic
Okta
1,210
Band 4 · Strategic
Red Hat
1,204
Band 4 · Strategic
Insperity
800
Band 4 · Strategic
Band Averages · SI Seats / Customer
BandAvg SI SeatsAvg Platform Users
Band 1144
Band 2349
Band 36315
Band 49226
If SI seats are replaced by a user band modifier that only counts platform users, the economics of every Band 3–4 Strategic account change dramatically. CrowdStrike has 2,000 SI seats and only 26 platform users — that's the extreme case that breaks the current modifier design.
What this is SI seat totals across 2,115 accounts — top accounts and band averages vs. platform user counts
Takeaway 66,000 total SI seats. CrowdStrike has 2,000 SI seats but only 26 platform users. A modifier that only counts platform users breaks the economics of every Band 4 Strategic account.
Decision Matrix

What We Can & Can't Decide This Week

✅ Decide Now
  • ✅Raise Band 1 allotment 5K → 15K
  • ✅Raise Band 2 allotment 15K → 25K
  • ✅Lower Band 3 allotment 40K → 30K
  • ✅Lower Band 4 allotment 100K → 45K (excl. CoID)
  • ✅Flag Tier 3 FTE as migration risk needing transition guidance
❌ Blocked: CoID Split
  • ❌Final Band 4 allotment with CoID included
  • ❌Whether Autodesk / NVIDIA / SAP face a large credit bill or get custom treatment
  • ❌Web-tag de-anon pricing policy
❌ Blocked: User Definition
  • ❌Revenue impact of user band modifier
  • ❌Whether modifier replaces SI seat monetization for Band 3–4
⏳ Future State Only
  • ⏳Signal config credits — 1 credit/signal/account/year. Product doesn't exist yet, no benchmark data.
  • ⏳LLM column processing — 1 credit/row. Product doesn't exist yet, no benchmark data.
These will be the biggest new credit meters when they ship. Adoption curve estimates will substitute for historical data.
What this is Decisions segmented by what's actionable now vs. what's blocked by missing data
Takeaway 5 allotment decisions are ready to make now. Two blockers — CoID split and user definition — are the only things standing between this analysis and full alignment.
Credit Call · Fri Apr 4

5 Questions That Need Answers

01
CoID Split · For Maggie
Can we get CoID volume broken down by API token (match call) vs. no token (web-tag)? This is the single most important data point for Band 4 allotments. Nothing else can unlock it.
02
User Definition for the Modifier
Platform users only, SI users, or both? The answer changes the modifier's revenue impact from ~$0 to potentially significant. Median platform users are 4–26; SI users are 14–92.
03
Tier 3 FTE Transition Plan
467 customers spanning all 4 revenue bands. Migration framework needed: grandfather at current pricing for X months? Blend? Some will see pricing go up, some down.
04
Programmatic Access Custom Treatment
Autodesk (13.1M CoID calls), NVIDIA, SAP — these won't fit a standard allotment. Enterprise custom pricing or a separate API tier rate card? Decision needed before August.
05
Band 1 Disposition
57% Red health, low-40s renewal, ~$48M ACV, not actively sold into. Let the cohort decline naturally and design around that? Or a specific lower-tier entry product?
What this is Five questions for the April 4 credit call with Stuart, Maggie, and Amir
Takeaway Q1 (CoID split) is the only truly blocking ask. Everything else can be debated Friday — Q1 requires Maggie to pull new data first.
What's Next

Credit Call → Kim Debrief → Workshop

Fri Apr 4
Credit Call
CoID split · user definition · Band 4 finalization
Mon/Tue
Kim Debrief
Pull-through decisions from credit call findings
~Apr 7
Maggie Data
Credit utilization analysis (Keane OOO — delayed)
Companion spreadsheet: credit-consumption-analysis.xlsx — 8 tabs: executive summary, band analysis, health/segment mix, FTE migration crosswalk, SI seat risk, CoID deep dive, Band 1 detail, full dataset with revenue bands applied.
Prepared by Jason Telmos
Late April Full Alignment Workshop
August 1 Rollout Target