Pilot Data Checklist for Trade Promotion Management (TPM)

To prepare for a trade promotion management (TPM) pilot, confirm five required data sets before it starts: a store or outlet master with stable identifiers, a product and SKU master, a promotion calendar with mechanics and rules, a budget and spend structure, and an agreed standard for execution evidence tied to a defined sales measurement scope. A pilot can only test what the data allows it to see. Everything else – historical campaign records, competitor notes, shelf condition photos – is useful but optional and should not delay the start.

Quick answer: what to prepare before a TPM pilot

• Store or outlet master: one record per outlet with a stable ID, channel, territory and active flag.
• Product and SKU master: codes, descriptions, brand, pack size and case configuration that match order and sales data.
• Promotion calendar and mechanics: campaign name, dates, mechanic, participating SKUs, target outlets and owner.
• Budget and spend structure: approved budget, spend type, period, cost owner and written claim rules.
• Execution evidence and sales measurement scope: evidence type, capture timing, reviewer, acceptance criteria, baseline, pilot period, outlet and SKU sets, and data source.

What a TPM pilot is meant to prove

TPM covers planned promotional activity across trading partners and retail execution, which differs from a general consumer advertising campaign. A pilot typically tests whether one promotional cycle can be planned, executed in stores, evidenced, reviewed and reconciled using a single set of records.

That goal sets the data requirement. If a store cannot be identified consistently, or a mechanic cannot be linked to the SKUs and outlets it covers, the exercise produces activity logs without a usable picture of what happened. For background, see what trade promotion management is and how it works.

The five required data sets

1. Store and outlet identifiers

One record per physical outlet, with an internal outlet ID, outlet name, channel type, address or geo reference, the territory or route that serves it, and an active or inactive flag. If retailers, distributors and your own systems use different codes, prepare a crosswalk table before the pilot, not during it.

2. Product and SKU master

Each SKU should carry a code, description, brand, pack size, case configuration and active flag. Confirm the SKU codes used in the promotional plan are the same codes used in order and sales data, otherwise planned versus actual comparisons break down at the first join.

3. Promotion calendar and mechanics

A usable calendar entry states the campaign name, start and end dates, the mechanic (price discount, display, sampling or bundle), participating SKUs, target outlets, the responsible owner and any channel-specific conditions. Check that two campaigns do not apply conflicting mechanics to the same store and SKU in the same period.

4. Budget and spend structure

Record the approved budget, spend type, period, cost owner and the business rules that govern claims. A simple spend review can compare approved budget, committed amounts, submitted claims and accepted settlement, provided the rules are written down. Do not assume a specific accounting treatment for your market; confirm it with finance.

5. Execution evidence and sales measurement scope

Evidence must relate to a specific store, campaign, task and period, and the standard should state the evidence type required, when it is captured, who reviews it and what counts as acceptance. Keep task completion, reviewer acceptance and business outcome separate. A photo alone does not prove sales uplift.

For measurement, define the baseline period, pilot period, outlet set, SKU set and sales data source in advance. Coverage discussions should define target stores, eligible stores, completed execution and the reporting period separately, and should not treat an assigned store as a completed store.

Optional inputs that improve results

• Historical promotion records: prior campaigns, mechanics, spend and outcomes, used to sanity-check assumptions rather than to set a guaranteed target.
• Competitor and market notes: observed nearby activity that helps explain unusual results.
• Outlet-level conditions: shelf space, planogram compliance or stock availability, useful when interpreting execution gaps.
• Baseline sales history: helpful if it covers the same outlets and SKUs consistently, but not a substitute for an agreed baseline definition.

Readiness checklist: required versus optional

Quality checks to run before the pilot starts

• Identifier uniqueness: test that every store and SKU resolves to one record, and document any code crosswalk.
• Period alignment: confirm whether the business reports by fiscal period, calendar month or week, and use one convention throughout.
• Unit and currency consistency: check case versus each conversions and the currency used for spend.
• Roles and permissions: decide who can create a plan, submit evidence, review it and approve a claim, then validate those permissions in the pilot environment.
• Exception handling: write down what happens with returns, out-of-stocks, late claims and cancelled campaigns before they occur.
• Completeness window: agree how late arriving data is handled so the review does not close on partial numbers.

Who owns each input

Name a single accountable person and a backup for each data set, plus the decision rights: who approves a change to the promotion calendar, who signs off settlement, and who resolves a disputed evidence submission. Ownership gaps usually surface as missing evidence at review time rather than as technical failures.

Acceptance questions to ask before signing off

• Can the vendor demonstrate the planning, execution, review and reconciliation scope that is actually supported today?
• Which parts are standard capability, which are configured, and which require a separate integration?
• What data sources will feed the pilot, and how frequently will they refresh?
• How are role permissions and exception cases handled and validated?
• How does the pilot count a store as covered – assigned, visited or fully executed with accepted evidence?
• Is acceptance based on task completion, reviewer acceptance or a business outcome? Define this in writing before the start.
• What baseline, time period and cost scope will be used if anyone discusses promotional return?

Limitations to state up front

Data readiness is a precondition for a fair test, not evidence of a result. Execution completion and sales changes do not on their own establish causal uplift or guaranteed return; that requires an agreed baseline, a defined time period, a cost scope and a view on other influences such as seasonality or competitor activity. Readiness also does not confirm that any vendor capability is available in your market, that integrations exist, or that local accounting and tax rules are supported – raise those as explicit verification questions.

Next step for evaluating TPM support

Airpalm describes mobile visits, route planning, store audits, sales orders, inventory and promotion management on its site (checked 2026-10-09). If a pilot is part of your evaluation, ask for a walkthrough using your own store and SKU samples so you can see how planning, retail execution and promotion reconciliation records connect. You can contact Airpalm to request that demonstration.

Frequently asked questions (FAQ)

Can this run on spreadsheet data?

Often yes for a limited scope, provided the store and SKU identifiers, promotion calendar, budget rules, evidence standard and measurement scope are agreed in advance. The constraint is usually consistency and version control rather than the format itself. Confirm with the vendor which data sources and refresh frequency will be used.

Does a photo of a display prove that a promotion worked?

No. Evidence relates to a specific store, campaign, task and period, and it supports a claim that execution happened. It does not prove sales uplift. Keep task completion, reviewer acceptance and business outcome as three separate measures, and treat any return discussion as a separate exercise with an agreed baseline and cost scope.

How should we count store coverage during the pilot?

Define the reporting period and distinguish target stores, eligible stores and completed execution. An assigned store is not the same as a completed store, so publish the definition you are using and avoid quoting a coverage rate without the supporting data.

What if our SKU or outlet codes differ from the retailer’s codes?

Build a crosswalk table before loading data, with one row per outlet or SKU and a named owner for keeping it current. Agree which code is authoritative for the pilot and map the others to it, so plans, orders and evidence can be joined to the same record.