Cvent Passkey reservation data and what to settle before you model room blocks

The housing report says pickup came in at 87 per cent, which everybody agreed was fine. Six weeks later a hotel invoice arrives with an attrition charge on it, and the finance lead wants to know how a block that hit 87 per cent produced a shortfall bill.

Both numbers are right. They were computed from different things, and the gap between them is where most room block modelling goes wrong. Cvent Passkey reservation data can support several defensible pickup figures at once, and the model you build is only as good as your answer to a boring question: what exactly is a row, and what exactly is the denominator.

What does the product expose, and what does your contract expose?

Cvent's own description of Passkey names a custom booking website, real-time reporting and tracking, registration integration, universal hotel connectivity, milestone alerts and sub-block group management, and says users can "See room pick-up in real-time and access reports" and "Feed bookings directly into hotel reservation systems" (Cvent, 2026). Reporting has kept moving: a release note dated 22 October 2025 describes an upgrade adding percentage-based metrics to the Block and Pickup Basic Report "to provide clearer visibility into event and hotel pickup performance" (Cvent, 2025).

None of that tells you what you personally can extract. Feature availability and contracted data access are separate questions, and the second one is answered by your agreement and your configuration rather than by a product page. Before designing anything, get someone to run the exports you plan to depend on and send you the actual files, with headers. Ten minutes of that is worth a week of reading documentation, because it settles which fields are populated on your event rather than which fields exist in the product.

Sub-blocks deserve a specific question. If exhibitors, speakers, staff and sponsors each hold their own allocation, then a single event-level pickup figure is an average across groups that behave nothing alike, and the group that under-picks is invisible inside it. Ask whether your export carries the sub-block on every reservation row, because retrofitting it afterwards from rate codes is guesswork.

Which grain does the export actually give you?

Four candidate grains show up in housing data, and they are not interchangeable.

A reservation is one booking. It might be one night or six, one room or three. Counting reservations tells you how many booking events happened, which is a useful marketing measure and a poor commercial one.

A room night is one room for one night. This is the unit hotels contract on, invoice on, and think in. Any model that will eventually meet money has to be expressed here.

A block night is the allocation you hold on a given night at a given property, which is the denominator for that night. Blocks are rarely flat across the week, so a single event-level allocation number hides the shape.

A guest is a person. Double occupancy means guests exceed rooms, and if you are counting people rather than rooms you will be systematically over on any night with a high share of shared rooms. On a show with a large contractor and build-crew population, shared rooms can run above a third of the block, and the guest count then overstates room demand by enough to change a contracting decision.

Get the export to carry all four, or carry enough to derive them, and state the one your headline uses. The industry vocabulary here is not always consistent between organisers, hotels and housing suppliers, and the Events Industry Council maintains an industry glossary through its APEX programme for exactly this reason (Events Industry Council, 2026). A shared definition is cheaper than an argument in December.

Pickup against block, and the three numbers that answer to that name

Take one property on one show. The block runs four nights: 60 rooms on Monday, 120 on Tuesday, 120 on Wednesday and 80 on Thursday, which is 380 contracted room nights.

The housing file shows 104 reservations, totalling 331 room nights, with 112 rooms occupied on the Wednesday peak.

Pickup expressed as room nights against contracted room nights is 331 divided by 380, or 87.1 per cent. Pickup expressed as peak-night rooms against the peak-night allocation is 112 of 120, or 93.3 per cent. Pickup expressed as reservations against a forecast of 95 reservations is 104 of 95, or 109.5 per cent.

Three numbers, one block, all honest. If the show director hears 109 and the hotel hears 87, next year's negotiation starts from two different beliefs about the same event. Put the definition in the report title rather than the footnote.

Reconciling one block against the hotel invoice

Now the part that produces the surprise invoice. Continue the same property. Say the contract allows a shortfall down to 85 per cent of contracted room nights before a charge applies. Eighty-five per cent of 380 is 323 room nights.

Your housing report says 331 picked up, comfortably above 323, so nobody expects a charge. The hotel bills on actualised room nights, meaning rooms genuinely occupied, and that figure is 318. The difference of 13 room nights is no-shows and early departures, which never touched the housing system because the reservation was never cancelled. At 318 against a 323 floor, the shortfall is 5 room nights, and at an average rate of 219 that is a charge of 1,095 before tax.

Small money on one property. Multiply it across eleven hotels and it stops being small, and the more damaging cost is that your model of block demand is 13 room nights optimistic on every property, which compounds into next year's contracted allocation.

The fix is to treat the housing file as a forecast of actualised room nights rather than a measurement of them, and to go and get the actualised figures from each property after the event. That is a chase, and it is the only way the model closes. Where the housing supplier's reporting differs from the registration picture as well, the join between housing and the registration file is a second reconciliation running in parallel, and neither substitutes for the invoice.

What to put in writing before the next cycle

Six questions, and the answers belong in a document rather than in somebody's memory.

Which reservation fields your export carries. Sub-block, rate code, arrival, departure, room type, occupancy, booking source and cancellation timestamp. Any field missing here becomes a dimension you cannot cut by, permanently, for that edition.

What happens to a cancelled reservation. If it disappears from the file, a Friday extract and a Monday extract disagree and you can never rebuild the curve. If it stays with a status, you can, and you should be keeping every extract anyway.

What happens to a modified reservation. Updated in place, or superseded by a new row with the old one retained. The first loses history and the second doubles your row count if you load it naively.

The grain of the standard pickup report. Established above, and worth confirming in writing because it changes with product releases.

Whether the export can be scheduled. A file somebody pulls by hand on a Tuesday is a file that does not get pulled during show week, which is the week it matters.

Who owes you actualised room nights, and by when. This is the one nobody asks and the one that decides whether your model ever matches the invoice. It belongs in the hotel contract, not in the housing supplier's scope.

Cancellations deserve one further note, because they behave differently before and after the cutoff date. Cancellations well ahead of cutoff release inventory that can be resold into the block, so they cost you nothing and often improve the final picture. Cancellations after cutoff, when the unsold rooms have already gone back to the hotel, reduce pickup against a commitment you can no longer fill. Two reservations cancelled on the same block, six weeks apart, therefore have completely different financial consequences, and a model that treats cancellation as one event cannot see the difference.

Where this stops

Reservation data describes bookings made through your block. It says nothing about the attendees who booked elsewhere, and on a show in a city with plentiful supply that group can be the majority. A block model built purely on Passkey data will therefore forecast your block accurately and your event's real accommodation footprint badly, which matters when anyone tries to convert those rooms into an accommodation figure for the event's emissions.

The second limit is behavioural rather than technical. Pickup responds to how hard you push the block, what the rate differential is against public rates on the same nights, and whether a booking incentive was running. A year-on-year pickup comparison across a year in which the rate gap moved by 40 dollars a night is comparing two different offers, and no amount of grain discipline recovers that. Record the rate differential alongside the pickup figure so the next person has the context, in the same way that the rest of your event data feeds should carry the conditions they were collected under. The wider question of pulling reusable extracts from the surrounding platform is its own planning exercise.

Start with one hotel. Take the block with the largest commitment on your last edition, pull the reservation-level export, compute pickup all three ways, then ask the property for actualised room nights and compare. The size of the gap between your 331 and their 318 is the correction your model has been missing, and one property is enough to find it.