Travel & Hospitality
Restaurant Demand Forecasting API
A restaurant's two largest controllable costs are labour and waste, and both are set days before anyone knows how busy it will be.
- Reservation platforms
- Restaurant groups
- Hospitality POS vendors
- Hotel food and beverage teams
- Staff scheduling software
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
The manager writes the rota on Wednesday for the following week and orders fresh produce on Thursday. Both decisions rest on an estimate of covers that is usually last week's numbers adjusted by a feeling about the weather. When the estimate is high, there are too many staff on and food goes in the bin. When it is low, service degrades and the kitchen is in trouble by eight o'clock.
Reservation data only tells part of the story. In a typical restaurant a large share of covers walk in, and the booked-to-walk-in ratio varies by day, service and season. So a booking book that looks thin on a Tuesday might still produce a full room, and a Saturday that looks full will lose a predictable fraction to no-shows and late cancellations.
No-shows are their own problem and a more tractable one than they look. The signals are mundane — how the booking was made, how far ahead, party size, whether the guest has a history, whether they confirmed, time of day, weather on the night. A per-booking likelihood lets a restaurant overbook deliberately and in proportion rather than either refusing to overbook at all or guessing at a flat percentage.
Who buys this
Reservation platforms, Restaurant groups, Hospitality POS vendors, Hotel food and beverage teams, Staff scheduling software
What the API returns
What comes back
- Expected covers by date, service and hourly slot with confidence intervals
- Walk-in component estimated separately from booked covers
- Per-booking cancellation and no-show likelihood with the contributing factors
- Busy-period prediction at a resolution useful for shift planning
- Recommended overbooking allowance per service with the risk stated
- Expected party-size mix, which drives table plan and prep more than headcount does
- Demand drivers attached to each forecast: weather, local events, holidays, day of week
- Variance flags where a service is forecast with unusually low confidence
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/venues/{id}/forecast | Expected covers by date, service and hour |
| GET | /v1/venues/{id}/services/{service_id} | Detail for one service including party mix |
| POST | /v1/bookings/score | Cancellation and no-show likelihood for bookings |
| GET | /v1/venues/{id}/overbooking | Recommended overbooking allowance per service |
| GET | /v1/venues/{id}/drivers | Demand drivers affecting upcoming services |
| POST | /v1/venues/{id}/actuals | Post actual covers back for continuous calibration |
Request and response
illustrativeRequest
{
"venue_id": "ven_2207",
"dates": { "from": "2026-10-27", "to": "2026-11-02" },
"services": ["lunch", "dinner"],
"resolution": "hourly",
"include": ["walk_ins", "party_mix", "drivers"]
}Response
{
"venue_id": "ven_2207",
"generated_at": "2026-10-22T05:00:00Z",
"services": [
{
"date": "2026-10-31",
"service": "dinner",
"booked_covers": 112,
"expected_covers": { "p50": 164, "p20": 141, "p80": 188 },
"expected_walk_ins": { "p50": 68, "p80": 86 },
"expected_no_show_covers": 16,
"by_hour": [
{ "hour": "18:00", "p50": 22 },
{ "hour": "19:00", "p50": 46 },
{ "hour": "20:00", "p50": 52 },
{ "hour": "21:00", "p50": 31 }
],
"party_mix": { "1-2": 0.44, "3-4": 0.38, "5-6": 0.13, "7+": 0.05 },
"drivers": [
{ "factor": "halloween_friday", "effect_covers": 24 },
{ "factor": "forecast_dry_mild", "effect_covers": 11 }
],
"overbooking": { "recommended_extra_covers": 12, "risk_of_turnaway": 0.08 },
"confidence": "medium"
}
]
}Where the data comes from
| Your reservation system | Bookings, modifications, cancellations and no-show outcomes — the outcome labels are what make no-show scoring possible |
| POS or till data | Actual covers and spend by hour, which is the ground truth the forecast is measured against |
| Weather forecasts and history | Short-range forecasts for prediction, historical observations for training — weather is the single largest external driver for most venues |
| Local event calendars | Fixtures, concerts and conferences near the venue, which can double or halve a service |
| School and public holiday calendars | Holiday patterns reshape both lunch and dinner demand, in different directions |
| Guest history where consent allows | Repeat-guest behaviour improves no-show scoring substantially, and is personal data that needs a lawful basis |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Separate models for booked covers and walk-ins, because the drivers and the lead times are genuinely different
- Quantile forecasts so a manager can staff to a confidence level rather than to an average that is wrong half the time
- Hourly profiles learned per venue and service, since arrival shape varies enormously between a bistro and a tasting-menu room
- No-show scoring trained on the venue's own labelled outcomes, with a pooled prior for venues that lack history
- Weather features engineered as deviations from the seasonal norm, which carries more signal than absolute temperature
- Event proximity features weighted by venue catchment rather than raw distance
- Calibration monitoring against posted actuals, with automatic retraining when a venue's pattern shifts — a menu change or a new neighbour moves it
- Explicit low-confidence flagging for new venues, unusual dates and the first weeks after a format change
What it changes for the business
Labour cost against real demand
Rotas are written to a forecast with a stated confidence rather than to last week's covers.
Less waste
Prep and ordering follow expected covers and party mix, which is where most food cost leaks.
Deliberate overbooking
An allowance sized to measured no-show risk recovers covers without the turn-away incidents that flat overbooking causes.
A retention feature for platforms
Reservation software that forecasts demand is harder for a venue to switch away from than one that only takes bookings.
How it fits into your product
How it embeds
- Pulls bookings and actuals from your reservation system and POS on a schedule
- Per-booking scoring inline at confirmation time, fast enough to sit in the booking flow
- Webhooks on forecast revisions and on bookings that cross a no-show risk threshold
- Multi-venue endpoints so a group or a platform can refresh an estate overnight
- Forecast and shift-planning components ready to embed, or raw JSON for your own screens
- Deployment inside your environment where guest data cannot leave
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 12 weeksDiscovery and data review
Weeks 1–2
We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.
Architecture and prototype
Weeks 3–4
You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.
Production build
Weeks 5–10
Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.
Integration and handover
Weeks 11–12
We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
How accurate can a cover forecast be?
For an established venue with a year of clean POS data, typical dinner-service error lands in the low teens as a percentage of covers, and the interval is honest about that. New venues, festival weekends and the week either side of a format change are considerably worse, and the API flags them as low confidence rather than quietly returning a tight interval.
Should we use no-show scores to charge deposits?
That is your commercial decision, but be careful. A score is a probability, not a verdict, and a guest with no history will often look risky simply because there is nothing known about them. If you gate deposits on the score, we would advise a threshold set well above the base rate and a policy that does not penalise first-time guests for being new.
Does it use guest personal data?
Only if you have a lawful basis for it and choose to supply it. Guest history improves no-show scoring noticeably, and it is personal data. The forecast itself — covers, walk-ins, hourly shape — works entirely on aggregate booking and POS data with no individual-level input.
Will it predict a one-off event we have never had?
No. A model trained on your history has no basis for a street festival that has never happened outside your door. You can enter known one-offs as events and the forecast will widen rather than pretend to know the effect, and after one or two instances the effect becomes learnable.
We have multiple venues with very different formats. One model?
No — per-venue models with shared structure and pooled priors. A single model across a mixed estate fits the average venue and serves none of them well. Pooling helps new or low-volume venues borrow strength without flattening the ones that have plenty of data.
Related blueprints
Hotel Revenue Optimisation API
Occupancy forecasts, recommended rates and demand signals per property and date, as the pricing engine inside hospitality software.
Travel Review Intelligence API
Topic-level sentiment, service issue detection and satisfaction movement from guest reviews, as an analytics layer for hospitality and travel software.
Hotel Price Intelligence API
Comparative hotel rates, availability movement and rate-change alerts, delivered as a data layer inside your booking or revenue product.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.