Blog · Wallet share and penetration
Test lower, base and upper customer-wallet assumptions before choosing accounts to pursue. Separate stable priorities from rankings that depend on weak evidence.
Share-of-wallet estimate sensitivity checks whether an account remains a priority when its estimated category spend changes. A point estimate can make two accounts look equally attractive even though one has current customer evidence and the other relies on a broad size ratio. Test the uncertainty before committing scarce account-manager time.
The calculation guide explains the underlying measure. This guide starts after a point estimate exists and tests the decision built on it.
For this exercise, hold your category sales, account identity, currency and period constant. Change only the uncertain wallet. Otherwise the scenario mixes several questions and the ranking movement cannot be explained.
Useful columns are account ID, category, measured sales, wallet source, source date, lower wallet, base wallet, upper wallet, reason for the range and reviewer. A customer statement may still need a range if it excludes subsidiaries or rounds heavily. An inferred figure needs evidence for both its size input and its spend-per-unit assumption.
Use stated and estimated source labels consistently. A range around a weak estimate does not turn it into a customer declaration.
Scenario share = measured sales / scenario wallet
Scenario unheld spend = scenario wallet − measured sales
Unheld spend is the remainder of the stated category wallet. It is not automatically available to your company: incumbent agreements, product eligibility, supplier diversification and delivery constraints still apply. If your decision uses a reachable-share ceiling, declare it separately and apply the same rule to every scenario.
The following example is synthetic. Amounts are annual USD thousands and are not customer results or industry norms.
| Account | Your sales | Lower wallet | Base wallet | Upper wallet | Gap, lower/base/upper |
|---|---|---|---|---|---|
| A | 80 | 120 | 200 | 280 | 40 / 120 / 200 |
| B | 120 | 180 | 240 | 300 | 60 / 120 / 180 |
| C | 50 | 150 | 160 | 170 | 100 / 110 / 120 |
| D | 60 | 310 | 330 | 350 | 250 / 270 / 290 |
A's share ranges from 66.7% at the lower wallet to 28.6% at the upper wallet; its base share is 40%. C's base share is 31.25%, but its dollar gap is smaller than A's base gap. Sorting only by the smallest share would confuse penetration with commercial size.
D ranks first under all three shared scenarios. More strongly, D's smallest gap, $250,000, exceeds every other account's largest gap, $200,000. It remains first even when accounts take different positions within their ranges.
The rest are unstable. In the lower scenario C ranks ahead of B and A. At base, A and B tie at $120,000. At upper, A leads B and C. The correct next action is to improve A's evidence or keep the tie visible, rather than publish a precise ranking that the inputs do not support.
Record best rank, worst rank and the decision that changes. A one-place movement below the team's pursuit cutoff may matter less than an account moving into or out of the first five calls.
Create separate result columns for each wallet assumption. Use the same formulas and sort rules, and retain the input version beside the output. Microsoft's Scenario Manager documentation describes saved input sets; a simple three-column worksheet also makes the assumptions inspectable.
For a book-level scenario, sum sales and wallets before dividing. A weighted calculation can be checked using Microsoft's SUMPRODUCT documentation, but do not average account shares. Report the revenue population excluded for missing wallets separately.
Ask for the smallest piece of evidence that could change the decision: the category's annual spend, sites included in the tender, or the current supplier split. Assign an owner and review date. Preserve the original range so the team can see whether the new information genuinely narrowed uncertainty.
Use backtesting to improve future estimates; sensitivity tests do not establish that an estimator is accurate. Bring a sample to Covirage's share-of-wallet review to discuss the fields and review outputs your team needs. The proposed sensitivity analysis depends on available evidence and agreed setup.
Only if a documented statistical method supports that interpretation. Customer statements, judgment and alternative scaling assumptions usually produce scenario ranges. Label them as such and record where each boundary came from.
Flag an inconsistent denominator and investigate category, period, currency and estimation assumptions. Do not silently force the wallet to equal sales; that hides the failure and invents a fully captured account.