Restaurant forecast drivers in India: when weather, festivals and events should change the plan

Start with core demand before adding forecast drivers.

Restaurant demand in India rarely moves for one reason.

A Friday can be busy because it is a Friday. It can be busier because salaries were credited, a long weekend is beginning, a cricket match starts at 7:30 p.m., a delivery platform is running a promotion, or a large office nearby has an event. Heavy rain may reduce walk-in traffic at one outlet while shifting more orders to delivery at another.

The natural response is to keep adding more signals to the forecast. Weather. Festivals. Events. Promotions. Search trends. Traffic. Delivery demand. Social media.

That can create a worse forecast if the signals are added without discipline.

The useful question is not, “What data can we add?”

It is: “What information was known before the restaurant had to make the decision, and has that information changed demand for this outlet before?”

That distinction matters more than the number of variables in the model.

India’s food-service market is also becoming more varied by channel, cuisine, occasion and time of day. Swiggy and Kearney’s How India Eats 2025 report described faster growth in late-night meals, more experimentation across cuisines and restaurants, and strong growth in dining-out pre-booking. These are useful signs that demand patterns are evolving. They are not, however, universal multipliers that every restaurant should apply to tomorrow’s forecast.

A restaurant should first understand the demand that is already visible in its own history.

For a daily forecast, that may include:

• day of week
• recent sales and order trend
• recurring seasonality
• outlet
• menu-item mix
• channel mix, when consistently recorded
• known opening hours and closures

Think of this as core demand.

If a Jubilee Hills outlet usually handles more orders on Saturday than Tuesday, the forecast should learn that pattern before anyone adds an “event uplift.” If biryani consistently sells better on weekend evenings, that behaviour should not need to be rediscovered through an external signal every week.

Forecast drivers are different. They describe something known about the future that may cause the upcoming period to behave differently from the historical baseline.

A useful driver should pass four tests:

If a signal fails these tests, it may still be useful context. It should not automatically become a model adjustment.

Festivals should not become one generic “holiday uplift.”

India does not have one festival effect.

Diwali, Eid, Christmas, Onam, Durga Puja, Ganesh Chaturthi, Navratri and regional celebrations create different behaviours across cities, cuisines and restaurant formats. Even the same festival can behave differently for dine-in, delivery, desserts, gifting, vegetarian menus and late-night ordering.

The forecasting mistake is to create one rule such as:

The number looks precise, but it ignores the questions that matter.

Was the restaurant open for normal hours? Did the festival fall on a weekday or weekend? Was the comparable historical period before or after payday? Was there a promotion? Did guests dine out, order in or travel? Did the menu change? Was a fasting period relevant to the restaurant’s cuisine? Did the outlet have enough capacity to serve the demand that appeared?

A stronger method is to compare genuinely similar periods and keep the event label specific.

Instead of “holiday,” record the event name, date, city, outlet, service period and any known operating change. Over time, the restaurant can learn whether the event repeatedly changes total orders, channel mix or item mix.

If there is not enough history, do not invent an uplift. Keep the baseline, widen the uncertainty if appropriate, and allow an operator override with a reason.

Weather can change the shape of demand, not only the total.

Rain is a good example of why one external factor can create opposite effects.

A dine-in restaurant in a high-footfall area may see fewer walk-ins during heavy rain. A delivery-heavy outlet serving the same neighbourhood may see more at-home ordering. A mall outlet may behave differently again because customers are already indoors.

Current Indian restaurant-industry coverage has highlighted monsoon-related shifts in delivery demand. The important forecasting lesson is not to copy an industry percentage. It is to measure the restaurant’s own response by outlet and channel.

Weather also creates a timing problem.

If the kitchen finalises tomorrow’s preparation at 4 p.m. today, the valid input is the weather forecast available at 4 p.m. today. Using tomorrow’s observed rainfall after the day is over would make a historical backtest look smarter than the real operating forecast could ever have been.

That is data leakage.

The same principle applies to every external driver: backtesting must use the version of the information that would genuinely have been available at the time of the decision.

Local events need proximity, timing and audience.

A city can have a major event that is irrelevant to most restaurants in the city.

A concert five kilometres away may create no visible change for one outlet and a sharp dinner peak for another outlet beside the venue. A technology conference may affect weekday lunch demand near a business district. A stadium event may move delivery demand before the match and dine-in demand after it. A college festival may matter to a QSR and barely register for a fine-dining restaurant.

The event name alone is not enough.

At minimum, an event record should consider:

• location and distance from the outlet
• start and end time
• expected audience or attendance range
• event type
• transport or access impact
• historical response to comparable events
• whether the restaurant is running its own promotion around the event

The aim is not to build an encyclopedia of everything happening in the city. The aim is to identify events that could realistically change an operating decision.

A smaller, relevant event feed is often more useful than a large list of events that generates noise.

Delivery platforms are demand channels, not magic forecast drivers.

Online food delivery continues to grow in India. Swiggy reported 22.6% year over year growth in Food Delivery Gross Order Value for FY26, while its wider consumer research with Kearney described changing expectations around convenience, speed, affordability and food discovery.

