Pricing & sales · SOW

Share of wallet

How much of a customer's spending in your category you actually hold.

your_revenue_from_the_account ÷ the_account_total_category_spend Unit percentage Usual grain year × account × category

01 What it is

Why anyone looks at this number

In one sentence

How much of a customer's spending in your category you actually hold.

Retention tells you they stayed. Share of wallet tells you whether they buy most of what they need from you. Growth inside the existing base is almost always cheaper than the equivalent acquisition.

02 The formula

How it is worked out

share-of-walletdefinition
Share of wallet = your_revenue_from_the_account ÷ the_account_total_category_spend

grain  : year × account × category
unit   : percentage
source : CRM and billing, joined to an external or modelled estimate of account size

The denominator never lives in your systems. It comes from a survey, a panel, trade data or a model — so the method has to be stored next to the number. An estimate that changes source between years produces a trend that is entirely artificial.

03 Worked example

The same number, with real inputs

Inputs
Revenue from the account€1.9m
Estimated category spend€8.6m
Retention98%
Calculation1.9 ÷ 8.6
Result22%

A loyal account that buys a fifth of what it needs from you. The growth here is not a new logo, it is the other €6.7m already being spent somewhere else.

04 What moves it

Four things that actually change this number

Driver 01

Range coverage

Categories where you are simply not on the list.

Driver 02

Contract structure

Framework agreements that lock in a share, or cap it.

Driver 03

Service performance

OTIF and quality decide whether the second category is ever offered.

Driver 04

Buying centralisation

A group that consolidates purchasing can double or halve your share.

05 Where the number lives

The system, the record and the fields

System of recordKey recordFields you need
CRM and billing, joined to an external or modelled estimate of account sizeAccount, at group level rather than site level account_id, parent_id, revenue_ltm, category, estimated_spend, estimate_source, estimate_date

The denominator never lives in your systems. It comes from a survey, a panel, trade data or a model — so the method has to be stored next to the number. An estimate that changes source between years produces a trend that is entirely artificial.

06 How it goes wrong

Three ways this metric misleads people

Mistake

Treating retention as share

A 98% retained account can still be a 20% share account, and the plan never notices.

Fix: Report both, side by side, for the top accounts.
Mistake

An undocumented denominator

The estimate changes method and the whole trend line moves for no business reason.

Fix: Version the estimate: source, date and method, stored with the number.
Mistake

Averaging across the base

A portfolio average hides the accounts where a plan would actually pay.

Fix: Work it account by account for the top decile and forget the average.

08 Questions

Frequently asked

How do we estimate the denominator credibly?

Three routes, in order of cost: ask the account directly in a review, buy panel or trade data for the category, or model it from firmographics and observed spend in comparable accounts. Record which one you used.

Is share of wallet worth measuring for small accounts?

Rarely one by one. Model it at segment level for the long tail and measure it individually only where a named plan would follow.

One definition, everywhere it is used

SCIKIQ stores this metric once and serves it to every dashboard, board pack and agent that asks.

Book a live demo