PLANNINGNESTPlan · Demand & supply planning

Order the right quantity before the festival, and know why the number is what it is.

PlanningNest cleans your sales history, forecasts every SKU with a likely range, and turns festivals, promotions and supplier lead times into purchase recommendations, order-by dates and cash. One plan for sales, marketing, supply planning, procurement and finance at mid-size manufacturers and distributors in India and Singapore.

Run the demo Discuss your demand planning challenge

Supermarket shelves stacked with rows of colourful canned goods

PlanningNest at a glance

1Reads

Sales history by SKU, by day, week or month, from a Tally, Xero, SAP Business One or NetSuite connector, or a CSV or Excel export
Promotion calendar from marketing; attributes of new launches
Forecast versions from sales and marketing for consensus

2Decides

PlanningNest

Which data fixes to apply (planner)
Whether to keep or override a forecast period, with a mandatory reason
How much festival cover to buy, compared as what-if scenarios, with the weekly cash alongside

3Produces

Agreed forecast, scenarios and purchase recommendations exported to Excel or CSV for the buyer
Reorder, festival and slow-mover alerts in the app, by email or on WhatsApp
Cash projection and working capital at risk for finance

↺ Learns Actuals recorded against every plan version and override back to 1 · Reads

The business problem

The festival order was due before anyone trusted the forecast

It is late September. Sales expects a strong Diwali. The contract manufacturer needs five weeks to deliver, and the reorder level in the ERP, set on average sales, says to buy the usual 2,500 cases.
Nobody has worked out that the Diwali order must be placed by the end of the month. The sales history has the same SKU under three spellings and one range booked in both boxes and cases, so the planner adds 30% "to be safe" and nobody writes down why.
In November one fast mover runs out in the peak week while another sits in the warehouse until February. Finance asks where the cash went. Next year a new planner starts again from the same spreadsheet.

Why the usual fixes fall short

Spreadsheets copy last year. They do not know that Diwali moves by weeks, cannot show a likely range, and break when SKU names change.
ERP reorder levels use average demand and a fixed buffer, so they under-call every festival and over-call the quiet months.
Large planning suites assume clean data, a long implementation and a team to run them. Mid-size companies end up back in Excel.

Every festival is planned from scratch, stock-outs and excess repeat each season, and the judgment behind every override leaves with the planner.

RevenueFestival weeks carry a large share of the year. A stock-out in the peak week is a sale that does not come back.
Working capitalBuying "to be safe" across the range ties up cash in stock that sells weeks or months later.
Supplier termsLate orders turn into rush runs, split deliveries and expensive freight, or simply no stock.
Planning knowledgeOverrides and the reasons behind them live in people's heads and leave with them.

In plain terms

What PlanningNest is, and how it fits

What it is: A demand and supply planning workspace for the monthly planning cycle (S&OP). It reads your sales history, cleans it with your approval, forecasts every SKU with a P10–P90 range, and turns the forecast into purchase recommendations, order-by dates and a weekly cash view.
Who uses it: Demand planners and the planning head use it daily. Sales and marketing feed in promotions, launches and their own forecast versions. Supply planners and buyers get purchase recommendations and order-by alerts. Finance gets the cash projection and the working capital at risk. The owner or CFO gets a one-screen executive view.
What it does: Finds duplicate SKUs, unit mix-ups, outliers and gaps; picks the best-fitting statistical model for each SKU; adds festival and promotion uplifts; works out what to order, from whom and by when, given lead time and MOQ; shows what the plan does to cash; keeps every override with its reason and its outcome.
How it fits your systems: Above your ERP or accounting system. It works with Tally, Xero, SAP Business One and NetSuite, and with CSV or Excel exports from anything else; connectors are configured per deployment. The agreed plan goes to your buyer as an export, or to the ERP after approval where write-back is switched on.
What is different: Every number shows its working: the model chosen and its back-test error, then baseline, trend, season and festival factor, then each human change with who made it and why. The statistical forecast and the planner's change are both kept, and the outcome is written beside them when actuals arrive.

See it work

PlanningNest in action

Walk a Diwali season buy for one SKU: clean history, a forecast range, the order-by date, three cover levels with their cash, a signed decision, and the result after the festival.

