ATPL

AI · See and predict

See next month’s demand before it arrives.

For retailers, restaurants, distributors and manufacturers with years of sales in a database: forecasts for each item and outlet, so stock, staff and purchases follow demand instead of chasing it.

Forecast by gut

Ordering by guesswork every week

Forecasts of demand, stock and risk from the sales data you already hold.

Describe the problem
  1. Guess

    You over-order some items and run out of others, and the difference is cash sitting on the shelf.

  2. Waste

    Festival season planning is done from memory and last year’s spreadsheet.

  3. Late

    Reports tell you what sold last month; nobody tells you what will sell next month.

Per item, outlet, week

A forecast that beats the baseline

  • A baseline to beat

    The forecast is compared against the simple method you use today, and we show you the difference before you rely on it.

  • Drivers made visible

    Weekday, season, festival calendar, price changes and promotions are included as inputs so you can see what moved the number.

  • Reorder and roster suggestions

    The forecast turns into a suggested purchase list or staffing plan a manager approves, inside the sheet or system they already use.

  • Accuracy tracking

    Every week the forecast is scored against what actually sold, by item, so you know where to trust it and where not to.

Primary deliverable

Ships with the engagement

Live brief

01 · Lead outcome

A forecast per item, outlet and week

Demand predicted at the level you order and roster at, with a range rather than a single number, refreshed as new sales land.

  • 01A baseline to beat
  • 02Drivers made visible
  • 03Reorder and roster suggestions
  • 04Accuracy tracking

How it ships

History, then suggest

  1. fcst/01

    Understand

    We take two or more years of sales history from your POS or ERP and find out whether it is clean enough to forecast from; often the first job is fixing it.

  2. fcst/02

    Design

    We agree the level of the forecast, the horizon, the baseline to beat and the decision it will drive; the method is chosen last, and is often simple.

  3. fcst/03

    Build

    The model forecasts in the background for a full cycle while your team keeps ordering as before, and the two are compared.

  4. fcst/04

    Stay

    Forecast error is reviewed monthly, the festival calendar is updated each year, and new outlets or items are added as they appear.

History to signal

History becomes a suggestion

The brief is the baseline you already beat and the fields a planner can override — not a magic number.

What a client typed

We have twelve cafés and the kitchen manager at each one orders milk, bread and produce by feel, so some days we throw food away and on busy days we run out by evening, and all the sales are in the POS going back years.

Brief ready

What it becomes

Problem
Perishable ordering by feel causes both wastage and stock-outs.
Scale
Twelve outlets; daily ordering; several years of itemised POS sales.
Systems
The POS database, supplier order sheets, the festival and holiday calendar.
First step
A daily demand forecast for the ten highest-wastage items at two cafés, scored against actual sales for one month.

Your data

Forecasts are built from your own sales and stock data, inside your database or a cloud account you own. The model is trained only on your data and belongs to you. Nothing is sent to a third-party model provider unless you choose to add external inputs such as weather.

Forecast or report

Where it fits, where it doesn’t

  • Fits when
  • Businesses with two or more years of itemised sales, orders or usage data in a system.
  • Decisions made repeatedly: what to order, how many staff, how much to produce.
  • Teams prepared to compare the forecast with their own judgement for a full cycle.
  • Doesn’t fit when
  • New products, new outlets or new markets with no history; a forecast needs a past.
  • Rare, large events such as a one-off tender; statistics need repetition.
  • Data that lives in paper registers or in someone’s head; start with data engineering.

How we work

Ethos has held itemised sales for 125+ restaurants and cafés in one cloud database since 2014; forecasting from that kind of record is the method described here. ATPL will confirm which forecasting work may be named.

    Chosen for the job

    Python · Node.js · Next.js

    Decide the shape

    Before you start

    Plain answers on scope, data and what a first proof usually takes.

    Predictive analytics uses past sales, calendar and price data to forecast what each item will sell at each outlet in the coming days or weeks, so ordering, production and staffing can follow the forecast. ATPL builds these forecasts from the POS or ERP data a business already holds.

    Two years of itemised daily sales is a good starting point, because it covers every season and festival twice. ATPL can begin with less for fast-moving items, but states the lower confidence plainly, and the first weeks of any project usually go into cleaning the data.

    It varies by item: fast-selling staples forecast well, slow and seasonal items less so. ATPL does not quote an accuracy figure in advance; it runs the forecast against actual sales for a full cycle, reports the error per item, and compares it with the ordering method you use today.

    Yes. ATPL includes the Indian festival calendar, regional holidays and your own promotion dates as inputs, so Diwali, Navratri or Eid weeks are forecast from how they behaved in previous years rather than treated as surprises.