Designing Slab-Based Volume Incentives for FMCG Distributors (Bronze to Platinum)
How to design slab-based volume incentive schemes for Indian FMCG distributors — incremental vs retroactive slabs, thresholds, the payout lookup table, Excel.
In short
A slab-based volume incentive pays a distributor at rates that step up with achievement — Bronze, Silver, Gold, Platinum tiers, each with a threshold and a rate. The two design decisions that matter most: whether a higher slab re-rates the whole turnover or only the increment, and where the thresholds sit relative to each distributor's realistic baseline.
A slab-based volume incentive pays a distributor at rates that step up with achievement — Bronze, Silver, Gold, Platinum tiers, each with a threshold and a rate. Done well, it makes the next tier worth chasing; done carelessly, it subsidises purchases that would have happened anyway and detonates at the slab boundaries. This guide covers the design decisions in order of consequence: slab type, thresholds, the payout lookup table, the Excel reality, and the pitfalls.
Scope note: this is the distributor-scheme side. Slab structures for your own salesforce are a different design problem — covered in designing a sales incentive plan.
What is a slab-based volume incentive?
The structure is simple: define achievement (purchases from you, or sales through to the market, for a period), set thresholds, and attach a rate to each band. Naming tiers — Bronze, Silver, Gold, Platinum — is more than decoration: it gives the field team a vocabulary ("get them to Gold this quarter") and the distributor a status ladder that outlasts any single period. Slab schemes are the workhorse of FMCG trade schemes because they scale one design across hundreds of distributors of different sizes — each distributor meets the ladder at their own rung.
Incremental or retroactive: the fork that decides everything
The single biggest design decision is what crossing a threshold does.
Incremental (marginal) slabs work like income-tax brackets: each rate applies only to the turnover inside its band. Costs are predictable, accruals move smoothly, and no single order changes the rate on money already earned. The trade-off: the jump to the next tier is worth little at the margin, so the boundary pulls weakly.
Retroactive (whole-turnover) slabs re-rate the entire achievement at the highest slab reached. Crossing ₹50 lakh doesn't just pay more on the next rupee — it lifts the rate on all fifty lakh. The boundary becomes genuinely magnetic, which is why FMCG schemes lean retroactive. The costs: scheme expense concentrates unpredictably at thresholds, accruals swing each time a distributor crosses one, and every mechanism in the pitfalls section below gets stronger. The re-rating arithmetic is also where manual calculations break most often — the claim-calculation guide walks the failure modes.
Pick deliberately. A retroactive design with tight anti-gaming controls beats an incremental design nobody stretches for; an incremental design beats a retroactive one you can't police.
Where should the thresholds sit?
Thresholds are the scheme. Set them from distributor baselines, not from your sales target arithmetic: pull each distributor's trailing achievement (seasonality-adjusted — an agri-inputs Q2 is not a Q4), segment the base, and place each tier so that a meaningful share of distributors sits just below a boundary at period start. A threshold everyone clears is a discount; a threshold nobody clears is decoration. The distribution to aim for: every active distributor within striking distance of some rung.
Two structural choices follow. Period: quarterly is the FMCG default — see the FAQ for the trade-offs. Base: primary or secondary sales — qualifying on what the distributor buys is measurable from your invoices but loadable; qualifying on sell-through rewards the behaviour you actually want but lives on secondary data quality.
The payout lookup table
Write the scheme as one table before you write the circular prose. This is the artefact practitioners search for — the payout lookup table — and it is the difference between a scheme and an argument:
All figures illustrative.
| Tier | Quarterly purchase threshold | Rate (retroactive, whole turnover) | Payout at threshold |
|---|---|---|---|
| — (below Bronze) | under ₹25,00,000 | 0% | ₹0 |
| Bronze | ₹25,00,000 | 1.0% | ₹25,000 |
| Silver | ₹50,00,000 | 1.5% | ₹75,000 |
| Gold | ₹1,00,00,000 | 2.0% | ₹2,00,000 |
| Platinum | ₹2,00,00,000 | 2.5% | ₹5,00,000 |
Reading it exposes the design: crossing into Silver at ₹50 lakh lifts the payout from ₹50,000 (had Bronze's 1% applied) to ₹75,000 — the boundary is worth ₹25,000, which is the pull. It also exposes the cost: a distributor landing at ₹49 lakh versus ₹51 lakh is a 50% payout difference on 4% more turnover, which is exactly where disputes and gaming concentrate. Publish the table in the circular, keep one authoritative version, and make sure the settlement recomputes from it — not from a copy.
Building it in Excel — and where it breaks
Every slab scheme starts life in a spreadsheet, usually as nested IFs — =IF(ach>=20000000,2.5%,IF(ach>=10000000,2%,IF(ach>=5000000,1.5%,IF(ach>=2500000,1%,0))))*ach for a retroactive design — or, better, a VLOOKUP/XLOOKUP with approximate match against the lookup table, which at least keeps the thresholds in one visible place. The Excel incentive-calculation guide covers the formula patterns.
Excel's breaking points are structural, not formula bugs: the workbook forks into versions the moment it's emailed; a mid-period threshold revision silently re-rates history; returns arrive after the payout and nothing claws back; and when a distributor disputes the number, the "calculation" is one analyst's file rather than a shared record — the revenue-leakage pattern in miniature. Excel is the right drafting tool and the wrong settlement system.
Design pitfalls (the boundary is where schemes fail)
- Quarter-end loading — orders pulled forward to cross a threshold, then returned in week one. Net returns out of achievement before rating, and watch returns without clawback.
- The achievement spike — a distribution of final achievements that bunches just past each threshold is the fingerprint of gaming; a bunching just below is the fingerprint of sandbagging for next period's baseline.
- Threshold inheritance — copying last year's slabs onto this year's baselines quietly converts stretch tiers into entitlements.
- Blending scheme types — a slab incentive stacked on a QPS and an early-payment discount, all computed on the same invoices, is three schemes' leakage in one settlement. Keep bases distinct and document stacking rules.
- Settling from memory — the slab that matters is the one in the published table, applied to verified achievement, with the working shown on a settlement factsheet.
Where systems take over
Everything above has a manual version and a breaking point. ClaimDS holds the slab definition on the rebate agreement as the single authoritative table, accrues achievement against it as transactions land, recomputes entitlement — incremental or retroactive — at settlement from invoice-level data, nets returns before rating, and shows the working on every settlement. The scheme designer's job stays creative; the arithmetic stops being anyone's job. To pressure-test a slab design against your own distributor base, book a demo.
Frequently asked questions
What is a slab-based volume incentive?
A scheme that pays a distributor at rates stepping up with purchase or sales achievement — for example 1% on reaching ₹25 lakh, 1.5% at ₹50 lakh, 2% at ₹1 crore, with tiers often named Bronze, Silver, Gold and Platinum. The design intent is to make the next slab worth chasing, so the incentive changes buying behaviour instead of rewarding what would have happened anyway.
What is the difference between incremental and retroactive slabs?
Incremental slabs pay each rate only on the turnover inside that band, like income-tax brackets. Retroactive (whole-turnover) slabs re-rate the entire achievement at the highest slab reached — so crossing a threshold lifts the payout on every rupee, not just the increment. Retroactive slabs motivate harder at the boundary but cost more, swing accruals sharply, and are the ones spreadsheet formulas most often get wrong.
What is a payout lookup table in scheme design?
The single reference table that maps achievement to payout for a scheme: each row a slab, with its threshold, rate, and the payout at key achievement points. It is the scheme's contract in numeric form — the circular's slabs written so a distributor, a salesperson and a finance analyst all read the same payout for the same achievement, which is precisely what prevents settlement disputes later.
How many slabs should a volume incentive scheme have?
Three to five in most FMCG designs — enough that every distributor segment has a reachable next tier, few enough that the scheme is explainable in one conversation. More slabs than that usually signals thresholds copied from a price list rather than designed from distributor baselines. The test: every active distributor should sit within striking distance of some boundary, or the scheme moves nobody.
Should slab schemes run monthly, quarterly or annually?
Quarterly is the common FMCG default: long enough to smooth ordering noise, short enough that the target stays vivid and payouts arrive while behaviour can still respond. Annual slabs suit strategic growth targets but need quarterly accrual and communication to stay motivating; monthly slabs chase noise and invite quarter-end-style loading every month. Whatever the period, settle quickly after it closes.
How do you stop distributors gaming slab boundaries?
Design for the boundary, because behaviour concentrates there. Retroactive slabs plus a hard period-end invite loading — orders pulled forward to cross the threshold, then returned. Counters: qualify slabs on sell-through rather than sell-in where data allows, net returns out of achievement before rating, cap the re-rated jump between adjacent slabs, and watch the achievement distribution — a spike just past each threshold is the fingerprint.
Are slab incentives calculated on primary or secondary sales?
Either — and the choice changes the scheme's meaning. Primary-based slabs reward what the distributor buys from you and are easy to measure from your own invoices, but can be loaded. Secondary-based slabs reward what the distributor actually sells through, which is the behaviour you usually want, but depend on believable secondary data. Many designs qualify on primary and gate on secondary evidence.
See ClaimDS on your own claims data
A 30-minute walkthrough tailored to how your channel actually settles claims.
Related posts
QPS Full Form in FMCG: Quantity Purchase Scheme, Explained
QPS stands for Quantity Purchase Scheme — a distributor incentive that pays on purchase quantity or value in a period. Definition, worked example, and when it's used.
Supplier, Dealer, Vendor and Trade Scheme Incentives: What's the Difference?
Supplier incentive, dealer incentive, vendor rebate, trade scheme — used interchangeably but different things. A clear guide for Indian businesses.
Seasonal Schemes and Liquidation in Agri-Inputs
How seasonal schemes and liquidation claims work in Indian agri-inputs — schemes timed to Kharif and Rabi, sell-through targets and season-end settlement.