A simulated scenario on representative data. You choose the option and give the approval; the numbers follow your choices.

End-to-end workflow

From data to decision to outcome

What goes in, what PlanningNest works out, what gets decided, what happens next, and how the result comes back.

InputsDATA

Sales history by SKU, by day, week or month, from a Tally, Xero, SAP Business One or NetSuite connector, or a CSV or Excel export
Promotion calendar from marketing; attributes of new launches
Forecast versions from sales and marketing for consensus
Supplier lead time, MOQ, lot size, open orders and on-hand stock per SKU from procurement
Unit cost, price, payment terms and carrying-cost rate from finance

IntelligencePREDICT

Rule and statistical checks for duplicate SKUs, unit mix, outliers, sudden zeros and date gaps
SeasonalNaive, AutoETS and AutoARIMA compared per SKU on back-test error; Croston and IMAPA for sparse sellers
India and Singapore festival calendars; festival uplift matched to your own history, with its source recorded
Promotion uplift from past promotions; analogue forecasts for new SKUs
Safety stock, reorder point, MOQ-rounded purchase recommendations, stock-out dates and a weekly cash projection

DecisionsDECIDE

Which data fixes to apply (planner)
Whether to keep or override a forecast period, with a mandatory reason
How much festival cover to buy, compared as what-if scenarios, with the weekly cash alongside
Consensus weights across statistical, sales and marketing versions
Which purchase recommendations go to the buyer (supply planner; finance above an agreed value)

ExecutionEXECUTE

Agreed forecast, scenarios and purchase recommendations exported to Excel or CSV for the buyer
Reorder, festival and slow-mover alerts in the app, by email or on WhatsApp
Cash projection and working capital at risk for finance
ERP write-back, where configured, only after a named approver signs

FeedbackLEARN

Actuals recorded against every plan version and override
Error (MAPE), bias and fill rate per SKU and per contributor
Override history: original number, new number, reason, person, time and outcome
Similar past decisions recalled, with their outcomes, at the next override

Modules

Capabilities, organized by the work they do

29 modules in 5 groups. Open a module for its inputs, outputs, users and an example.

Demand review6 modules Commercial review6 modules Supply review7 modules Financial review4 modules Decision memory and governance6 modules

Demand review

Get the data in, clean it, and forecast every SKU with a likely range and the working shown. Run by demand planning, with sales and marketing reviewing the numbers.

Data ingestion and connectorsBrings sales history in from a CSV or Excel file, or through a connector to your ERP, and works out which columns hold the date, SKU, quantity and location.

Challenge: Every ERP and accounting package exports sales differently, and a planning tool that needs an integration project first waits weeks for its first forecast.
Inputs: A sales export (CSV or XLSX), or sales orders, invoices, inventory and supplier records from Tally, Xero, SAP Business One or NetSuite.
Outputs: Sales history rows ready for cleaning, with dates, SKUs, quantities and locations recognized.
Used by: Demand planner; IT or finance for the first connection.
Value: Planning starts from the files you already produce and moves to a direct connection without changing how the planner works.
Works with: Connectors are configured per deployment: Tally, Xero, SAP Business One and NetSuite, plus a REST API for other systems.
In action · illustrative: A 104-week export with columns named "Inv Dt", "Item Code" and "Qty (Cs)" is mapped without a template. The next month the same history arrives through the SAP Business One connector instead.

Data cleaning with planner-approved fixesFinds data problems before they distort the forecast, gives the history one data-quality score, and lets the planner choose which fixes to apply.

Challenge: Duplicate SKU spellings, a range booked in boxes and in cases, negative or impossible quantities, one-off bulk orders and missing weeks quietly ruin forecasts.
Inputs: Ingested sales history.
Outputs: A cleaning report and data-quality score, then the selected fixes (merge, convert units, replace, interpolate, delete) applied and logged in an audit trail.
Used by: Demand planner.
Value: The forecast starts from history the planner has checked, and every fix can be traced back.
Works with: Rule-based and statistical detectors for exact and fuzzy duplicates, mixed units, negative and extreme values, sudden zeros and date gaps.
In action · illustrative: "Sandal Agarbatti 100s" and "Sandal Agarbati 100 Stk" are flagged as one SKU and merged; a range booked in dozens and in pieces is converted to one unit; a one-off institutional order is flagged and the planner keeps it as sold.

