If you haven't read it yet, our guide to the legal duty behind guest registration covers the Immigration (Hotel Records) Order 1972 in full. This piece assumes you've accepted the duty and want to build something that satisfies it without becoming a second job. The short version of what the Order asks for: a written record of every guest aged 16 or over — name, nationality, next destination, plus ID document details for some guests — kept for at least 12 months.
The flow at a glance
A digital guest registration flow has six jobs. Most tools do two or three of them well and quietly skip the rest, which is why "we have digital check-in" and "we can answer a police request" are not the same sentence.
Step 1: Trigger the request automatically
The first failure point is the oldest one: a host who has to remember to send the form. If registration depends on you pasting a link into a message, it will be missed on exactly the busy changeover day you needed it. The request should be created by the booking itself, from your calendar or channel manager, with no human in the loop.
Timing matters more than it looks. Too early (at booking, months ahead) and guests ignore it; too late (on the doorstep) and you're chasing. A common sweet spot is roughly 24 hours before arrival, with automatic reminders for guests who haven't finished. Last-minute bookings need the request to fire immediately, which is a good test to run on any tool: book a same-day stay and see what happens.
Step 2: Capture every adult, not just the booker
This is the single most common gap, and it comes straight from how booking platforms work: you get one name, the person who booked. The Order, as we covered in our legal-duty guide, is framed around each guest aged 16 or over. A flow that only collects the lead booker's details satisfies "we collected something" while leaving the rest of the party unrecorded.
A workable flow asks the lead guest how many adults (16+) are staying, then collects each person's details, either by having each adult fill their own short form or by the lead guest entering them. Per adult, you need:
- Full name and nationality (the fields the Order specifically asks for).
- Next destination, which is the field most digital tools omit entirely, because it isn't needed for ID verification. It's usually best captured as a simple free-text box near the end of the stay, or at check-out.
- ID document type, number and place of issue for guests who aren't British, Irish or Commonwealth citizens, so the form should branch on nationality rather than asking everyone for everything.
Children under 16 fall outside the per-person record, but it's still sensible to capture a headcount, both for the booking and for your own safety and insurance records.
Step 3: Verification and registration are two jobs
Hosts and vendors blur these together, and the blur causes most of the compliance trouble later. Verification answers "is the person arriving who they say they are?" It uses a photo of an ID document, is a point-in-time check, and the image is sensitive and has no reason to hang around once the check is done. Registration answers "can I show who stayed here, on these dates?" It's a small set of text fields, it's lower-sensitivity than a photo of a passport, and the Order says it has to be kept for a year.
The practical consequence is that a good flow treats them as separate data with separate lifetimes. The ID photo can be deleted quickly. The register line cannot. A tool that collects one blob called "guest ID" and applies a single deletion rule to all of it is making that choice for you, and not necessarily in the direction the law requires.
Step 4: Gate the door code on completion
A registration form with no consequence for skipping it will be skipped. The reliable fix is to make the door code, WiFi details and directions the reward for finishing: the guest receives them automatically once the form, house-rules acknowledgement and consent are complete, and not before. This also has a security benefit, since a code sent at booking can be shared, forwarded or stay live for weeks, while a code released after verification is tied to a person you've actually checked.
For the timing and smart-lock side of code delivery, see how to send Airbnb door codes automatically. The point here is that registration is what makes the gate meaningful.
Step 5: Store it with two retention clocks
This is where the data-protection rules and the 1972 Order meet, and the answer is to be explicit rather than clever. UK GDPR expects you to keep personal data no longer than necessary and to be able to say why; the Order gives you a documented reason to keep one specific record for a year. Both can be true if you separate the data.
| Data | Purpose | Sensible retention |
|---|---|---|
| ID document photo | Confirm identity at check-in | Short: delete soon after check-out |
| Register entry (name, nationality, next destination, ID number where required) | Satisfy the 1972 Order | At least 12 months from the stay |
| Consent and house-rules acceptance | Evidence the guest agreed to your terms | Per your own policy; often alongside the booking record |
| Marketing contact details (if any) | Only if the guest opted in | Until they withdraw consent |
Write your retention periods into your own privacy notice; the ICO's guidance on UK GDPR principles is the place to check how to document them. If you're unsure how the Order applies to your specific let, read the text of the Order itself or take advice. This article is practical guidance, not legal advice.
Step 6: Run the police-request drill
A register you can't search is a register you don't really have. Before relying on any system, run a ten-minute drill using a made-up scenario: "An officer asks who was staying at Property B on the night of the 14th, and for the details of every adult." Can you:
- Find the right stay without opening four tabs or scrolling through chat threads?
- See every adult in the party, not only the person who booked?
- Produce nationality and next destination for each, and ID details where required?
- Export it as a readable file, in minutes, from a phone?
- Do the same for a stay eleven months ago, not just last week?
If any answer is "not really", you've found the gap while it's cheap. The last question is the one that trips up tools built primarily around the check-in moment, because the record may have been quietly cleaned up long before the 12 months were over.
Edge cases that break flows
- Guests who don't use WhatsApp or can't open a link. You need a fallback: an emailed link, or a printed QR card in the property, so nobody is locked out and nothing is skipped.
- Language. A form guests can't read gets abandoned or filled in wrongly. Check which languages the flow supports and that the legally relevant fields are understood in each.
- Direct bookings. If a tool only syncs from Airbnb or Booking.com, your direct guests fall outside the system. They're often the ones you know least about.
- Late additions to the party. A friend joins on night two. The flow needs a way to add a guest mid-stay, or the register is wrong from day two.
- Extended stays. A fortnight-long stay is one register entry per guest, not a new one per night. Make sure the system doesn't create duplicate or fragmented records.
- Guests who refuse. Decide in advance what happens. The Order obliges guests to provide the information, so a clear written house rule that check-in details are required for every adult is reasonable, and the door-code gate enforces it without an awkward conversation.
Questions to ask any vendor
Take this list to any demo, including ours. Honest vendors will have clear answers; vague ones tell you something too.
- Which fields do you capture per guest, and are nationality and next destination among them?
- Does it collect every adult in the party, or only the lead booker?
- How long do you keep (a) the ID image and (b) the text record, and can I change either?
- Can I search and export records across all my properties in one place?
- Where is guest data stored, who else can access it, and what happens to it if I cancel? Ask for a straight answer, not a brochure line.
- Does the door code release depend on completing the form, and can a guest bypass it?
- What's the fallback for a guest who can't use the link?
- Do you use the official WhatsApp Business API, or automate a personal number? The second risks the number being banned mid-season.
What our own flow does and doesn't do
In the interest of the same honesty we'd ask of anyone else: Pivot Bureau's WhatsApp self check-in sends the guest a link about 24 hours before arrival, collects house-rules acceptance, photo ID and consent, and releases the door code only after that's done. It runs on the official WhatsApp Business API, supports English, French and Spanish, and handles multiple properties from one dashboard. Guest ID photos are encrypted at rest and automatically deleted seven days after check-out.
That seven-day deletion is the right call for the ID image, but it is shorter than the Order's twelve-month duty for the written record. So we'd tell any host what we're telling you here: use the verification flow for what it's good at, and keep a separate register, even a simple spreadsheet with one row per adult guest, for the full year. Ask us what is and isn't captured for your setup before you rely on it; we'd rather you ask than assume.
A registration flow isn't compliant because it has a form. It's compliant because, a year later, you can still answer the question.
If guest questions before arrival are eating your evenings as well, an AI receptionist can take those out of your inbox while the check-in flow handles the paperwork. For the lock-box alternative, see WhatsApp self check-in vs key lock boxes, and for ready-made wording, our self check-in message templates.