That makes delivery important to forecasting, but “Swiggy is growing” does not mean one restaurant should increase tomorrow’s order forecast by 22.6%.

A restaurant needs its own channel history.

Useful delivery inputs may include:

• completed orders by platform
• cancellations
• outlet availability on the platform
• service-area changes
• platform promotions
• restaurant-funded discounts
• menu availability
• channel-specific price changes
• operating hours
• temporary outages

The first question is often whether delivery and dine-in should be forecast separately.

If they respond differently to rain, festivals, promotions or time of day, a combined total can hide the operating change. A kitchen may still prepare from one consolidated item plan, but understanding where the demand is coming from can improve timing, packaging and staffing decisions.

National platform trends are valuable market context. Outlet-level history should determine the restaurant forecast.

Known bookings usually deserve more weight than vague external signals.

Some future information is much stronger than a general trend.

A confirmed table booking for 40 guests, a corporate order, a catering commitment or a scheduled outlet closure is directly connected to the upcoming service period. It is known before service and can change the operating plan immediately.

That makes it different from a broad signal such as “this area may be busy.”

Swiggy and Kearney reported rapid growth in dining-out pre-booking in their 2025 India study. For operators, the forecasting implication is straightforward: as more demand becomes visible before service, reservation and pre-order data can become useful near-term inputs when they are available in time.

There is still a double-counting risk.

If a restaurant regularly receives similar Saturday bookings and the historical baseline already reflects them, adding the entire booking volume on top of the forecast can overstate demand. The system needs to understand whether the booking is ordinary, unusually large, or outside the pattern already captured in history.

Separate slow-moving demand changes from short-term forecast drivers.

Not every restaurant trend belongs in tomorrow’s forecast.

India is seeing changes in cuisine discovery, health-focused ordering, late-night consumption, delivery expectations and dining formats. Those changes matter, but many of them develop over months rather than appearing as a one-day event. Swiggy’s own 2026 data, for example, shows growing adoption of health-oriented ordering alongside wider changes in cuisine and daypart behaviour.

A slow change should usually enter through recent sales history, menu mix and model retraining.

A short-term driver should enter because something specific is known about the upcoming period.

This distinction keeps the forecast understandable:

Core demand captures recurring behaviour and recent structural change.

Forecast drivers adjust for known future conditions that are not fully represented in the baseline.

Intraday signals help after the day begins, when actual orders or service conditions start deviating from the plan.

Mixing all three into one unexplained number makes it difficult for an operator to know why the recommendation changed.

Worked example: tomorrow is not “Saturday plus rain plus cricket.”

The synthetic Openfluid restaurant dataset produces a transparent same-weekday baseline of about 281 completed orders across three outlets for the next Saturday.

Now suppose the upcoming Saturday also has a major cricket match and a forecast of heavy evening rain.

A weak approach would apply two generic uplifts:

That assumes the two effects are independent, transferable and correctly measured. They may not be.

A stronger workflow asks:

• How did each outlet behave during comparable rainy Saturdays?
• Did dine-in fall while delivery increased?
• How did previous major match nights affect the same service window?
• Were those historical match nights also weekends?
• Were promotions or delivery discounts active?
• Did the kitchen hit capacity, causing observed sales to understate demand?
• Is the event information known before the preparation cutoff?

If the restaurant has enough comparable history, the drivers can be estimated and backtested.

If it does not, the forecast should remain honest: show the baseline, show the known conditions, expose the uncertainty, and allow a manager to adjust the plan with a recorded reason.

An override is not a failure of forecasting. An unexplained override that is never measured is.

The best driver is the one that improves the decision.

Adding a variable is easy. Proving it helps is harder.

Each driver should be tested against a simpler forecast using historical decision cutoffs. The comparison should answer more than whether average forecast error moved slightly.

Did the driver reduce meaningful under-forecasting during festival periods?

Did a weather input improve delivery forecasts without making dine-in forecasts worse?

Did event data improve the outlets close enough to the venue, or simply add noise everywhere?

Did the better forecast change preparation or purchasing in a useful way?

If a driver improves a statistical score but never changes an operating decision, it may not deserve the complexity it adds.

The objective is not the largest model.

It is the smallest set of reliable signals that helps the restaurant make a better decision before service.

What data is required?

A restaurant can begin with a relatively small set of controlled data.

The most important field may be the timestamp.

Without knowing when a signal became available, it is easy to train a model on information the real operator could not have known.

Practical rule: a driver must earn the right to change the forecast.

Weather, festivals, local events, delivery platforms and bookings can all matter to restaurant demand in India.

They should not be treated as automatic uplifts.

Start with the restaurant’s own core demand. Add a future driver only when it is known before the decision, relevant to the outlet, supported by comparable evidence and capable of changing an action. When evidence is weak, show the uncertainty instead of manufacturing precision.

A restaurant forecast becomes more trustworthy when the operator can answer two simple questions: