Sign first, then send the code: why the timing of acknowledgment is what makes it stick

Most of what gets written about house rules is about the rules themselves: which fees to set, how to word them, what to put in the packet. Less gets written about when the guest agrees to them, which turns out to be the part that decides whether the agreement is worth anything later. The argument for capturing signed house rules before check-in is not really about the document. It's about sequence. The same acknowledgment is strong or worthless depending on when in the booking it happens.

So set the document aside for a minute and look only at the order of operations.

Three places to capture signed house rules before check-in

There are basically three timings a host can choose for the agreement, and almost everyone is using the first one without having chosen it.

In the listing (passive). The rules and fees live in the listing description and the house manual. They're disclosed, they're published, anyone can read them. But nothing makes the guest do anything. They book, the platform's blanket "I agree to the house rules" checkbox fires, and that's the entire record. Whether this particular guest read past the first line is unknown and unknowable. The rule existed; that's all the listing can prove.

After arrival (too late). The guest is in the unit. Now there's a printed sheet on the counter, or a "by the way, please reply confirming you've read the rules" text on day one. Some guests sign, most don't, and the ones who do are signing after they already have the keys. Nothing was contingent on it. If they'd refused, they'd still be standing in your kitchen. An agreement collected at this point is a courtesy, not a condition.

Before the code (the argument). The acknowledgment happens between booking and arrival, and the check-in details (door code, exact address, parking, wifi) are what's on the other side of it. The guest reads the rules and the itemized fees, signs, and the instructions unlock. This is the timing this whole post is about, and the reason it's different is not the document. It's that the guest did something, on a date, with the stay still in front of them.

Why "before the code" is leverage, not friction

The instinct is to read gating as an obstacle between the guest and their vacation. It's closer to the opposite. Why "before the code" is stronger has nothing to do with making the guest's life harder and everything to do with what their choice means.

When the check-in details sit behind the acknowledgment, signing becomes a voluntary act with a consequence the guest can see. They are not signing because a host nagged them after they'd already arrived. They're signing because they want the door code, and reading-then-signing is the step that produces it. The agreement is something they chose to do to move their own booking forward.

That voluntariness is the whole point. An acknowledgment a guest completes to get something they want reads very differently, later, from one a host extracted after the fact or buried in a checkbox nobody looked at. Nobody can claim they were ambushed by a rule on arrival night when they clicked through it three days earlier to get the address. The sequence converts "the host says I agreed" into "I agreed, and here's the moment I did it."

This is also the honest answer to when to send check-in instructions: not at booking, and not the morning of arrival as a reflex, but at the point the guest has acknowledged the terms, so that the thing they're waiting on becomes the thing that motivates the read.

What this does to a later dispute

Skip ahead to the part nobody wants to think about at booking: something goes wrong, there's a fee, and the guest contests it. Now the two timings are standing in front of an adjuster, a Resolution Center agent, or a small-claims clerk, and they do not look the same.

The listing-only host has a published rule and a blanket checkbox. The reviewer's question writes itself: did this guest ever actually see this specific fee? There's no good answer. The record can't distinguish a guest who read every line from one who clicked agree on autopilot. The dispute becomes an argument about what the guest should have known, which is exactly the argument the platform doesn't want to adjudicate and usually won't.

The before-the-code host hands over something harder to argue with: a clear, dated record that this guest, individually, was shown this fee and confirmed it on a day that pre-dates their arrival, voluntarily, because the check-in details were waiting on the other side. The contested question ("did they see it?") is already answered by the file. That doesn't decide the dispute; it just removes the most common reason these go nowhere. We wrote a whole piece on that gap (disclosure versus acknowledgment, and why the file is what fails) in why AirCover claims get denied. Timing is half of why the acknowledgment counts.

The mechanic, in one paragraph

The whole thing is one move. You build the packet (house rules plus itemized fees) once. The guest gets a link before arrival, reads it, and signs; the signing is timestamped and the text recorded so it can't be quietly changed later. The check-in details stay gated until that's done, then unlock automatically. No chasing, no counter signing, no paper on the counter: just a pre-arrival acknowledgment that produces itself. The how it works page walks the exact flow, and the features page covers what ends up on the record: the timestamps, the audit trail, the tamper-evident hash. The point to hold onto is that the gating and the signing are the same step — the guest reads to get the code, and reading-to-get-the-code is what produces the file.

Does gating hurt the guest experience?

This is the real objection, and it deserves a straight answer rather than a reassuring one. Gating is a host choice with a tradeoff. You are adding a step before arrival, and a step is not free.

But measure the step honestly. A well-built packet is a roughly ninety-second read on a phone: rules the guest mostly expected to see, fees laid out plainly, one signature. Framed that way, at the moment the guest is already looking forward to the trip and wants the address, it reads as a normal part of checking in, the same way a hotel asks for a card at the front desk. Most guests don't experience a short, clearly-framed acknowledgment as friction. They experience it as a host who runs a tight operation, which tends to attract the guests you want and gently filter the ones you don't.

Where it does cost you is the rare guest who balks at agreeing to terms they were always going to be subject to anyway. That's worth naming plainly: a tiny number of bookings may feel the gate. The honest trade is that you're exchanging a little friction up front, with the stay still ahead of everyone, for not having to manufacture a record after an incident — which can't be done at all, because you can't go back and get a guest to sign something dated before a check-in that already happened.

The sequence is the product

Strip out the document and the certificate and what's left is an argument about order. Rules in the listing prove they existed. Agreement after arrival proves the guest was already inside. Capturing it before the code, voluntarily, with the details on the other side, is the only one of the three that produces a record built before there was anything to dispute, by a guest who chose to make it.

None of this is a verdict, and none of it is a contract that decides the outcome for you. It's a stronger, earlier file, created at the one moment it can still be created cleanly: before the stay, while the guest still wants something from you. That's why the timing is the thing that makes it stick. If you want to see the order of operations in practice, the how it works page is the place to start, and why PreArrive exists makes the longer case for sequence over disclosure.