Product families and SKU mappingMaps product codes across systems, follows renamed and discontinued codes, and groups SKU variants into families so their history counts together.

Challenge: New pack sizes, design iterations and code changes split history across many codes, so each one looks too new to forecast.
Inputs: SKU names and codes from each source system.
Outputs: A SKU map and a family map with the planner's corrections, and a family-level forecast.
Used by: Demand planner, master-data owner.
Value: More history behind each forecast and fewer orphan SKUs.
Works with: Name-matching rules are tuned to your SKU naming during onboarding; the planner reviews and corrects every grouping.
In action · illustrative: Three pack iterations of the same 500 g product, one of them renamed after a relaunch, are grouped so two years of history sits behind the current code.

Statistical forecast with P10–P90 rangeForecasts every SKU by day, week or month with a P50 and a P10–P90 range, from the model that fits that SKU best.

Challenge: A single number hides risk. Before committing stock, planners need to know how wide the plausible range is.
Inputs: Cleaned sales history; a horizon of 1 to 365 periods.
Outputs: P10, P50 and P90 per period, the model used and its back-test error, with trend, season and holiday effects shown separately.
Used by: Demand planner, planning head.
Value: Buys are sized against a range instead of one number, and the choice of model is visible.
Works with: SeasonalNaive, AutoETS and AutoARIMA from the statsforecast library, compared per SKU on back-test error. One forecast per SKU across locations.
In action · illustrative: For a fast-moving agarbatti pack, AutoETS beats AutoARIMA and SeasonalNaive on back-test error and is chosen; for a seasonal gift box, a different model wins.

Forecast explanationShows how each forecast was built: baseline plus trend plus season plus events equals the total, followed by every human adjustment.

Challenge: Planners override numbers they cannot explain "just in case", and later nobody can tell which changes helped.
Inputs: A forecast and its adjustment history.
Outputs: A step-by-step trace and a 0–100 confidence flag; SKUs below 70 are marked for review.
Used by: Demand planner; sales and marketing reviewers.
Value: Reviews go to the SKUs that need attention, and every number can be defended in the planning meeting.
Works with: The confidence flag is a rule of thumb from back-test error, horizon and range width. It points reviewers at SKUs and never changes the forecast.
In action · illustrative: The Diwali week reads: baseline 760, trend +35, season +25, festival ×2.5 from the calendar default. Confidence 68, flagged for review.

Sparse and erratic SKUsClassifies each SKU as smooth, erratic, intermittent or lumpy, and uses Croston and IMAPA methods for sparse sellers.

Challenge: Standard models forecast small, steady demand for slow and lumpy SKUs, demand that never actually arrives.
Inputs: Up to 104 weeks of weekly history, with outliers capped at the 95th percentile.
Outputs: Weekly forecasts for the whole range in one batch run, with each SKU's demand class.
Used by: Demand planner, planning operations.
Value: Fewer false reorder signals on the long tail of the range.
Works with: Runs as a weekly batch across the full range.
In action · illustrative: A SKU selling 0, 0, 40, 0, 0, 35 is routed to an intermittent-demand method instead of a seasonal one.

Commercial review

Bring what sales and marketing know into the plan: festivals, promotions, launches and their own numbers, each kept separate and traceable, then agree one number.

Festival and promotion calendarsTags sales history and forecast periods with Indian and Singapore festivals, including regional ones, and with your own promotion calendar.

Challenge: Diwali, Eid, Onam and Chinese New Year move every year, so last year's week numbers are wrong this year.
Inputs: Country, state and year; your promotion calendar.
Outputs: Festival and promotion tags on history and forecast periods, by SKU.
Used by: Demand planner, marketing.
Value: Festival and promotion weeks line up correctly every year without manual calendar work.
Works with: Built-in calendars; an external holiday service can be added per deployment.
In action · illustrative: 26 Indian festivals mapped to states, with lunar and Hijri date conversion and Diwali dates through 2035; Singapore festivals such as Chinese New Year, Hari Raya, Deepavali and 11.11.

