Retail Promotion Planning Software: Why the Ad Circular Deadline Beats the Forecast

Why the promo calendar is run by a print deadline rather than a forecast

The ad circular has a pagination deadline weeks before the offer runs. That deadline is immovable because a printer has a press slot. Everything upstream bends to it. The merchandising team fills the front page with items suppliers will fund, fills the inside pages with whatever the category managers propose, and the whole thing is assembled in a spreadsheet with a tab per week and a tab per page. Someone checks that the same item is not on two pages. Nobody checks what the offer does to the items next to it.

Then it runs. Volume moves. Some of it is incremental. Some of it is people who were going to buy the item anyway at full price. Some of it is people who bought the promoted brand instead of the private label sitting next to it at twice the margin. Some of it is pantry loading that flattens the next four weeks. Post event evaluation, if it happens, compares promoted week sales against a prior period and calls the difference lift, which is a measurement so crude it can make a margin destroying offer look like a success.

Meanwhile the funding side runs on a parallel track. Supplier deals are agreed by category managers, recorded in a deal sheet, accrued by finance from a summary, and claimed months later against documentation nobody can tie back to a specific offer on a specific page in a specific week. When a supplier disputes a claim, the retailer's evidence is an email chain.

Problem 1: the forecast ignores everything except the promoted item

A promotion has four effects and most planning processes model one. There is the direct lift on the promoted item. There is cannibalisation, where the offer steals volume from the items around it, including your own private label. There is halo, where the offer drives traffic that buys other things. And there is forward buying, where a customer stocks up and disappears from the category for three weeks.

Get the first right and the other three wrong and you can run a promotion that increases category volume, increases footfall, and destroys category margin, which is exactly what happens when a well funded national brand offer quietly moves shoppers off private label for a month. The category manager reports strong lift and the finance team wonders why margin fell.

Revionics and Eversight are serious about offer testing and price experimentation, and if your question is which price point performs best they are worth talking to. Where they are weaker is being the operational calendar of record: the thing that holds pagination, offer mechanics, funding commitments and store execution in one place. Blue Yonder and Oracle Retail Promotion Planning do hold that, but they hold it inside a full merchandising suite, so if you are not on the suite the honest answer is that you are buying the suite. That is a program, not a project.

What a custom build does: forecast at category level rather than item level, using your own transaction history to estimate substitution between items in the same subcategory and the pantry loading pattern for that product type. Not perfectly. Directionally, with the assumptions on screen. The output the merchandising team needs is not a precise number, it is a warning that this offer is projected to move 40 percent of its volume off your private label, before the page goes to print.

Problem 2: the mechanic in the plan is not the mechanic the POS executes

Buy two for five. Spend thirty save five. Mix and match across a group with different regular prices. Cheapest item free. Threshold offers with exclusions. Digital coupons that stack with a shelf offer or do not, depending on a flag set by someone else.

Every one of these behaves differently at the register, and the exact behaviour depends on your POS promotion engine: how it allocates discount across lines, what it does when a customer buys three in a two for offer, whether it stacks with a loyalty offer, how it handles the item being out of stock. If your forecast assumed one behaviour and the register does another, your funding calculation and your margin projection are both wrong, and you find out in the post event report.

What a custom build does: model the mechanic exactly as your POS executes it, and prove it by replaying historical baskets through the model. This is a concrete, testable step. Take last quarter's transactions containing that mechanic, run them through the simulator, and check that the discount the model computes matches the discount the register actually gave, to the cent. If it does not match, the model is wrong and every forecast built on it is wrong. We treat this as a gate before any forecasting work starts.

Problem 3: vendor funding has no audit trail back to the offer

Funding arrives in several shapes. Off invoice deals reduce cost for a window. Bill backs are claimed after the fact on units sold. Scan backs pay per unit scanned during the offer. Ad fees and display fees are fixed payments for placement. Some deals are agreed verbally by a category manager and written down later.

The retailer's problem is evidencing what was earned. To claim a scan back you need scanned units in the promotional window at the agreed price, by store if the deal is regional. To claim an ad fee you need proof the item ran on the agreed page in the agreed week. When the supplier's own records disagree, and they will, the discussion is decided by whoever has better documentation.

What a custom build does: make the offer the primary object and hang everything off it. The deal terms, the pages and weeks it appears in, the stores in scope, the actual scanned units at the actual promotional price, the accrual raised, the claim submitted and the cash received. Then a claim is generated from data rather than assembled from memory, and a dispute is answered with a report rather than an email search. This alone is often the piece that funds the build, because unclaimed and underclaimed funding is quiet money that never shows up as a loss on any report.

