Build a Registration Desk Staffing Model That Holds

Most registration queue disasters are not staffing shortages in the aggregate. They're staffing mismatches in the hour. You had enough people across the day — you just had three of them on lunch when 400 delegates arrived for the 10am keynote.

Fixing that is not about hiring more staff. It's about building a model that tells you where the demand actually lands.

Why the old approaches keep failing

The typical approach to registration staffing goes like this: take total expected attendance, divide by some ratio you half-remember from a previous show, round up slightly, and brief the temp agency. It produces a flat headcount — say, eight staff across a six-hour window — that ignores the fact that 60% of your badge traffic will arrive in 90 minutes.

The ratio approach has a second problem: it doesn't carry forward. Next year's ops manager inherits a number, not a method. They don't know whether that number was right, slightly wrong, or genuinely disastrous and papered over by an experienced team. The institutional knowledge lives in someone's head and leaves with them.

A staffing model does something different. It maps demand to hours, not just totals.

The four inputs your model needs

You don't need sophisticated software to build a first version. You need four things:

1. Hourly badge volumes from your last show. If your registration system produces scan logs with timestamps, export them and bin them into 30-minute windows. That shape — the curve of arrivals across the day — is your demand profile. It tells you when people actually turn up, not when the programme says they should.

If you don't have scan logs yet, your first show is a data-collection exercise as much as anything else. Set a team member to tally badge prints per 30-minute slot at each desk. It's low-tech but it gives you the curve.

2. Pre-registered vs walk-in split. Pre-registered delegates are faster to process — badge prints in under 20 seconds if your system is set up right. Walk-ins need data entry, payment (sometimes), and often a conversation. A show that's 80% pre-registered runs very differently to one that's 50% walk-in, even at the same total volume. Your model needs to weight these separately.

3. Session start times and their delegate draw. The single biggest peak driver is a plenary or keynote session with a hard start time. If 600 of your 900 delegates are expected at a 9am opening session, you have a hard constraint: you need enough desk throughput to clear 600 people before 8:55. Work backwards from that number and your per-desk throughput rate to get minimum staffing in that window — not as a guess, as a calculation.

4. Desk throughput rate. How many badges can one competent staff member print per hour? This varies by system, printer speed, network reliability, and whether staff are logging in and out between delegates. Time it at your next show, or estimate conservatively: 60–80 badges per hour per desk for a well-configured system with fast printers. If your system is slow to load, badge stock jams frequently, or staff share a single login queue, adjust down.

Building the model: what it actually looks like

Once you have those four inputs, the model is not complicated. For each 30-minute window:

• Estimated arrivals (from your historical curve, scaled to this year's expected attendance)
• Weighted processing time (pre-reg vs walk-in mix)
• Required throughput (arrivals ÷ window in minutes)
• Desks needed = required throughput ÷ per-desk rate
• Staff needed = desks needed + 1 float per three desks

That gives you a staffing schedule by hour — not a flat headcount. Your ops team then maps that to shift patterns, briefing times, and break cover.

A 1,200-delegate show with a 9am keynote might look like this in practice: two staff at 7:30am for early registrations and setup checks, ramp to eight by 8:15am, peak at ten between 8:30am and 9:15am, drop to four by 10:30am, and hold at three through the afternoon for walk-ins and badge reprints. That's a very different brief to "ten staff, 8am–4pm" — and it's the difference between a smooth morning and forty delegates photographing your queue to post on LinkedIn.

You can use the Booth Staffing Calculator at /tools/booth-staffing-calculator to model shift cover and peak headcount — it's built for exhibitor booth teams but the underlying logic (peak windows, shift cover, float) transfers directly to registration desk planning.

What the model exposes beyond headcount

Once you run the numbers, you'll often find the constraint isn't staffing at all — it's desk capacity. If you need ten-desk throughput in your peak window but you've only got six badge printers, no amount of staff solves the problem. The model makes that visible before show day, not during it.

The same goes for system performance. If your registration platform takes 12 seconds to load each delegate record, your theoretical throughput rate is halved. When your exhibition registration system is holding you back, it tends to show up exactly here — in the gap between your modelled throughput and what actually happens at the desk.

Network is the hidden variable most ops teams don't budget for. A hotel or convention centre Wi-Fi that can't handle 15 concurrent badge-print sessions under load will grind your registration to a halt regardless of how many staff you have. Your model should flag this as a risk and your show-week runbook should have a mitigation: dedicated hardwired connections for registration desks, or an offline-capable fallback in your reg system.

Making the model repeatable

The whole point of building a model rather than a one-off calculation is that it compounds. After each show, you feed in the actual scan log, compare it to your projected demand curve, and note where the model was off and why. Did a keynote start 15 minutes late and flatten the morning peak? Did a social media post drive a walk-in spike you didn't predict? Those annotations turn a spreadsheet into institutional knowledge.

Over three or four shows, your demand curve becomes genuinely predictive. You'll know that this particular show always has a 40% late-registration surge in the final week, and that it produces a sharper morning peak than your other events. You'll staff for it without having to argue the case from scratch each time.

For teams running multiple shows a year across different venues, this is where a dedicated ops tool starts earning its keep. Keeping the model in a shared spreadsheet works at low volume; once you're running six or eight events with different ops leads, the version-control chaos and manual data entry start costing you more than the tool would. Five signs your show ops have outgrown spreadsheets covers the broader set of triggers, but registration staffing is usually one of the first cracks to show.

The brief that actually lands with temp agencies

One underrated benefit of a proper staffing model: it produces a brief that temp agencies can act on. Instead of "we need ten registration staff for a conference", you can send an hourly schedule with role descriptions (desk operator, queue marshal, badge reprint station) and explicit peak windows. Agencies can match skill levels to roles — experienced staff on peak desks, newer staff on quiet afternoon shifts — and your show-week coordinator spends less time managing on the fly.

The same brief feeds your internal ops team's run-of-show. Everyone knows which hour requires all hands and which windows allow bathroom breaks. That sounds obvious. At most shows it isn't — and the queue during the ops manager's lunch break is the evidence.

Where a custom system changes the calculus

For shows above a certain scale — say, 2,000+ attendees with multiple registration touchpoints — the manual model starts to have limits. You're updating a spreadsheet the night before based on final pre-registration numbers, briefing a team who haven't all read it, and hoping the morning holds.

A registration system that exposes real-time throughput data — badges printed per desk per hour, queue depth at each touchpoint, staff login status — lets you manage the peak live rather than just plan for it. Combined with the staffing model as your baseline, you can see when desk four is running slow, when walk-in volume is beating your forecast, and where to shift float staff before the queue builds.

That's a different kind of ops tool to most off-the-shelf exhibition platforms, which tend to give you post-event reports rather than live ops data. Whether you're comparing an off-the-shelf exhibition platform versus a custom build, the registration desk is one of the clearest test cases: what does the system tell you while the show is running, not just after?

If your current platform's answer is "nothing until you export Monday's report", that's worth factoring into your next procurement decision.

Start with what you have

You don't need a new system to build your first staffing model. Export your scan logs, map the demand curve in a spreadsheet, calculate your per-desk throughput against your peak windows, and produce an hourly schedule. Do it once, annotate it after the show, and you've already got more than most ops teams carry into their next event.

The model is the asset. Everything else — better tools, live data, integrated systems — is what you layer on top once you know what you're actually trying to measure.

Useful tool

Try Samvara's Organiser Exhibition ROI Planner — For organisers — show P&L by day.