Queue wait time predictor

A queue wait time predictor earns a place on the duty desk only when every filled cell is a forecast of front-desk load for a 15-minute slice, and that cell cites two inputs: the arrival load that fed the model, and the staffing vintage of the roster used at prediction time. If either cite is missing, the cell is incomplete. It is not a wait time.

Quality is the outcome. You want a forecast the duty manager can defend, not a printed minute count. The model estimates how long the line is likely to be, in people, parties, or desk work, during peak arrival windows. It does not observe how long the guest now at the rope has already stood there. Do not print a measured minutes figure the model did not observe. Do not back-fill a wait by dividing queue length by a service rate you did not time this hour.

A front-office manager still redeploys from a well-cited forecast. You open a second check-in terminal, pull a porter onto bag-drop, or hold a supervisor through the next two buckets because arrival pressure is rising against a thin vintage roster. You do not do it because a widget invented a minutes headline.

Arrival load must be namable: remaining check-ins in that interval, group movements the PMS actually holds, day-use or walk-in signals you record, not a vibe that the lobby "looks busy." Staffing vintage must be namable: which roster snapshot, as-of time, who is on desk versus cashier, concierge, bell, or break. Empty stays empty if arrivals are unknown. A blank cell is honest. A filled cell with no cite is the failure that trains the team to trust decoration.

Before anyone runs the predictor, load the arrival list for the peak windows you staff against, and load the roster that will actually stand at the desk in those windows.

Arrival load is not "busy Saturday." It is the set of reservations still due in each 15-minute bucket, plus known group movements, plus whatever walk-in or day-use signal the property records in a form the model can read. Incomplete files slow the desk even when headcount looks light. An agent reconstructing a missing ID, rate, or billing instruction is not a free server. Clean that file first; incomplete reservation flagging is the pre-arrival hygiene that keeps the arrival extract honest.

The roster is a vintage, not a hope. Pull who is scheduled on front office for each bucket, who is already assigned elsewhere, and who is on break. If the predictor reads yesterday's published roster after you have already moved two people onto a VIP arrival, the forecast is stale the moment it prints. Timestamp the roster you fed the model. That timestamp is the staffing vintage the cell must cite.

Property systems in this class (Oracle Hospitality, Mews, Cloudbeds, Canary, and the same family of PMS, CRS, and guest-journey tools) already hold arrivals and often hold labor or task assignments. Use them as sources of record for load and roster. Do not treat a vendor screen as a measured wait clock unless it is literally counting people with an observation method you trust. Most front-office products in this class know who is due and who is rostered. They do not automatically know how many minutes the current party has waited.

If the arrival extract is empty, delayed, or clearly partial (a group block with no pickup names, a coach due with no rooming list, a PMS window where tomorrow's arrivals have not posted), stop. Do not substitute last week's shape, a seasonal pattern, or a manager's gut so the grid looks complete. That is inventing the input. The next rule, leaving blanks, exists for this case.

Run the model on the peak arrival windows you actually staff against: typically late morning through early evening check-in, plus any known cluster such as crew, tour, wedding, or conference load-in. Forecast queue length, or remaining desk work, for each 15-minute interval. Carry the arrival cite and the staffing vintage into every cell.

Pick one definition of queue and keep it. Queue length here means expected people or parties waiting or in process at the desk, or expected remaining check-in work against the agents in the vintage. Mixing "parties waiting" with "minutes of wait" in the same grid is how a forecast gets misread as a stopwatch.

Walk one afternoon the way a duty manager would, without turning it into a scored case. A coach is due after 15:00. The remaining in-house list still shows a cluster of leisure arrivals across 15:00-16:00. The vintage roster for 15:00-15:30 is the duty manager plus one agent because the third agent is on a late break. Given that arrival file and that roster snapshot, the predictor should fill 15:00-15:15 and 15:15-15:30 with a heavier expected queue than the 14:30-14:45 cell that had a fuller desk and a thinner remaining list. The cells cite the coach, the remaining FIT arrivals, and the roster vintage taken just before the window. They do not print how long anyone has already waited, because nobody timed the line.

Self-check-in changes the work mix, not the need for a cite. If kiosks or a frictionless self-check-in agent absorb eligible arrivals, the load you feed the desk predictor should be desk-bound load, not the raw in-house list. Feeding every remaining reservation while a share of parties can bypass the rope overstates the queue and sends you to overstaff the desk while the lobby kiosks sit idle.

Housekeeping readiness is arrival friction, not a wait measurement. Rooms not released hold guests at the desk in conversation. Coordinate the queue forecast with the housekeeping schedule optimizer so you know whether the 15:00 cluster is likely to be key-ready or still waiting on rooms. That changes redeployment (a runner to the floors versus an extra checker at the desk). It still does not authorize a made-up minute figure.

Outbound pressure belongs in the same lobby picture. A pile-up of late check-outs can steal agents for billing and clog the same rope. A departure time optimizer is a sibling control. It is not a substitute for arrival cites on this grid.

If the arrival extract for a bucket is unknown, the forecast cell stays empty. Unknown includes no remaining check-in list for that interval, a group with no names or pickup count, a system outage, a night-audit window where the next day's arrivals have not posted, or a walk-in stream you do not record in a form the model can read.

Empty is a quality outcome. Filling the hole is the failure.

Three failure modes show up on the same grid.

A forecast with no arrival cite. The cell shows a number, maybe even a color, but you cannot point to which arrivals and which roster vintage produced it. Do not redeploy from that cell. Demand the cite or clear the cell. Dashboards that "just show a wait" without naming inputs are decoration.

Treating the number as measured wait. A predicted queue of parties is not a statement that guests have already waited a given number of minutes. Do not read it onto a guest-facing display, into a complaint log, or into a service promise as if a sensor observed it. If you need measured wait, you need a separate observation: ticket timestamps, a queue count you trust, or agent start times. This predictor is not that instrument.

Inventing minutes. The common patch when a cell is blank, or when a manager wants a single headline, is to convert queue length to minutes with a rule of thumb (divide by agents, assume a service time). That invented minutes figure is not a model output and not an observation. Do not print it. Do not put it in the shift handover as fact. If you want a planning range for briefing, say it in words: a heavy 15:00 desk against two agents, not a false-precision clock.

When a bucket is blank, the front-office manager still acts. You do not freeze the lobby because the model refused to guess. You use visible lobby state, the raw remaining arrival list if a person can read it, and the roster in front of you. The predictor's job in that bucket is to stay quiet so it does not compete with those eyes.

Use filled, cited cells to move people before the rope grows, not to narrate how long it already is.