Document every change to a live trade promotion as a new, dated version of the promotion record rather than an edit that overwrites the original. Each new version states what changed, why, who approved it, when it takes effect, and which stores, products or mechanics it covers. Field and distributor teams receive the new version and its effective date before it applies, and execution evidence stays linked to the version that was in force when the visit or claim happened.
This matters because a promotion that changes mid-flight generates two different records: what was planned and what was actually executed. Merging them makes coverage counts, claim reviews and post-promotion evaluation unreliable.
Why version control matters during trade promotion execution
Trade promotion management (TPM) covers planned promotional activity across trading partners and retail execution. A promotion is rarely static for its whole run: a launch slips a week, a retailer agrees to more stores, a mechanic proves impractical in traditional trade, or a product supply issue removes an SKU. Each of those decisions changes what the field was asked to do — and what a claim reviewer should accept.
Without dated records, three problems appear:
- Mixed evidence. Photos and visit records from the old mechanic get used to prove the new one, or visits outside the revised window count toward the campaign.
- Claim disputes. Finance reviews a claim against the original plan while the field executed the revised plan, and neither side can show the approved change.
- Unreliable coverage. The store list changes but the denominator does not, so assigned stores get reported as completed stores.
What counts as a change worth documenting
Not every note about a promotion needs a new version. A change is worth documenting when it alters what is executed, where, when, or at what cost. Use the table below as a starting filter.
| Change type | Record at minimum | Effect on evidence and claims |
|---|---|---|
| Dates (start, end, execution window) | Old dates, new dates, effective date, reason | Visits and photos outside the active window belong to a different version |
| Eligible products | SKUs added or removed, and any replacement mechanic | Only qualifying SKUs count toward the promotion; others are excluded from uplift claims |
| Participating stores | Stores added or removed, and why | The coverage denominator changes; assigned and completed stores must stay separate |
| Mechanics | Original mechanic, revised mechanic, materials affected | Evidence captured for the old mechanic does not prove the new one ran |
| Budget or funding split | Approved budget, committed amounts, revised allocation | Claims are reviewed against the version in force when they were executed |
A five-step process for documenting a mid-flight change
1. Freeze the current version
Number the live version and mark it as closing at a specific date and time. Anyone reviewing the history later should be able to see that this version applied to a defined period.
2. Raise a change record
One person — usually the promotion coordinator or trade marketing owner — captures the request in writing before it is communicated to the field. The record names the promotion, the revision it changes, and the requester.
3. Approve before the effective date
The approver depends on the change: a schedule shift may sit with the promotion owner, while a budget reallocation usually needs a finance reviewer. The approval should be recorded with a name, role and date, not inferred from an email thread.
4. Communicate the new version and its effective date
Field sales, distributor teams and merchandisers need the change and the cut-off for old instructions. A short message is usually enough: what changed, effective when, what to stop doing, what to do instead.
5. Close the promotion with the version list intact
At the end of the run, the version list becomes the spine of the retrospective. Keep it with the evidence rather than archiving it separately.
Fields every change record should carry
These fields work as a checklist. They are an educational framework, not a confirmed interface in any specific tool.
- Promotion name or identifier and new revision number
- Revision being superseded and its cut-off date
- Change category (dates, products, stores, mechanics, budget)
- Before value and after value
- Reason or trigger for the change
- Effective date and time
- Approver name, role and approval date
- Stores and products affected, or affected scope
- Communication issued to whom, on what date, through which channel
- Status of the previous version (superseded, closed)
Effective dates, cut-offs and retroactive changes
The effective date is what separates planned change from drift. State it explicitly, and state what happens to execution between the decision and the effective date. If a change is approved after the work has already happened, label it as retroactive and record the date the decision was actually made. Backdating an approval to match execution makes the history useless for review and creates avoidable friction in claims settlement.
Communicating the change to field and distributor teams
Communication should reach the people who execute, not only the people who plan. A practical message covers:
- Which promotion and which revision it replaces
- What changed and from which date
- Which stores or products are affected — and, just as important, which are not
- What evidence is required under the new revision
- Where to raise questions if a store was already visited under the old revision
Distributor and third-party merchandising teams may run their own briefing cycle, so allow time between approval and the effective date when the change touches many stores.
Keeping execution evidence tied to the correct version
Evidence should relate to the relevant store, campaign, task and period. Where a promotion has more than one revision, attach the revision to the visit or claim record so a reviewer can see which instructions applied. Three distinctions are worth preserving:
- Task completion — the field activity happened.
- Reviewer acceptance — a reviewer judged the evidence sufficient.
- Business outcome — what sales or share did, which a photo alone cannot establish.
The same discipline applies to coverage discussions: define target stores, eligible stores, completed execution and the reporting period, and avoid treating an assigned store as a completed one.
Retrospective review after the promotion ends
The change log is an input to evaluation, not a substitute for it. A spend review can compare approved budget, committed amounts, submitted claims and accepted settlement against stated business rules, and a performance review can compare outcomes against an agreed baseline, time period and cost scope. Execution completion and sales movement on their own do not establish causal uplift, and different revisions should not be pooled without saying so.
Where Airpalm fits
Airpalm publicly describes mobile visits, route planning, store audits, sales orders, inventory and promotion management as part of its field and channel offering; the company is a sales force automation (SFA), distributor management system (DMS) and trade promotion management (TPM) provider for overseas markets. How a specific change log, version control or approval routing is configured is not something the public material confirms, so treat those as questions for a demonstration rather than assumptions. If you are evaluating tools, ask what is standard, what is configured, and what requires separate integration. You can read a general explanation of trade promotion management and what it covers, or contact Airpalm with your specific scenario.
Common mistakes to avoid
- Overwriting the original plan so only the final revision survives
- Approving a change verbally and communicating it in the same message, with no record
- Changing the store list without updating the coverage denominator
- Accepting old-mechanic photos as proof of a new mechanic
- Backdating approvals to match execution dates
- Pooling evidence across revisions when reporting results
Frequently asked questions (FAQ)
Can we simply update the live promotion record instead of creating a new version?
You can, but you lose the ability to explain what the field was asked to do at a given point in time. If a claim, a coverage figure or a result is questioned later, the original instructions are the reference point. Creating a dated version and marking the previous one as superseded keeps both the plan and the execution traceable, and it usually takes less effort than reconstructing the timeline from messages afterwards.
How should we handle a change that is approved only after the work has already been executed?
Record it as a retroactive change and keep two dates: the date the change was approved and the period it applies to. State the reason for the timing. Retroactive changes are a normal part of retail execution, but hiding them by backdating the approval weakens the version history and makes claim reviews harder to defend.
Which evidence has to be collected again after a mid-promotion change?
Re-collect evidence that only proves the superseded revision. If the mechanic changed, visits executed under the old mechanic do not demonstrate the new one. If the date window moved, activity outside the active window belongs to the earlier revision. If only the store list changed, existing evidence for unchanged stores can usually stand, provided the coverage denominator is updated.
Does good change documentation prove whether the promotion worked?
No. Documentation shows what was planned, what was executed and what was reviewed. Evaluating return still needs an agreed baseline, a defined time period, a cost scope and a view on other influences such as distribution or pricing changes. Execution completion and sales movement alone do not establish causal uplift.
Put this guide into practice
This general-purpose worksheet is a starting point. Adapt its fields, responsibilities and rules to your business process.
