Price pack architecture comes down to a small number of decisions with large consequences: which pack sizes to carry, what each should cost the shopper, which channel gets which configuration, and what to do when a retailer wants an exclusive size that undercuts the one next to it.
Price pack architecture software is sold as the tool that answers those. Before comparing categories, it helps to be clear about which part of the decision is analysis and which part is data assembly, because the assembly is where the months go and no vendor demo spends time on it.
The decision the tool has to support
A pack architecture review asks whether a 6-count at one price and a 12-count at another are doing different jobs or cannibalising each other, and whether the answer differs by channel. To answer that at all, four things have to be true of the data.
- Price per unit is comparable across configurations. A 12-count carton, two 6-count sleeves and a club multipack have to reduce to a common unit before any price ladder means anything.
- Realised price, not list price. What the shopper paid is list less promotion, less marketplace fees, less the off-invoice allowance, and pack decisions made on list price flatter the large sizes.
- Channel is a defined dimension rather than a label. Club, grocery, convenience, marketplace and your own store have different fee structures, and the same pack has a different economics in each.
- Cost follows the pack. Landed cost per unit changes with pack configuration through packaging, cube and freight, so a margin comparison across sizes needs cost at the same grain as price.
Those four are definitions rather than analysis. Get them wrong and every elasticity curve drawn on top is a well-fitted answer to the wrong question.
| Input | Where it lives | The trap |
|---|---|---|
| Pack configuration and conversions | Item master in the ERP, plus retailer item files | A configuration change with no effective date rewrites last year |
| Realised price | Invoices, marketplace settlements, promotional records | List price stands in for realised price because it is easier to find |
| Channel fees | Marketplace statements and account agreements | Fees sit in a finance summary that never reaches the pack analysis |
| Landed cost per unit | ERP standard cost, freight invoices, co-packer bills | One standard cost applied to every pack size |
The categories of price pack architecture software
Four categories show up in these evaluations, and the useful question for each is which part of the decision it owns.
Revenue growth management suites own the analysis end: price ladders, elasticity, pack and price scenarios, sometimes a simulator to test a change before you make it. When a brand has the pricing question as its central commercial problem and someone to run the models, this is the right category. What none of them removes is the input requirement, and the sequence matters: a suite fed unmapped pack conversions and list prices produces a confident scenario nobody in the room believes.
Syndicated data and category analytics answer the question your own systems cannot: what competing packs cost on shelf, where the category price ladder sits, and which sizes are gaining distribution. This is the only source for the competitive half of the picture, and it is priced accordingly. It knows nothing about your landed cost, so it cannot tell you which of your own packs deserves the shelf.
BI on a modelled warehouse gives you exactly the ladder you define. Where a brand runs BigQuery, Snowflake or Microsoft Fabric with someone maintaining the model, this is a strong answer and a durable one. The cost is ownership: pack conversions, fee schedules and cost allocations are business rules that need a maintainer, and when that person moves on the analysis keeps rendering on conversions nobody has revisited.
Spreadsheets are where most pack architecture work still happens, and for a brand with one channel and six SKUs that is proportionate. The problem arrives with the third channel: the per-unit conversion is retyped for each analysis, the fee assumptions differ between two workbooks, and nobody can reconstruct why last year's review recommended the 10-count.
Where we fit
We do not model elasticity and we do not simulate a price change, so a brand that needs those should buy a suite that does. Permute sits underneath one, on the input problem the suite assumes away.
We connect the item master in the ERP (usually NetSuite at this size, sometimes something older), the marketplace settlements, the retailer files, the freight and co-packer invoices, the spreadsheets holding the fee assumptions, and the rest of the systems we connect. Pack conversions, realised price, channel and landed cost per unit are then written down once as explicit rules in the Ontology layer, with effective dates, so a pack configuration that changed in March does not rewrite the January ladder. A commercial lead can ask for realised price per unit by pack and channel for the last eight quarters and get it with the invoices, settlements and cost lines behind each figure. That traceability is the difference between a recommendation the room debates and one it relitigates, and it is what a context layer actually does. The same definitions then feed whatever sits on top, whether that is a revenue growth suite, a dashboard, or a finance model in Excel.
The honest limits: we read from the systems we connect and do not write prices back into them, and we hold no view on what your prices should be. We also cannot supply the competitive shelf picture, which comes from syndicated data and stays a separate purchase.
Compare your pack ladder on realised price
Connect your ERP and marketplace settlements, then pull price per unit by pack and channel.
How to test a vendor in one hour
Pick two packs of the same product that sell in three channels, and one quarter. Ask each vendor to show realised price per unit for both packs in all three channels, from your data, with the fee and promotion treatment visible.
Three follow-ups sort the field. Where does the pack conversion come from, and what happens when it changes mid-quarter? Which costs are included in the margin shown, and can you see the lines? And when the recommendation is challenged by the account team, what can you put on the screen? A vendor who reaches for a data preparation project at that point has told you where the work sits, which is the input layer rather than the model.
For the neighbouring decisions, SKU-level margin analysis across channels covers the cost side at product grain, and CPG analytics software: what to look for before you buy places these categories against each other. Consumer brands weighing a suite against fixing the inputs first should look at what it costs on both sides of that choice.
Bring two packs and three channels
We will show what it takes to make them comparable on realised price per unit, using your own data.
Questions commercial teams ask about price pack work
Can price pack architecture work be done without syndicated data?
Partly. Your own data answers which of your packs earns its margin in which channel, which is enough to fix an internal ladder that has drifted. What it cannot tell you is where competing packs sit on shelf, and a pack decision made without that is half informed.
A practical sequence is to fix your own realised price and cost first, then buy the competitive view when the internal picture is trustworthy.
How often should the ladder be reviewed?
Once a year as a full review, with a lighter check each quarter for drift, since promotional depth and marketplace fees move the realised ladder without anyone changing a list price.
The quarterly check is cheap once the definitions are written down and expensive when each review rebuilds the conversions from scratch.
How do club and marketplace packs get compared fairly?
By reducing both to price per unit after the fees that apply in each channel, then holding channel as a dimension so the comparison is explicit rather than averaged away. A club multipack at a low unit price can carry a healthier margin than a marketplace single once fulfilment fees are counted.
Averaging across channels is what produces the recommendation that looks right in the deck and fails in the account.
What about changing a pack size rather than a price?
A size change is a price change expressed differently, and the arithmetic works the same way once price per unit is the measure. What it needs is effective dating: the old and new configurations both existed, and a comparison that ignores the changeover date reports a price move that never happened.
That is a data modelling requirement rather than an analytical one, which is why it is usually the part that breaks.