Every organizer over-orders catering and under-books the popular room, because the only number they have is registrations and the only number that matters is arrivals. The gap between the two is knowable — it is written into the history of every event a team has already run — but nobody has the time to derive it from a spreadsheet the week of the show.
The signal for this already exists in the platform, which is what makes it the next honest step rather than a wish. Registrations are recorded per ticket type with their status; attendees are distinct records linked to those registrations; check-in records capture every scan with a direction and a timestamp; and the platform already computes hourly check-in throughput for an event by truncating those scan timestamps into hour buckets, charted on the analytics page today. That is the arrival curve. Sessions carry capacity and a room, and the agenda carries the time windows. Everything a forecast needs to be trained and evaluated on is being collected now.
The intended experience is decision-shaped, not dashboard-shaped. Before the event, a forecast of expected arrivals against registrations, so rooms, catering and door staff are sized to the number that will show up. Per session, a predicted no-show rate and a popularity estimate, so an oversubscribed track can be moved or repeated while there is still time. On the day, the live arrival curve compared against the forecast, so a slow first hour is either normal or a signal to open more lanes.
Where predictions would land is also already modelled: analytics snapshots are point-in-time records with a metrics payload, created and listed from the analytics page today, which is the natural home for a stored forecast so that a prediction can be compared against what actually happened. Evaluating forecasts against outcomes is the difference between a decision engine and a plausible-sounding number, and that comparison needs the snapshot history the platform is accumulating.
None of the forecasting itself exists. There is no forecasting resolver, no no-show model, no capacity recommendation, and — deliberately — no interface that implies otherwise. This capability is blocked behind the shared platform AI runtime, and it is described here as committed direction so that the roadmap and the product are never confused for each other.
Roadmap scenario, stated honestly: the inputs and the write target exist; the forecasting engine does not.
Ready to make this your story?
