The Peak Our Forecast Cannot See
Our demand forecast adds twenty-five per cent in March, June and December. Those months are written into the code as a list, they are the same for every customer in every country, and the comment beside them in the source says "mock logic". In a market whose single largest demand event moves eleven days earlier every year, that is not a small approximation.
There is a line in our forecasting service that decides whether next month is a busy one. It reads: if the month is March, June or December, multiply expected demand by 1.25. Otherwise, do not.
That is the whole seasonality model. Not a parameter, not a per-item profile, not something learned from your own history — a list of three numbers, identical for every organisation using the product, in every country, in every industry.
We are writing about it because the market this page is aimed at is the one where the approximation fails most completely, and because the failure is silent. A forecast that is 25% high in a flat month and flat in a peak month does not produce an error message. It produces a number that looks like a forecast.
What the forecast actually does
The honest half first, because it is real work and it is the part you would keep.
Consumption is measured over two windows — the last thirty days and the last ninety — and blended. The weighting between them is a per-organisation setting with three positions: conservative leans on the ninety-day history, responsive leans on the recent thirty, balanced sits in the middle. That blended figure is your velocity. From it the system derives a predicted thirty-day demand, an expected stockout date, and a suggested reorder quantity that accounts for lead time and safety stock.
All of that is defensible. A velocity blend with an adjustable recency weight is a reasonable model for a business with no strong seasonality, and the sensitivity setting is a genuine acknowledgement that some catalogues turn faster than others.
The blend is a model. The seasonality is a list of three months and a constant, and it has never been anything else.
Why three fixed months cannot work here
Indonesian retail, distribution and manufacturing run on a demand curve dominated by Ramadan and Idul Fitri, and by the mudik travel period around them. Volumes in food, beverages, packaged goods, clothing, transport and cash logistics do not rise politely by a quarter — they move by multiples, and then they collapse for a fortnight.
The structural problem is not the size of the uplift. It is that the peak is set by a lunar calendar and drifts roughly eleven days earlier against the Gregorian one every year. Over a decade it walks through the entire calendar. A rule that names March, June and December is therefore not merely mistuned — it is tracking a different clock, and it will be right by coincidence for one year in a cycle and wrong for the rest.
| Demand event | How it moves | What a fixed-month rule does |
|---|---|---|
| Ramadan and Idul Fitri | About eleven days earlier each Gregorian year | Tracks it by accident, at most, for one year in a cycle |
| The post-Lebaran collapse | Moves with the peak | Nothing — there is no negative factor at all |
| Lunar New Year in Chinese-Indonesian trade | Late January to late February | Never covered; neither month is in the list |
| School year intake | Mid-year, broadly stable | June is in the list, so this one is roughly served |
| Wet and dry season effects on construction supply | Broadly stable, region-dependent | Partly served, by luck |
The fourth row is the interesting one. A fixed rule is not always wrong, and where it happens to be right nobody notices there is no model underneath it. That is what makes the whole thing dangerous rather than merely crude: it is plausible often enough to be trusted.
What this costs, concretely
One fast-moving SKU through a moving peak
The multiples above are illustrative and deliberately not sourced. The point is the direction and the mechanism, not the magnitude: the error is not random noise around the right answer, it is a systematic miss in a known direction on a known date.
And notice the second-order effect. The suggested reorder quantity is derived from the same understated demand, so the system does not merely mis-predict the peak — it advises you to under-buy for it, in writing, with a number that looks calculated.
What to do instead, this year
Four habits that beat the model without waiting for anybody to build anything
- Treat the forecast as a velocity read, not a plan. It tells you honestly how fast something has been moving. Take that and apply your own multiple.
- Set sensitivity to responsive in the weeks before your peak and back to balanced afterwards. A thirty-day-weighted blend picks up a ramp faster, which is the closest thing to seasonality the product actually has.
- Build your peak buy from last year's actual movement over the same lunar window, not from the same calendar month. Our reports will give you movement between any two dates, so the window you choose is yours.
- Write down the collapse as well as the peak. Most operations plan the build-up and get caught by the fortnight afterwards, which is where the dead stock is made.
That third habit is the one that does the most work, and it does not need a feature. The system holds every movement with a date. The skill is asking it about the right dates.
Four questions for any vendor selling you a forecast
How to find out in twenty minutes whether a forecast is a model or a constant
Which months does your seasonality apply to, and where is that configured?
A good answer sounds like
A per-item or per-category profile, editable, derived from history.
What it actually means
If the answer is a fixed list, ask to see the list. Ours is March, June and December, and we are telling you that before you ask.
Show me the forecast for an item whose peak is lunar.
A good answer sounds like
The uplift moves with the event across years.
What it actually means
Any calendar-month model fails this, regardless of how it is presented in the interface.
Does the model ever forecast a decline?
A good answer sounds like
Yes — troughs are modelled as well as peaks.
What it actually means
Uplift-only models systematically over-buy across a full year, because nothing ever pulls the number down.
How much of my own history does it use?
A good answer sounds like
A named window, and a statement of what happens with less.
What it actually means
A forecast that needs three years of data is not a forecast for a business in its second year.
Our position
Use the velocity, ignore the seasonality. The blended thirty-and-ninety-day figure is a genuine and useful read on how fast your stock is moving; the seasonal factor is a hardcoded 25% in three Gregorian months and should not be part of any purchasing decision you make in this market. Plan your peak from last year's movement over the same lunar window, which the reporting will give you today.
What AWRA OpsHub does today
- A blended 30-day / 90-day consumption velocity per item, with a per-organisation sensitivity setting at conservative, balanced or responsive.
- Predicted 30-day demand, an expected stockout date, and a suggested reorder quantity that accounts for the item's lead time and safety stock.
- Movement history against every item with dates, so any window you choose can be measured directly.
- Dead-stock scanning on a daily schedule with a per-organisation idle threshold, and batch-expiry alerting on a 30/60/90 horizon.
What it does not do
- Learned seasonality of any kind. The uplift is a hardcoded 25% applied in March, June and December, identical for every organisation and every item.
- Any lunar, fiscal or custom calendar. There is no way to tell the system when your year peaks.
- A downward seasonal factor. The model can only ever raise a forecast, never lower it.
- Per-item or per-category demand profiles. One rule covers the whole catalogue.
Not ours, by choice
- The comment beside the rule in our own source calls it mock logic. We are not discovering this; we are publishing it.
- None of this affects recorded history. Stock figures, movement records and valuation are unaffected by the forecast — only the prediction and the suggested reorder quantity are.
- The multiples used in the worked example above are illustrative. We have not measured Indonesian peak ratios and we are not going to publish a number we cannot source.
What is not built for your market today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in your market. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a tax authority pipeline, a local-language interface, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Tax authority pipelines and reporting
Electronic invoicing against your authority's published interface or its accredited network, with retries, a failure queue and a daily report of sales that never reached it. The regimes here range from a live clearance model to a purely voluntary scheme, so this is one build per country and we will say which country rather than sell an ASEAN integration that does not exist.
Local-language interface, banks and wallets
Interface text and document templates in the language your finance floor and your statutory documents actually require, plus real-time payment collection, e-wallet settlement and bank statement feeds wired into the Payments Register.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
Social security, provident fund and withholding computed on live records, with the contribution files produced in the layout each agency expects and any statutory bonus accrued through the year rather than found at the end of it.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedPlan your next peak from your own numbers
If your demand event moves with a calendar our forecast does not know about, the movement history it sits on is still the best evidence you have. Talk to us about pulling the right window and sizing the buy from it.
Talk to the teamFrequently asked questions
Can I change which months get the uplift?
No. The months are written into the code as a list, not held as a setting, so there is no screen where they can be edited and no per-organisation override. The only forecast control exposed to you is the sensitivity setting, which changes how much weight the recent thirty days carry against the previous ninety.
Does the 25% uplift affect my stock valuation or reports?
No. It affects the predicted demand figure, the expected stockout date and the suggested reorder quantity. Recorded stock, movement history, valuation and every report built on them are unaffected.
What would a real seasonality model need?
At minimum a per-item or per-category profile, at least a year of history to learn from, a calendar the profile can be anchored to that is not necessarily Gregorian, and the ability to forecast a decline as well as a rise. That is a substantial build rather than a configuration change, and if it is decisive for you we would rather scope it properly than describe the current rule as something it is not.
