The Sunday night rebuild takes about two hours. Export thirteen months of orders from Shopify, download the Amazon business report and the settlement file, paste both into the workbook, net off the refunds you can find, and rebuild next month by SKU before the Monday planning call.
Demand forecasting automation for ecommerce is worth scoping around where those two hours go, because almost none of them go on forecasting. They go on assembly: matching an Amazon listing to a Shopify variant, deciding which month a refund belongs to, working out which orders shipped and which were cancelled. That work repeats every cycle and follows rules, so it automates. The call at the end of it, what a launch will sell or how much of a promotion is new demand, does not.
What demand forecasting automation for ecommerce takes over
Five jobs, in the order they cost a planner time.
- One product across every channel. A Shopify variant SKU, an Amazon seller SKU and its ASIN, a bundle listing that consumes three units of one component: a forecast at product level means nothing until all of them resolve to one item, with the bundle decomposition stated and dated.
- Refunds and returns assigned to a stated period. A refund settled in April against a March order reduces April in the export and reduces March in the demand history, and both versions are defensible until someone writes down which one the forecast uses.
- Cancelled and partially fulfilled orders separated from units. A cancelled order was demand you did not convert, and a split shipment puts one order into two weeks. A history counting ordered units and a history counting shipped units differ by exactly those two things, so a model fed one and reviewed against the other looks broken when it is not.
- Marketplace fees kept out of the unit series. Referral, fulfilment and storage fees arrive in settlement files at a different grain from the orders, and a planner who joins the two by hand ends up with a units column missing every order the settlement period did not cover. Fees belong in the margin work, which SKU-level margin analysis across channels covers.
- One calendar and a version you can point a tool at. Settlement periods, the store day and your fiscal month produce three different monthly totals from identical orders, and late refunds keep changing a month after you have planned against it, so the history needs dated versions and a record of what moved.
Not one of those five is a modelling choice. They are bookkeeping about your own demand, and in most brands they live in a single workbook maintained by the person who remembers which Amazon SKUs were relisted last spring.
Why the ecommerce history keeps moving after the month closes
No system holds ecommerce demand as one series. Shopify holds orders at daily grain, on its own variant SKUs, with its own treatment of discounts and shipping. Amazon Seller Central holds units against listings and a settlement stream that arrives days later and gets restated. Stripe knows what cleared and what was charged back, not what shipped. The 3PL knows what left the building. Subscription billing generates orders nobody decided to place this month.
Each of them answers the question it was built for. Demand history is what you get after joining them, and the join is where the unwritten rules get decided again every cycle: whether a refund reverses the week of the order, whether a cancelled order counts as demand, whether a three-pack is one unit or three. A spreadsheet column accepts any of those answers and records none of them, which is why two people rebuilding the same thirteen months arrive at different files and neither can say why.
- Channel SKUs, unmatched
- Refunds in a later month
- Cancellations inside the units
- One product, bundles split
- Refunds on the order week
- Orders and shipments apart
Keeping the history from moving
This is the point the Sunday workbook stops working, and it is the job we built Permute for. We connect Shopify, Amazon Seller Central, Stripe, NetSuite or whichever system holds landed cost, the 3PL feeds and the rest of the systems we connect, then resolve every channel identifier to one product record, with bundle components and pack conversions attached and dated, which is the Data Foundation layer doing the half of this work nobody volunteers for. A unit of demand, a refund, a cancellation and the reporting week are written once as explicit rules, so the number in the planning file and the answer to a question typed in plain language come out the same. A planner asks for thirteen months of weekly units by channel, net of refunds, on the fiscal calendar, and gets it with the rows behind it: this order, this settlement line, this feed, received at this time. When Amazon restates a settlement period, the history changes and the workspace records that it changed, which is what lets a forecast review separate a method problem from an input that moved underneath it. Access follows the same rules, so an agency with a login sees the channel it runs and nothing else.
We are not a forecasting engine. The projection belongs in a planning tool, a statistical model, or the planner who has run this category for six years, and what we hand that tool is a governed history it can run on without being rebuilt first. We read from Shopify and Amazon rather than writing back into them, so a purchase order, a price change or a listing edit still happens in the system that owns it.
Assemble the history once instead of every cycle
Connect Shopify, Amazon Seller Central and your accounting system, then pull thirteen months of weekly units by channel, net of refunds.
The calls automation cannot make
A product going live in three weeks has no history, so its number comes from an analogue, the launch plan, and the media behind it. Each of those is a judgement, and no amount of clean data converts it into arithmetic. What the layer underneath contributes is a defensible analogue: the closest product you have already sold, at the same channel mix, on the same calendar, counted the same way, rather than the one the person building the deck happened to remember.
A promotion is the same problem pointed the other way. The question is how much of the lift is new demand and how much is pulled forward from the weeks after it, and the answer turns on the discount depth, the audience you sent it to (a list discounted four times this year behaves differently from a cold one), and whether the last three promotions taught people to wait for the next one. A clean history narrows the range and does not settle the number.
The division holds across the neighbouring jobs too. Inventory planning automation: what to automate first draws the same line between assembly and decision on the stock side, and How to automate Shopify reports on a schedule covers the weekly reporting built from the same joined data.
Whether automation will help your forecast
Run this against the last thirteen months before you change anything about the model.
- Rebuilding last quarter today produces the units you planned against, or you can name every difference and the settlement file it came from.
- A refund settled last month against an order from two months ago lands in one stated period, and the planning file and the P&L use the same one.
- A bundle or multipack listing decomposes into component units without a lookup table someone edits by hand.
- Cancelled and partially fulfilled orders are visible as their own lines rather than absorbed into the unit total.
- The same product sold through Shopify, a marketplace and a wholesale account rolls up to one item with no mapping step in between.
- A week your best SKU was out of stock is marked as a supply constraint rather than read by the model as falling demand.
Three or more failures put the model at the back of the queue this quarter. The general case across retail and distributor channels sits in CPG demand planning starts with the sales history, and the error patterns that grow out of a history like this one are in Demand forecasting mistakes that a better model will not fix.
The review improves before the accuracy does. When the history holds still between cycles, a miss is attributable to a method or an assumption someone can defend, and the planning call stops opening with an argument about whose export is right.
Bring last cycle's workbook
We will look at how your ecommerce demand history is assembled today and what it would take to hand your planning tool a version that holds still.
Questions ecommerce planners ask about forecasting
Should we forecast on orders or shipped units?
Orders are closer to demand, because a shipment carries your own fulfilment and stock decisions inside it. Forecast orders, then convert to shipments with a stated fill assumption when the output feeds purchasing.
What matters more than the choice is that one series is used consistently and the other is available beside it. A model trained on orders and reviewed against shipped units will be blamed for a gap that belongs to the fill rate.
How should a week we were out of stock be treated?
As a censored observation rather than a demand number, because the units sold that week describe your inventory rather than the market. Left in raw, a stockout teaches the model that demand fell, which reduces the next order and repeats the stockout.
The practical fix is to flag the period and substitute an estimate from the weeks around it, with the flag kept visible so a reviewer can see the number was adjusted and why.
Do subscription orders belong in the forecast?
Keep them as a separate series. Recurring orders are largely known in advance from the active subscriber base and the churn rate, so forecasting them alongside one-off demand hides both the churn trend and the underlying acquisition trend.
Add the two series at the end, after the subscription number has been built from subscribers and skip rates rather than from last year units.
Can our planning tool do this assembly itself?
Planning tools import history and expect it to arrive resolved: one product key, one calendar, one definition of a unit. Most will accept whatever you load, which is why a bad history produces a confident forecast rather than an error.
The assembly is a data question that sits before the tool, and consumer brands running several channels usually solve it once, underneath, rather than inside each tool that needs it.