How to Use AI to Forecast Demand for a Small Business

Demand forecasting for a small business does not need a data science team, and it does not need two years of clean history. It needs about eight weeks of daily numbers, an honest list of the things that move your demand, and a model that you ask the right question. The right question is almost never "what will sales be next month". It is "how many units of this thing do I need on Thursday, and what happens if I am wrong in each direction".

Here is the approach that works with the data a small business actually has.

Start with the decision, not the forecast

A forecast that does not change a decision is a hobby. Before you touch a spreadsheet, write down the specific decision you are trying to make and the cost of getting it wrong in each direction.

A bakery over-ordering flour loses a little money. Under-ordering on a Saturday loses a lot, because the customers who wanted a loaf at 10am do not come back at 3pm. That asymmetry should shape the forecast, and it is the single most common thing small businesses get backwards. They forecast the average and then order the average, when the correct behaviour is to deliberately over-supply the cheap-to-be-wrong side.

Write it in one line: "If I over-prepare I lose X. If I under-prepare I lose Y." Keep it visible. Every step below refers back to it.

Get eight weeks of daily data into one place

Not monthly. Daily, or per-shift if you run shifts. Monthly totals hide every pattern worth knowing, because the pattern in most small businesses is day-of-week and weather, not season.

Export from wherever the numbers live: your point-of-sale system, your booking software, your invoicing tool. What you want is a flat file with one row per day and these columns, at minimum:

The notes column is the one people skip and the one that carries most of the value. A model cannot infer that Tuesday was terrible because the road was closed. You can tell it.

Ask the model to find the pattern before you ask it to predict

This is the step that separates a useful forecast from a confident-sounding number. Paste your data and ask for the structure, not the prediction:

Here is 8 weeks of daily sales data from my cafe, one row per day,
with a notes column explaining unusual days.

Do not forecast anything yet. Tell me:
1. The average for each day of the week, and the spread (min, max)
   for each day.
2. Which days in this data are outliers, and whether the notes
   explain them.
3. Any trend across the 8 weeks, and whether it is large enough
   to matter given the day-to-day variation.
4. What information is missing that would materially improve
   a forecast.

Question 4 is the one that earns its place. Most small business data has an obvious missing variable, and the model will name it: weather, local events, a competitor's opening hours, payday timing. You then go and get that column, and your forecast improves more from adding it than from any modelling cleverness.

Question 1 matters because the spread is the forecast. If your Saturdays range from 180 to 260 covers, a point forecast of 220 is nearly useless. The range is what you order against.

Then ask for a range, and force a bad case

Only now ask for numbers, and never ask for a single number.

Now forecast next week, Monday to Sunday. For each day give me:
- a low estimate (roughly the 20th percentile of what you would expect)
- a central estimate
- a high estimate (roughly the 80th percentile)

Then, in one sentence per day, state the main reason that day
could come in below the low estimate.

Known factors for next week: [local festival Saturday, forecast
rain Tuesday and Wednesday, bank holiday Monday].

The bad-case sentence is doing real work. It surfaces the assumptions the model is quietly making, and roughly a third of the time it will name something you had not accounted for.

Feed the known factors in explicitly. The model does not know about your local festival, and it will not ask.

Turn the range into an order, using your asymmetry

Now go back to the line you wrote at the start.

Cheap to over-prepare, expensive to under-prepare: order to the high estimate. That is a bakery on a Saturday, a restaurant on a known busy night, a service business scheduling staff for a period where turning work away means losing the customer permanently.

Expensive to over-prepare, cheap to under-prepare: order to the low estimate. That is anything perishable with thin margins, or anything where a customer will happily wait two days.

Genuinely symmetric: order to the central estimate. This is rarer than people think. Check before assuming it.

Check it against reality every week for six weeks

Keep a two-column log: forecast and actual. After six weeks you will know something concrete, which is whether the forecast is biased and in which direction. Almost all early forecasts are biased, usually optimistic, because the notes column under-records bad days.

If you are consistently high by roughly the same percentage, correct for it and move on. That is a better use of an hour than rebuilding the model.

The log is also what tells you when to stop. If the forecast is no better than "same as this day last week", use "same as this day last week" and get your afternoon back. That is a real and common outcome, particularly for very stable businesses, and knowing it is worth the six weeks.

Where this fits with everything else

Forecasting demand is one of the few AI use cases in a small business where the value is measurable in the first month, because the decision it changes has a price tag attached. If you are working out which processes to point AI at first, the same logic applies more broadly and we set it out in which tasks to automate with AI first. If you want to put a number on whether it paid off, measuring AI ROI for a small business covers the arithmetic, and signs your business is ready for AI automation is the honest pre-check.

One caution worth stating plainly. A language model is not a statistical forecasting engine, and it will produce a confident answer whether or not your data supports one. That is exactly why the workflow above asks for a range, asks for the bad case, and validates against actuals for six weeks. Treat the output as a structured opinion from someone who has seen your numbers, not as a calculation.

FAQ

How much data do I actually need?

Eight weeks of daily data is enough to see day-of-week structure, which is where most of the signal lives in a small business. A year lets you see seasonality. Do not wait for a year to start.

Can I do this without sharing my sales data with an AI provider?

You can, and for some businesses you should. Aggregate to daily totals with no customer information, which is usually enough. If that is still too much, running a model locally removes the question entirely, at the cost of setup effort.

Should I use a spreadsheet formula instead?

Often, yes. A four-week moving average by day of week is a genuinely strong baseline and takes ten minutes. Use the AI workflow when you have several interacting factors, such as weather and events and promotions, that a simple average cannot separate.

What if my business is too new to have history?

Then you are not forecasting, you are estimating, and you should say so. Use comparable businesses, supplier guidance and small orders, and start the daily log on day one so that in eight weeks you have something real.