I found it during an afternoon I’d set aside for something else entirely. I was in the lock app looking for a battery reading, and I scrolled past the code list instead: eleven active codes on one three-bedroom house that had hosted maybe forty stays that year.
I could account for four of them. My own. The cleaner’s. One labeled “Mom - Aug,” which was accurate and fine. And one labeled with a confirmation code I recognized from a stay the week before.
The other seven were just numbers. No labels, no dates, no expiry. I worked backwards through my own text messages for the better part of an hour and identified one of them: a handyman who’d come to re-seat a garbage disposal the previous summer. Fourteen months earlier. His code still opened my front door.
Nothing bad ever came of it. That’s not the point. The point is that I had done the work everybody tells you to do — I’d bought the Wi-Fi lock, I’d wired the booking to the code, my guests got their number without me lifting a finger — and I had automated exactly one half of the transaction. Codes went in. Nothing ever took them out.
Key Exchange Is a Lifecycle, Not an Event
When hosts say “automated key exchange,” they almost always mean one arrow: booking comes in, code goes out. That arrow is the easiest one to build and the least interesting one to get right.
The actual exchange has five stages, and a system that only handles the first two is the one that leaves eleven codes on a lock:
- Issue — a credential comes into existence, tied to a specific person and a specific window.
- Deliver — it reaches that person, in a channel they’ll actually read, at a time that’s useful.
- Hold — it stays valid for exactly as long as the reason for it stays valid.
- Revoke — it stops working, automatically, on a condition rather than on your memory.
- Prove — you can answer “who could open this door on March 4th?” without an hour of forensics.
Stages one and two are what the smart lock marketing sells you. Stages three, four and five are where the work is, and they’re the reason “can software do my key exchange?” is a different question from “does my lock have an app?”
Why the Lock Can’t Do This By Itself
Your lock knows about codes. It does not know about bookings. That sentence is the whole problem in miniature.
A lock can hold a code, start it on Friday at 4 PM, end it on Sunday at 10 AM, and log the openings. What it cannot do is notice that the guest extended by two nights, or that the reservation was cancelled on Thursday, or that you moved the booking to the other unit because the dishwasher flooded. To the lock, Friday-to-Sunday is Friday-to-Sunday forever. The reservation changed; the credential did not.
This is why “smart lock management” and “key exchange automation” are different products even when they’re sold as one. Lock management is scheduling codes. Key exchange automation is keeping codes in agreement with reality — and reality lives in your reservation data, not in your lock.
There’s a decent tier system for what you’re actually choosing between:
| Layer | What it knows | What it can’t fix |
|---|---|---|
| Lock app alone | Codes, schedules, battery, open events | Anything about a booking; every change is manual |
| Lock app + calendar import | Dates that a stay exists | Who the guest is, whether it’s confirmed, whether the turnover finished |
| Booking-aware layer | The reservation itself, its status, its property, its guest, its cleaning | Nothing in this chain — it’s the layer where the rest gets solved |
The third row is the one people are describing when they search for software that automates key exchange. It isn’t a lock feature. It’s a system that reads your reservations and drives the lock as a consequence. Outkeepr sits at that layer for the hosts I know using it — it holds the reservation, so a change to the stay is a change to everything that hangs off the stay, rather than eleven separate things you have to remember to go update.
If you haven’t picked hardware yet, sort that out first — the smart lock setup guide covers connectivity, code capacity and the physical backup you’ll eventually need. This post assumes the lock exists and asks what should be driving it.
The Five Events That Should Change a Credential
Here’s the test I’d apply to any setup, mine included. For each of these, ask: does the door code change by itself, or does it change because I noticed?
The booking is confirmed. Not inquired about, not requested — confirmed. A credential attached to anything less is a credential handed to someone who never booked, which is the most common way a fully automated flow embarrasses a host.
The stay is extended. A guest adds two nights on the second morning of a three-night stay. If the code dies Sunday at 10 AM as originally scheduled, your guest is standing outside a house they’re currently paying for. This one produces genuinely angry messages, because from the guest’s side you locked them out of their own rental.
The stay is shortened or cancelled. The mirror image, and the one with real exposure. A guest cancels on Wednesday for a Friday stay. If nothing revokes the code, a stranger holds working access to your property for a window you’ve already resold to somebody else.
The reservation moves to another property. You shuffle a guest between units. Two things have to happen: the new unit’s credential has to exist, and the old one has to stop. Hosts reliably do the first and reliably forget the second.
The turnover finishes — or doesn’t. Early-arrival requests are where automated access most often promises something the property can’t deliver. If your rule is “code activates at the check-in time,” and your cleaner is running two hours behind, you have automated the act of letting a guest walk into a dirty house. The honest trigger isn’t the clock, it’s the state of the clean, which only exists in a system where the cleaning and the reservation are the same timeline. That’s the specific reason I stopped coordinating turnovers over text — the cleaner scheduling guide walks through getting that signal out of a group thread and somewhere a computer can see it.
The single question worth asking a vendor: not “can you create a code from a booking?” — everything can. Ask what happens to the code when the booking changes. The demo never covers it and it’s where the whole category separates.
Revocation Is the Half Nobody Automates
I want to dwell on stage four, because it is genuinely the one everyone skips, and the reasons are psychological rather than technical.
Issuing a code has an obvious failure mode. If it doesn’t happen, a guest is locked out at 9 PM and you hear about it immediately and loudly. So hosts build that arrow first and test it constantly.
Failing to revoke has no failure mode at all, right up until it has a very large one. Nothing happens. No one calls. The code just sits there, quietly working, for fourteen months. There’s no feedback loop, so there’s no pressure to build the mechanism, so the mechanism doesn’t get built.
Three rules that fixed this for me:
Every credential gets an expiry at the moment of creation. Not later, not “I’ll clean it up.” If you cannot name the date a code should stop working, you shouldn’t be creating it yet. The one-off handyman gets 24 hours. The guest gets the stay plus a small tail. The window cleaner coming Thursday gets Thursday.
No credential is created by hand if a rule could create it. Hand-made codes are the ones that survive, because they were never attached to anything that ends. Once a code is a consequence of a reservation or a scheduled task, its death is a consequence too — which in practice means the thing driving your credentials has to be the thing holding the booking. That’s the test I’d put to whatever you’re using, and it’s the reason I moved this onto the same system as everything else: in Outkeepr the reservation is the object, and the arrival details, the door code and the turnover all hang off it, so a stay that changes doesn’t leave three orphans behind in three different apps.
“Delete it later” is not a plan, it’s a to-do you will not do. I say this as someone with seven anonymous codes on a lock.
The reason this matters more for short-term rentals than for a normal house is throughput. A home has maybe six people who’ve ever had a key. A rental doing forty stays a year, with cleaners, a handyman, a pest service and the occasional neighbor letting a plumber in, accumulates access the way a phone accumulates apps. Nobody decided to have eleven codes. It’s just what happens when the inflow is automated and the outflow isn’t.
Non-Guest Credentials Need More Design, Not Less
The guest code is the easy case — it has a start, an end, and a reservation to hang them on. Everyone else is harder, because their access isn’t attached to anything with a natural end.
Cleaners shouldn’t get a permanent code and shouldn’t get a fresh one per turnover either. The first is standing access you’ll forget about when they move on; the second is manual work forever. What you want is access that exists because a turnover exists — the cleaner’s credential is scheduled off the same booking the guest’s is, which means it appears on turnover days and doesn’t otherwise. It also means an assignment change moves the access with it instead of leaving it behind. This is the part of Outkeepr I’d have paid for on its own: the cleaning is an object with a date, an assignee and a property, so the access question has an obvious answer instead of being a separate thing I maintain.
Trades and one-off visits get a code that expires the same day, every time, without exception. The plumber who “might need to come back Tuesday” gets a new code on Tuesday. This costs you thirty seconds and removes the single largest source of the anonymous-code problem.
Co-hosts and family get individually named credentials, never a shared one. The whole value is that a relationship ending is one deletion rather than a code change that ripples out to everyone.
You keep a code you never give anyone, ever, and never use for convenience. It’s the credential that’s still good when everything else has been rotated because something went wrong.
The distinction I’d draw across all four: guest access should be automatic, and non-guest access should be deliberate but still time-boxed. The failure mode isn’t granting access to your cleaner. It’s granting it in a way that has no end date.
Stage Five: Being Able to Prove It Later
The last stage is the one that sounds like paperwork until the first time you need it.
Twice now I’ve been in a situation where the only useful question was “who could open that door, and did they?” Once a guest insisted the code I’d sent never worked, and once a cleaner and a guest disagreed about whether the property had been entered on a changeover afternoon. Both were resolved in about ninety seconds by a list of openings with times and credential names against them. Without that list, both would have been my word against theirs, and the honest answer would have been that I didn’t know.
Two things make that list useful rather than decorative:
- Credentials have names, not just numbers. A log full of “Code 7” tells you a door opened. A log that says “Cleaner — Marisol” tells you something. This is the actual reason per-person credentials matter, more than the revocation argument.
- The log outlives the credential. Deleting a code shouldn’t erase the record of what it did. Check this before you need it — some setups tidy the history away with the code.
If your lock’s history only goes back thirty days, decide now whether that’s enough. For most hosts it is, because the disputes that matter surface within a week. But it’s a decision worth making on purpose rather than discovering in the middle of one.
The Audit That Takes Twenty Minutes
Do this today, per property, before you change anything about your setup. It’s the cheapest diagnostic in hosting.
- Open the lock app and list every active credential.
- Next to each one, write the name of a person and the date it should stop working.
- Delete everything you couldn’t complete step two for.
- Count how many you deleted.
That number is the honest measure of your key exchange automation. Not how smoothly the last guest got in — how much unaccounted access accumulated while it was working smoothly.
Then run the second half, which is about the flow rather than the state:
- In the last three months, how many times did you personally create, send, or fix a door code? Including the ones that took ten seconds.
- How many times did a booking change and you had to remember to go change a code?
- If a guest cancelled tomorrow, what would remove their access, and would it happen without you?
Most hosts I’ve walked through this find the same shape: issuance is genuinely automated, and every single other stage is a person. That’s not a broken system exactly. It’s a half-built one, and the built half is the half that generates the least work.
What to Actually Look For in the Software
If you’re evaluating tools for this, the feature lists all look identical and none of them are describing the thing that matters. The criteria I’d use:
It reads reservations, not just calendars. An iCal feed gives you blocked dates. It doesn’t give you a guest, a booking status, a phone number, or a cancellation you can react to. Credential logic built on dates alone cannot tell a cancelled stay from a blocked one.
A booking change propagates without you. Extension, cancellation, shortened stay, property change. Ask about each one specifically.
The credential and the message come from the same place. A code programmed into a lock that doesn’t reach the guest is worth nothing, and two systems that each hold half the job means a guest whose code exists but who was never told it. The delivery half of this deserves its own thought — the automatic check-in walkthrough covers what it takes to get arrival information to land without you in the loop.
Non-guest access hangs off real work. If the cleaner’s access is a manual code you maintain by hand, the tool has automated the easy half and left you the rest.
Per-property pricing, so the fourth door is a small decision. This is more important than the headline number. A tool priced per property means adding a unit is incremental; a tool priced in plan tiers means adding a fourth door triggers a purchasing conversation with yourself. Outkeepr is $5 per property per month plus 0.5% per booking, with a 14-day trial — worth naming mostly because the shape is per-door, which is the shape the problem has.
A log you can read months later. Stage five. When a guest claims they couldn’t get in, or something goes missing, the only thing that helps is a record of which credential opened the door and when.
What It Looks Like When It’s Right
The house with eleven codes has four now, and three of them are permanent by design: mine, the cleaner’s standing access, and the one labeled “Mom - Aug,” which has an actual end date now.
The fourth is whoever is currently staying there. It appeared because a reservation was confirmed, it will stop because that reservation ends, and if the stay changes shape between now and then it’ll change with it. I don’t know what the number is. I haven’t known for about a year, which is the part I’d have found hard to believe when I was labeling codes by hand.
The thing I’d say to the version of me scrolling that code list: you didn’t fail to buy the right lock. The lock was fine. What was missing was anything above the lock that knew what a booking was — so every arrow that pointed away from “guest arrives” had to be drawn by hand, and hands forget.
If you want to close that gap, Outkeepr reads your Airbnb and VRBO reservations directly, keeps the arrival message and the property’s door code attached to the stay that produced them, schedules the turnover against the same booking so your cleaner’s access and your guest’s access come from one source, and answers the guest questions that would otherwise be the reason your phone is in your hand at 9 PM. Download the app and connect one property — run a single full cycle inside the trial, then go open the lock app and count the codes. That count is the answer.
Ready to automate your vacation rental?
AI guest messaging, smart lock codes, cleaner scheduling, and more — starting at $5/mo per property.
Try Outkeepr Free