Festival upliftMatches each festival to your own sales around past festivals and lifts the forecast weeks by that factor, recording where the factor came from.

Challenge: A statistical model treats a festival as noise unless it is told the date and the likely size.
Inputs: Forecast, festival calendar, sales around past festivals.
Outputs: Adjusted P10, P50 and P90 for the affected weeks, with the factor and its source (your history or the calendar default).
Used by: Demand planner.
Value: Festival demand shows up in the plan weeks ahead instead of as a surprise.
Works with: Uses your own history where it holds enough festival days, otherwise the calendar default.
In action · illustrative: The two Diwali weeks are lifted 2.5× using the calendar default because the upload holds too little festival history; the planner can override any week with a reason.

Promotion upliftEstimates a planned promotion's uplift from how past promotions performed against baseline, and adjusts the forecast.

Challenge: Marketing plans schemes, but the forecast does not know about them until stock runs out.
Inputs: Promotion calendar (CSV) with dates, SKUs and mechanics.
Outputs: Uplift % per promotion and an adjusted forecast.
Used by: Marketing, demand planner.
Value: Schemes are planned into supply instead of being discovered by it.
Works with: —
In action · illustrative: A "buy 10, get 1" distributor scheme in July is sized from last year's two similar schemes and added to those weeks.

New-product forecastBuilds a launch curve for a new SKU with no history from similar past products, weighted by category, sub-category, brand, pack and price tier.

Challenge: A launch has no history, so the first buy is a guess.
Inputs: Attributes of the new SKU.
Outputs: A launch forecast and the analogue products it used.
Used by: Marketing, demand planner.
Value: The launch buy rests on named comparables that marketing can challenge.
Works with: —
In action · illustrative: A new 250 ml floor cleaner borrows its curve from the 500 ml variant and two similar fragrances in the same price tier.

What-if scenariosApplies a demand change or promotion uplift over a date range and compares scenarios side by side.

Challenge: Planning meetings argue over one number instead of comparing options.
Inputs: Base forecast; a % change or uplift; a date range.
Outputs: A scenario set with totals, exportable to CSV or XLSX.
Used by: Planning head, sales, finance.
Value: Trade-offs are visible before money is committed.
Works with: —
In action · illustrative: Diwali at 2.0×, 2.5× and 3.0× is compared before the season buy is sized.

Consensus forecastCollects forecast versions from sales, marketing and planning and combines them with agreed weights.

Challenge: Each department keeps its own number, and the monthly meeting ends without one plan.
Inputs: Contributor versions and their weights.
Outputs: A consensus forecast; actuals are later recorded against each version.
Used by: Sales, marketing, demand planner, planning head.
Value: One agreed number, with each contributor's view preserved for the accuracy review.
Works with: —
In action · illustrative: Sales submits a higher Diwali number. With weights of 50% statistical, 30% sales and 20% marketing, the consensus lands between them, and every version is kept.

Supply review

Turn the agreed demand into what to order, from whom and by when, and catch stock-outs and slow movers early. Used by supply planning and procurement.

Reorder signal and safety stockCalculates safety stock, reorder point and a suggested order rounded up to MOQ and lot size, with a health status for each SKU.

Challenge: Reorder levels set once and never revisited cause stock-outs on growing SKUs and excess on declining ones.
Inputs: Demand and its forecast range, supplier lead time and its variability (plus holidays inside it), safety factor, MOQ, lot size and on-hand stock.
Outputs: Status (healthy, reorder, critical, stock-out), safety stock, reorder point and suggested quantity.
Used by: Supply planner, buyer.
Value: Every SKU gets a current reorder level, and safety stock grows where the forecast range or the supplier's lead time is wide.
Works with: On-hand stock comes from the ERP connection or is entered per SKU.
In action · illustrative: On-hand of 3,900 cases is below a reorder point of 6,343, so the SKU shows "reorder" with 2,500 cases suggested (MOQ 2,000, lots of 500).

Purchase recommendations and stock-out warningsTurns the reorder signal into an action: how much to order, from which supplier, by when, and how many days remain before a stock-out if no order is placed.