Problem 4: the store cannot execute what the plan assumed

A promotion needs a shelf talker, sometimes a display, sometimes a secondary location, sometimes an end cap that is already promised to another category that week. Stock needs to be there in enough depth to survive the weekend. If any of that fails, the offer runs at the register with no visibility and the sales lift never materialises, but the funding obligation and the margin give away are both real.

What a custom build does: generate a store execution pack per week from the same plan that generated the ad, including the display list, the point of sale material required and the expected uplift so the store knows what to order. Then close the loop with a simple compliance check, a photo or a checklist, so a category manager can see which stores actually set the display before drawing conclusions from the results. Half the promotions that look like failures were never executed.

Problem 5: post event evaluation is a comparison to nothing

Most evaluation compares promoted period sales to the prior period, or to the same weeks last year. Both baselines are contaminated: the prior period may have contained another offer, last year may have had different weather, a competitor may have run something. The result is a lift number nobody argues with because nobody can defend an alternative.

What a custom build does: construct a baseline from non promoted stores or comparable non promoted weeks, subtract cannibalised volume from the substitution model, subtract the pull forward from the following weeks, and report incremental margin after funding rather than lift. That number is smaller than the one your current report shows and it is the only one worth managing. Expect the first quarter of honest evaluation to be uncomfortable, because a proportion of your promotional calendar has been running on faith.

What this costs and how long it takes

A focused first release, meaning the promotional calendar with pagination, mechanic modelling validated against historical baskets, deal and funding capture linked to the offer, and store execution packs, runs $80,000 to $160,000 and ships in 12 to 16 weeks. A full platform adding category level forecasting with cannibalisation and pull forward, accrual and claim generation with finance integration, post event evaluation with constructed baselines, and supplier facing visibility runs $200,000 to $450,000 phased over 8 to 12 months.

What drives cost up in promotion work specifically: the number of distinct mechanics your POS supports and therefore has to be simulated, because each one is separate modelling and separate validation; digital and personalised offers, since a targeted coupon changes the baseline per customer and the evaluation logic with it; and multi banner operations, because a deal negotiated centrally and executed differently per banner doubles the funding model. What keeps it down: start with the weekly ad and your top three funded categories, get the mechanic simulator right, and add forecasting once the plumbing is trusted.

Build versus buy, and when buying is the right call

Buy if you are on Oracle Retail or Blue Yonder end to end. The promotion module is next to your item, price and sales data, and a custom build would spend a third of its budget on integration you already have. Buy Eversight or Revionics if your genuine question is which offer or price point wins and you are comfortable with a testing engine that sits alongside your existing calendar rather than replacing it. Buy nothing at all if you run a handful of price cuts a month with no supplier funding, because a shared calendar and a competent category manager is enough.

Build when two or more of these are true. Vendor funding is a material part of your category margin and you cannot evidence claims from data. Your ad circular is planned in spreadsheets and the pagination is the real system of record. You run mechanics your suite cannot model, or your POS behaviour differs from what your planning tool assumes. You operate multiple banners with different pricing and different funding. Or your post event evaluation is a prior period comparison that nobody in finance believes.

The tipping point is funding. If promotional money from suppliers is a serious line in your P and L, the audit trail from offer to claim is worth building on its own, and the forecasting is a bonus you earn later.

How to choose a developer for promotion planning software

Ask them how they will validate the mechanic simulator. The correct answer is replaying historical baskets and reconciling computed discount against actual register discount to the cent. Anyone who does not propose that has not built one of these and will hand you a forecast resting on an assumption nobody checked.

Ask how funding is modelled. If they describe a deal as a percentage on a purchase order, they are thinking about buying rather than promotion. You need off invoice, bill back, scan back and fixed placement fees as distinct objects, each with its own evidence requirement.

Ask what baseline they will use for evaluation and listen for whether they mention control stores or comparable non promoted weeks. Prior period comparison is the answer that means they will build you the same unreliable report you already have, in a nicer interface.

Ask who owns the code, the forecasting models and the funding data, and settle it in the contract before kickoff. At Digital Heroes the client owns the repository and the infrastructure accounts from the first commit. Promotional funding history is commercially sensitive data about your supplier negotiations, and it should never sit in an agency's account.