Commercial Planning

Bottom-Up R3, Not Top-Down - Why Aspiration Can't Be a Percentage

← Back to Knowledge Center

Every consulting engagement eventually arrives at the same question: what's the target? The client has an ambition, the consultant has a framework, and somewhere between them a number has to emerge that everyone commits to. In our early modelling, we approached this with the bluntest instrument possible - a top-down percentage.

The platform knew R1, the total addressable market volume for a territory. The client had set an aspiration - say, 22% national market share in three years. So R3, the aspirational volume per territory, was R1 × 22%. Clean arithmetic. Defensible-sounding. Wrong.

Why a percentage of a ceiling isn't a target

R1 is a ceiling. It's the total volume a territory could theoretically absorb if every addressable outlet were selling the product at maximum throughput. Nobody ever hits R1 - it's not a realistic target, it's a physical maximum. Taking a percentage of R1 and calling it an aspiration is like taking a percentage of the Earth's energy budget and calling it your electricity bill. The arithmetic works. The meaning doesn't.

More specifically: the percentage you apply has no grounding in what actually produces the volume. A 22% share of a 100-million-litre addressable market equals 22 million litres. But how do you get to 22 million litres? You don't know. The top-down number doesn't tell you how many outlets you need, how often you need to visit them, how much each visit needs to sell, or what share of each outlet's wallet you need to win. It's a wish, not a plan.

A distributor handed a top-down R3 has no way to commit to it. They can accept or reject the number as a whole, but they can't break it into operational components they control. Their DSR planning has no anchor. Their coverage strategy has no anchor. Their trade marketing investment has no anchor. The target is operationally unplumbable, which is another way of saying it's not a target - it's an exhortation.

What a bottom-up R3 looks like

The real R3 is built from the outlet up. For each outlet archetype in the territory, define: number of outlets, target share of wallet (what percentage of the outlet's category purchases should flow through your product), visit frequency (how often a DSR sees the outlet), throughput per visit (how much volume flows per visit). Multiply through, aggregate across archetypes, and you get a volume number.

The number is different in kind from the top-down R3. It's accountable to specific operational commitments. If the DSR is visiting 80% of target outlets at target frequency, and each outlet is hitting target share of wallet, the volume emerges. If volume is below target, you can decompose the miss: which archetype is under-performing, on which dimension? The analysis isn't forensic; it's diagnostic. The distributor can see exactly what they need to do differently.

The bottom-up R3 also scales with effort in ways the top-down doesn't. A top-down 22% share is a single number - you're either at it or not. A bottom-up target has dimensions - coverage, frequency, throughput, wallet share - and each dimension has its own sub-target. The distributor can improve on some dimensions while lagging on others, and the system can tell the story accurately. "You're hitting coverage but missing frequency; your share of wallet per visit is on target." That's a coaching conversation, not a blame conversation.

Why we got it wrong the first time

The top-down approach was expedient. R1 was already computed - it was a core output of Module 1. Multiplying it by a percentage was trivially implementable. There was no additional data required. The formula register had room for R3 as a simple multiplication.

Bottom-up R3 is hard. It requires share-of-wallet targets per archetype, visit frequency targets per archetype, throughput assumptions per visit per archetype. Most of this data doesn't exist at engagement start. Some of it can be estimated; some requires field research; some requires client confirmation. The formula is more elaborate. The data collection is heavier. The SP has to make more calls.

We chose expedience first and regretted it. Every distributor conversation that depended on R3 was harder because the number had no operational handles. Every territory review got stuck on "what's our target?" without being able to break the target into components. Every scenario comparison felt unanchored. The top-down R3 was technically computable and practically useless.

The real home for the bottom-up build

There's a clean architectural fix: Module 1 defines the ceiling (R1) and the current state (R2). It does not invent the aspiration. The bottom-up R3 is built in Module 2, the JBP workspace, where the commercial director, regional MD, and distributor actually negotiate targets outlet by outlet. That's the right forum for the work. Senior partners from the consulting side can facilitate, but the target-setting is a joint exercise, not a deliverable handed over.

Module 1's output on the R3 question is "territory opportunity" - the gap between current R2 and ceiling R1, labelled as an indicative range pending JBP target-setting. That labelling is critical. Calling a number "opportunity" rather than "aspiration" or "growth ask" signals that it isn't yet a commitment. It's a space within which the real target will be negotiated. The module that produces the opportunity doesn't pretend to produce the target.

Boundaries between modules are often drawn where they're easy, not where they're right. Module 1 could easily have included a target-setting flow - the data was there, the UI was there, one more screen and it would have been done. The result would have been targets without accountability. By pushing target-setting into Module 2, where the people who own the targets are actually in the room, the platform forces the organisational accountability to match the analytical work. The module boundary enforces the business boundary.

The broader principle

Whenever a formula produces a number that a person is supposed to commit to, ask whether the number has operational handles. Can the person hitting the target decompose it into things they control? Can the person missing the target decompose the miss into diagnosable components? If the answer is no, the number is a wish, not a target. Move the target-setting to where the operational decomposition can actually happen, even if that means your current module produces a less tidy output.

A vertical platform that hands clients wishes instead of targets is no better than a framework on a PowerPoint. The value of computation is that it can produce numbers people can act on. Numbers that can't be acted on aren't valuable just because they're computed; they're decorative.