Challenge: Planning that stops at "demand is up" leaves the buyer to work out what to order, from whom and by when.
Inputs: Forecast range, reorder signal, supplier lead time and MOQ, open purchase orders and on-hand stock.
Outputs: A purchase recommendation per SKU and supplier, with an order-by date and a days-to-stock-out warning.
Used by: Buyer, supply planner.
Value: The buyer gets a decision to make, with its reasons, instead of a number to interpret.
Works with: Recommendations go to the buyer as an export, or to the ERP after approval where write-back is configured.
In action · illustrative: "Order 5,000 cases from the Hosur contract manufacturer by Friday. Without it, Sandal 100s runs out in 16 days." The buyer accepts, edits or rejects it, and the choice is logged.

Festival order-by datesWorks back from each festival to the date the order must be placed, given the supplier lead time, and grades the urgency.

Challenge: Teams see the festival coming but miss that the order deadline falls weeks earlier.
Inputs: Festival-adjusted forecast and supplier lead time.
Outputs: An order-by date and a grade: on time, order now, late or critical.
Used by: Buyer, supply planner.
Value: The order deadline is visible while there is still time to act on it.
Works with: Uses the festival-adjusted forecast and each supplier's lead time.
In action · illustrative: "ORDER NOW: Diwali (2.5× demand) is 6 weeks away. Order by 29 Sep (5 days remaining)."

Slow-moving stock alertsFlags SKUs whose stock is running well ahead of forecast demand, before the stock becomes a write-off.

Challenge: Dead stock is usually found at the year-end review, when the only option left is a write-off.
Inputs: On-hand stock, forecast demand, last sale date and unit cost.
Outputs: A list of slow movers with weeks of cover, value at cost and a suggested action: stop further orders, transfer or run a scheme.
Used by: Supply planner, sales head, finance.
Value: Excess is seen while there is still time to stop ordering or sell it through.
Works with: Uses the same forecast and on-hand data as the reorder signal.
In action · illustrative: A Diwali gift box still holds 14 weeks of cover in December. It is flagged, its open reorder is stopped, and sales gets the list for a January scheme.

Exception alerts and digestsSends stock-out risks, slow movers, festival order-by dates and threshold breaches to the person who owns them, in the app, by email or on WhatsApp, with daily and weekly digests.

Challenge: Exceptions get lost in reports nobody opens until something has already gone wrong.
Inputs: Threshold settings per alert type, an owner per SKU group, and each owner's channel.
Outputs: Alerts, a daily digest, a weekly summary and an alert history.
Used by: Planner, buyer, planning head.
Value: Each exception reaches its owner while there is still time to act.
Works with: Email and WhatsApp delivery are configured per deployment.
In action · illustrative: Each morning the buyer gets one WhatsApp message listing the SKUs in "reorder" or "critical" status for their suppliers, with the order-by date for each.

Export and hand-offExports forecasts, scenarios and purchase recommendations, with their overrides, to Excel or CSV for buyers and other systems.

Challenge: A plan that cannot leave the planning tool does not get executed.
Inputs: Forecasts, filters, scenario sets, purchase recommendations.
Outputs: CSV and XLSX files.
Used by: Buyer, planner, finance.
Value: The plan reaches the people who execute it, in the format they already use.
Works with: Your ERP stays the system of record; where write-back is configured, it runs only after approval.
In action · illustrative: The buyer receives the agreed festival forecast as a spreadsheet and raises the purchase order in Tally.

Production schedule link (OpsNest)Reads SKUs, the master production schedule and purchase history from OpsNest when the two are deployed together.

Challenge: Demand and supply plans drift apart when they live in separate systems.
Inputs: OpsNest SKU master, master production schedule, purchase-order history.
Outputs: Local read-only copies used for planning.
Used by: Supply planner, plant planning.
Value: One view of demand against planned supply for plants that also run OpsNest.
Works with: Read-only, when PlanningNest and OpsNest are deployed together.
In action · illustrative: The planner checks the festival forecast against the production weeks already scheduled in OpsNest.

Financial review

Translate the plan into money before it is committed: cash out, cash in, cash blocked in excess and revenue at risk. Used by finance, the planning head and the owner.

Weekly cash projectionProjects purchase outflows against sales inflows week by week from the forecast, unit costs and payment terms.

