Version seven of the nominations spreadsheet
The university's accommodation office sends a spreadsheet of nominated students in July. A week later another arrives with twenty names removed and thirty added. Some students have already booked directly with you, some have not replied to the offer, and a few have withdrawn from their course. Your team is copying rows into the booking system and colour-coding the ones they are unsure about.
Meanwhile the agreement has a date when unfilled nominated beds can be released to the open market, and a date when the university is told how many rooms are empty. Both are in a PDF in the operations director's email.
The root of the confusion
Each party works from its own record. The university knows who it nominated. You know who has signed. The contract knows what was promised. Nobody holds a live comparison of the three, so every change means a manual reconciliation, and every reconciliation produces a new version of the spreadsheet.
- Student identifiers differ: the university uses its student number, your system uses its own booking reference.
- Names are spelled differently, and some students use a preferred name.
- The same student can appear as both a direct booking and a nomination.
- Contract terms such as release dates, room types and rent levels are not held anywhere the system can check.
- Changes arrive by email at different times from different university staff.
Where the money leaks
A missed release date can leave rooms empty that could have been sold directly. A miscounted nomination can mean invoicing the university for the wrong number of beds, or a dispute at the end of the year about who was actually in residence. There is also the relationship: a university partner that keeps getting corrected numbers from you starts to wonder about everything else you report.
How we build nominations tracking
- Each agreement is entered once: university, building, room types, number of beds, rent, release dates and reporting dates.
- When the university sends a list, it is uploaded or emailed to a nominations inbox, and each row is read and matched to a booking using student number, email, date of birth and name, in that order.
- Confident matches are linked automatically. Possible matches, such as a similar name with a different email, go to a person to confirm.
- Each nominated student gets a status: offered, accepted, signed, withdrawn, no response. Status changes come from your booking system as they happen.
- The tracker counts signed nominated beds against each agreement and shows the gap by room type.
- A warning goes to the right person ahead of each release and reporting date, with the list of unfilled beds attached.
- Reports for the university are produced from the tracker in the format they ask for, so everyone works from the same numbers.
| Event | Before | With the tracker |
|---|---|---|
| New list from the university | Rows copied by hand | Matched to bookings, differences shown |
| Student withdraws | Noticed at arrivals | Status changes when the university or booking system says so |
| Release date approaching | Someone remembers | Warning with the list of unfilled beds |
| End-of-year reconciliation | Argument over versions | One history of every change |
Contract interpretation stays with you and your university partner. We record the terms as you give them to us.
One set of numbers for both sides
Your team stops maintaining a spreadsheet that only one person understands. When the university asks how many nominated beds are filled, the answer is on screen, with names. When a release date comes up, the decision about what to do with empty beds is made with days to spare, not the afternoon before.
Is this how your nominations work now?
- University lists arrive as spreadsheets in several versions.
- You have released or held beds late because a date was missed.
- Students appear twice, once as nominated and once as a direct booking.
- End-of-year numbers are disputed with the university.
- Only one person really knows the state of each agreement.