Challenge: A festival buy is a cash decision, but finance often sees it only when the supplier invoice arrives.
Inputs: Forecast, unit cost and price, supplier and customer payment days.
Outputs: Weekly cash out, cash in and net position.
Used by: Finance head, planning head.
Value: Finance can plan the working-capital line before the buy is placed.
Works with: Unit costs and payment terms come from finance.
In action · illustrative: A ₹78 lakh season buy on 30-day supplier terms is set against festival collections arriving on 45-day distributor terms, showing the weeks finance needs to fund.

Working capital at riskPuts the plan in currency: the carrying cost of current stock, overstock as blocked cash, revenue at risk from likely stock-outs, and what this week's and this month's purchases will cost.

Challenge: Planning decisions are rarely translated into money, so the CFO's question about where the cash went is answered only at month-end.
Inputs: On-hand stock and unit cost by SKU and location, forecast range, purchase recommendations, selling price, carrying-cost rate.
Outputs: Carrying cost, blocked cash and revenue at risk by SKU, and purchase outflow by week and month.
Used by: Finance head, CFO, planning head.
Value: Working-capital calls are made with the planners, while stock can still be moved and orders changed.
Works with: Carrying-cost rates are set by finance.
In action · illustrative: Before the festival buy, finance sees ₹22 lakh blocked in overstocked gift packs, ₹9 lakh of revenue at risk on three fast movers heading for a stock-out, and ₹78 lakh of purchases due in October.

Service level against costShows what each level of service costs in safety stock and cash, so the business chooses the service level it can afford for each SKU class.

Challenge: Service targets are set as one number for the whole range, so slow items get the same buffer as the fast movers that matter.
Inputs: Forecast range, lead-time variability, unit cost, carrying-cost rate and SKU class.
Outputs: Service level against inventory cash for each SKU class, and the chosen target per class.
Used by: Planning head, finance head, sales head.
Value: The service target becomes a business decision with a visible price.
Works with: Uses the reorder signal and the forecast range.
In action · illustrative: Moving A-class SKUs from 95% to 98% service needs ₹14 lakh more safety stock; C-class SKUs drop to 90% to fund it.

Executive viewA one-screen mobile view for the owner and CFO: revenue at risk, blocked cash, purchases due and the top decisions waiting for them.

Challenge: Owners and CFOs sign the big buys but rarely open planning screens.
Inputs: Plan, cash and working-capital figures; pending approvals.
Outputs: A phone summary with links to the decisions waiting for sign-off.
Used by: Owner, managing director, CFO.
Value: The people who sign the largest decisions see them in time, with the evidence.
Works with: Reads the same plan and cash figures as the finance review.
In action · illustrative: On Monday morning the managing director sees three festival buys waiting, ₹1.1 crore in total, each with its order-by date and its effect on cash.

Decision memory and governance

Keep the judgment behind every number, recall it when it helps, measure who adds accuracy, and control who can change and approve what.

Decision log (override with reason)Lets a planner change any forecast period, but only with a reason, and keeps the original number, the new one, the person, the time and, once the period closes, the actual result.

Challenge: Overrides happen in spreadsheets with no trace, and when a senior planner leaves, the judgment behind years of numbers leaves too.
Inputs: Forecast period, new value and reason; actuals after the period closes.
Outputs: A decision-log entry with its outcome; the chart and adjustment history update.
Used by: Demand planner, planning head.
Value: The team's judgment stays with the company and can be reviewed against what happened.
Works with: —
In action · illustrative: Diwali week raised from 2,050 to 2,563 cases with the reason "distributor scheme confirmed; product keeps, cover the upper range". After the season, the actual of 2,410 cases is written beside it.

Similar-situation recallWhen a planner is about to change a number, surfaces the last times the team faced something similar, what they did, what happened, and a suggested adjustment.

Challenge: Last year's lesson sits in someone's head or a lost email, so the same mistake is made again.
Inputs: SKU, family, period, festival or promotion, and the text of the planned override.
Outputs: Similar past decisions with their reasons and outcomes, and a suggested adjustment the planner can accept or ignore.
Used by: Demand planner, planning head.
Value: A new planner inherits the team's context instead of starting from zero.
Works with: Searches your own decision log and outcomes only.
In action · illustrative: "Last Diwali you raised this family by 20%, and actual sales came in 18% above the statistical forecast. A similar adjustment is suggested." The planner accepts it and adds a reason.

Accuracy scorecardMeasures error (MAPE), bias and fill rate by SKU and by contributor, setting the statistical forecast against each human override and each department's version.

Challenge: Nobody tracks whether an override helped, so bad calls repeat and good judgment goes unrecognized.
Inputs: Actuals recorded against the statistical forecast, the overrides and the consensus versions.
Outputs: Error, bias and fill rate per SKU and per contributor, and a leaderboard.
Used by: Planning head, management.
Value: Consensus weights and override rights are set on evidence.
Works with: —
In action · illustrative: After Diwali, the sales version shows a steady upward bias, the statistical forecast under-called the peak, and the planner's overrides on gift packs reduced the error.

Planner copilotAnswers planning questions in plain language, with a step-by-step trace and the records it used, drawing on the forecast, supply, cash and decision log.

Challenge: Answering a planning question means digging across data, forecasts and past decisions by hand.
Inputs: A question such as "Why is SKU-442 up next month?"
Outputs: A written answer, its reasoning trace and the sources behind each figure.
Used by: Planning head, sales, finance.
Value: Faster, checkable answers in planning reviews.
Works with: Every number comes from the database or the forecast engine; a language model only writes the sentence.
In action · illustrative: Asked why SKU-442 is up next month, it shows the Diwali factor, a confirmed distributor scheme and last year's override on the same family, each with its source.

Maker-checker approvalsRoutes a season buy, a plan release or an ERP write-back to a second person to approve or reject; nobody can approve their own request.

Challenge: Large buys and plan changes need a second pair of eyes.
Inputs: A request, its value and its approver.
Outputs: Approved or rejected, with who and when.
Used by: Planning head, finance head.
Value: Clear accountability for the decisions that move the most cash.
Works with: Approval thresholds and approvers are set per workspace.
In action · illustrative: A season buy above ₹1 crore goes to the finance head before it is released to the buyer.

Workspaces and rolesSeparates teams into workspaces with admin, planner and viewer roles.

Challenge: Not everyone who reads the plan should be able to change it.
Inputs: Users and their roles per workspace.
Outputs: Access control on every request.
Used by: Admin.
Value: The right people change the right numbers.
Works with: —
In action · illustrative: Finance and sales reviewers get viewer access; planners and admins work in the plan.

Intelligence and automation

What the intelligence actually does

Five levels, from seeing what is happening to learning from it.

Visibility

Clean sales history by SKU with festival and promotion tags, current reorder status, days of stock, slow movers and the cash tied up in them.

Prediction

A P10–P50–P90 forecast per SKU from the best-fitting statistical model, with festival and promotion uplifts, analogue forecasts for launches, and the date each SKU runs out if no order is placed.

Decision

Purchase recommendations with order-by dates, MOQ-rounded quantities, side-by-side cover scenarios, the service level against its cost, and the weekly cash. The planner and the buyer choose.

Execution

Sends the agreed plan to the buyer as an export, or to the ERP after approval where write-back is configured, and pushes alerts and digests to each owner in the app, by email or on WhatsApp.

Learning

Actuals against every plan version and override; error, bias and fill rate per SKU and contributor; and similar past decisions recalled, with their outcomes, at the next override.

Runs automatically

Column detection on ingestion
Data-quality detection (fixes wait for the planner)
Model selection and forecasting for every SKU
Festival tagging and uplift, with the source recorded
Reorder status, order-by dates, slow-mover flags, alerts and digests

Always waits for a named person

Which data fixes are applied
Any change to a forecast number (reason required)
The season buy and each purchase recommendation released to the buyer
Consensus weights between contributors
Any write-back to your ERP

Business value

What it helps you work toward, and how we measure it

We agree the baseline with you in writing before a pilot starts. These are the outcomes we measure.

Fewer festival stock-outs

Order-by dates and a forecast range for every festival SKU, weeks before the peak.

Stock-out weeks on festival SKUs, season against season.

Cash matched to demand

Buys sized against a range and shown in cash before they are placed.

Days of cover by SKU class at season end, against a baseline agreed in writing.

A forecast people trust

Clean history, a visible model choice and an explanation for every number.

Forecast error (MAPE) and bias by SKU class and by contributor, and the share of forecasts overridden.

Judgment that stays

Every override kept with its reason, its author, the original number and the outcome.

Overrides with a recorded reason, as a share of all overrides.

A shorter planning cycle

One agreed plan from sales, marketing, supply and finance instead of separate spreadsheets.

Days from month-end data to an agreed plan.

Illustrative example

A SKU selling about 800 cases a week has a reorder level, built from average demand, that suggests 2,500 cases. With Diwali at the 2.5× calendar factor, the P50 for the two festival weeks and the week after is about 4,900 cases and the P90 about 6,200. Rounded to an MOQ of 2,000 in lots of 500, that is 5,000 or 6,500 cases, or ₹60 lakh against ₹78 lakh at ₹1,200 a case. PlanningNest puts that trade-off in front of the planner before the order-by date.

Enterprise readiness

Integration, control and deployment

ERP & system integration

Works with Tally, Xero, SAP Business One and NetSuite, with CSV and Excel files in and out, and through a REST API; connectors are configured per deployment. Read-only link to OpsNest when deployed together.

Data sources & connectivity

Sales history, promotions, supply settings and costs stay in your deployment (PostgreSQL). Every number comes from the database or the statistical engine, never from a language model.

Deployment & implementation

Container-based; runs as its own stack or alongside OpsNest, with infrastructure templates for AWS Mumbai and Singapore.

Configuration & business rules

Forecast horizon and frequency, safety factor, MOQ, lot size, lead times, festival calendar by country and state, promotion files, consensus weights, approval thresholds, alert thresholds and channels.

Roles, access & approvals

Workspaces with admin, planner and viewer roles, checked on every request.

Security, governance & audit

Signed tokens, one-time-code login and single sign-on through your identity provider. Each workspace's data is kept separate, and plan changes are written to an audit trail.

Human oversight & exceptions

Overrides require a reason and keep the original number; data fixes apply only when the planner selects them; season buys and ERP write-backs above a set value need a second approver.

Scale & ongoing optimization

Batch forecasting across the full SKU range, with one company per deployment.

Straight answers

Questions about PlanningNest

Something else? Ask a specialist.

Does PlanningNest replace our ERP's MRP?

No. Your ERP stays the system of record for stock, orders and production. PlanningNest sits above it: it forecasts demand, recommends purchases, shows the cash, and hands the agreed plan to your buyer, or to the ERP after approval. It does not explode bills of material or plan capacity.

How does the monthly planning cycle run in PlanningNest?

Demand planning cleans the data and publishes the statistical forecast. Sales and marketing add promotions, launches and their own versions, and a weighted consensus is agreed. Supply planning and procurement turn it into purchase recommendations and order-by dates. Finance reviews the cash and the working capital at risk, and the planning head signs the plan. Every override keeps its reason, and its outcome is written beside it when actuals arrive.

How accurate is it?

We do not quote an accuracy figure, because accuracy depends on your data and has to be measured on it. During onboarding we back-test on your history, then track error (MAPE) and bias by SKU class and by contributor against a baseline you agree.

Which systems does it connect to?

Tally, Xero, SAP Business One and NetSuite, plus CSV and Excel exports from any other ERP or accounting system and a REST API. Connectors are configured per deployment. Your ERP stays the system of record, and nothing is written back to it without approval.

Is it machine learning or a language model?

Neither, for the numbers. Forecasts come from established statistical models (SeasonalNaive, AutoETS, AutoARIMA, and Croston-type methods for sparse SKUs) chosen per SKU by back-test error. Cleaning, festival uplift, reorder and cash are transparent rules and formulas. A language model only writes the wording of answers in the planner copilot.

Next step

Discuss your demand planning challenge

A festival buy is a cash decision made weeks before the festival. It deserves a range, a date and a written reason, and a record of how it turned out.

Talk to a specialist

Mid-size manufacturers and distributors in India and Singapore with festival or season-driven demand, a few hundred to a few thousand SKUs, and planning done in Excel today.

In the same loop