It is 01:12. A guest is standing in a doorway in Lisbon with a suitcase, typing a code into a keypad that beeps twice and does nothing. She has tried it six times. The code is correct — it is the code you sent — and the door is still shut.
You will spend the next forty minutes finding out why. It will turn out to be something small: a hash key the instructions never mentioned, a battery that died in October, a code that activated at 15:00 on a date that ended twelve minutes ago. Small causes, expensive consequences, and almost all of them decided months earlier when someone wrote the instructions and nobody stood at the door to test them.
The useful thing about self check-in is that it does not fail in interesting ways. The list is short and it repeats across properties, cities and lock brands. Six failure modes cover nearly all of it.
Self Check-In Moves the Failure, It Does Not Remove It
Before the list, the framing that makes the list worth reading.
Meeting guests in person fails one way: nobody is there. The host is stuck in traffic; the flight is three hours late. It is a failure of presence, and the guest's experience of it is waiting.
Self check-in trades that for a different failure: the instructions were wrong. Presence is no longer the variable — the accuracy of what you wrote is. That is a genuinely better trade, because instructions can be fixed permanently and traffic cannot. But it is a trade, not an elimination, and the hosts who are surprised at 01:00 are usually the ones who were sold elimination.
The corollary is that every failure below is a content or a maintenance failure. None of them is a guest failure, even the ones that look like one.
Failure One: The Code Belongs to a Different Reservation
The guest has a code. It is a real code that really opens the door. It is last week's.
This happens when the code is copied from a previous message thread rather than generated from the current reservation, when a template pulls the wrong booking, or when a host with several properties sends flat 3B's code to the guest arriving at 3C. It is the most embarrassing of the six because the guest can see, from your own message, that you sent it confidently.
The design fix. Never source a code from a previous conversation. It should come from the reservation record, and the message that carries it should also carry the property name and the arrival date — "Flat 3B, Rua Nova 14, arriving 20 September" — so that a mismatch is visible to the guest before they are standing at the door. A guest who can see the wrong flat name in the message will ask about it at the airport instead of at 01:00. The mechanics of generating that message from the booking rather than from memory are covered in automating check-in instructions over WhatsApp.
The recovery. The current code for every property has to be reachable by someone other than you, without unlocking your phone. One document, current, that your co-host or on-call contact can open at 01:00. If the only copy of your access codes is in your head or your sent messages, you have made yourself the single point of failure in a system you built to avoid being one.
Failure Two: The Keypad Needs a Key Nobody Mentioned
The code is right. The guest types it. Nothing happens, because this particular lock wants a hash after the digits, or a wake-tap on the panel before it will accept input, or the code entered twice, or the handle lifted upward before the latch will turn — which is standard on a lot of European multipoint doors and completely non-obvious to anyone who has not met one.
Whoever wrote your instructions already knew about the hash key. That is precisely why it is not in them. Knowledge of your own door is the hardest thing to write around.
The design fix. Instructions get tested by someone who has never opened the door, at night, following only what is written. Not by you. What survives that test is the instruction set. Include a photograph of the actual keypad — not a stock image of a lock — and, where the sequence is fiddly, a fifteen-second video of a hand doing it.
The recovery. Send the video into the chat rather than typing the sequence again. After six failed attempts more text is not the answer, and some locks lock out after repeated failures — a second failure stacked on the first. Know your lock's behaviour before it happens.
Failure Three: The Guest Is Inside the Building and Still Outside the Flat
The code opened something. It did not open everything. There is a street door with a keypad, a lobby door with a fob, a lift that needs the fob held against a reader, and then the flat door with its own code. Four barriers, and your instructions described one of them because the other three are invisible to you after the two-hundredth time you have walked through them.
The design fix. Count the barriers, then write one instruction per barrier, in order, numbered, with the count stated up front: "There are three doors between the street and the flat." A guest who knows there are three doors will keep going. A guest who thinks they have arrived and finds another locked door assumes something has gone wrong and stops.
The recovery. For shared-building barriers, the fallback is usually social rather than technical — a neighbour, a night porter, a resident coming home. Have the building manager's or concierge's number in the same place as the codes, and know the hours that number is answered. A guest waiting in a lobby is in a better position than one waiting on the street, and moving them inward is worth doing even if the flat door takes longer.
Failure Four: The Keypad Battery Is Flat
The lock has been beeping a low-battery warning for three weeks, in an empty flat, to nobody. Then it dies, usually in the cold, usually between 22:00 and 02:00 because that is when the door is being used.
There is no clever fix for this one. It is maintenance, and it is the failure mode that proves self check-in is a physical system with a software layer on top.
The design fix. Battery replacement goes on a date schedule, not on a "when it warns us" schedule, because nobody is there to hear the warning. Put a check on the turnover checklist — the cleaner presses the keypad and confirms it lights normally — and replace on a fixed interval regardless of whether the lock has complained. Keep a mechanical override key in a second, separate lockbox that only you and your on-call contact know about.
The recovery. Someone drives over. That is the entire recovery, and any vendor who tells you otherwise is describing a product that does not exist. What you control is how long it takes: whether there is a named person who is actually on call at that hour, whether they have the override key, and whether the guest was told within four minutes that help was coming rather than left messaging into silence for forty. The structure for that on-call chain is the same one used for any night incident, set out in handling after-hours guest emergencies.
Failure Five: The Guest Is at the Wrong Door
The map pin sits on the centroid of a large building whose numbered entrance is on the other street. Or the pin is accurate and the navigation app routes to the service entrance at the back. Or the address is 14 and there is also a 14A and a 14 bis, forty metres apart, both with keypads.
The guest is not lost. They are somewhere precise and wrong, which is worse, because they will keep trying the code on a door that was never yours.
The design fix. Walk to your own pin from the nearest metro or main road, with a phone, as though you had never been there. Fix the pin so it lands on the door and not the building. Then send a photograph of the entrance taken from standing height on the pavement, in daylight, with enough context either side to be recognisable — the pharmacy on the left, the green gate on the right. A photograph of a door disambiguates an address faster than any written description, and it works across languages.
The recovery. Ask the guest to send their own location pin, and navigate them in from where they actually are. Do not re-send the address; they have it already and it is what put them there. A few sentences of turn-by-turn from their pin to yours resolves this in minutes.
Failure Six: The Flight Lands After the Window Closes
The code was valid from 15:00 to 23:00. The flight was delayed. The guest reaches the door at 23:40 with a code that expired forty minutes ago, and the system that was supposed to remove you from the process has just put you back in it, at the worst hour.
The same failure wears other costumes: a key-collection point that closes at 20:00, or a code scoped to a single calendar date used by a guest whose taxi arrives at 00:15 the following day.
The design fix. Do not scope access windows more tightly than the risk requires. A code valid from midday on arrival day until midday after checkout costs you nothing and removes a whole failure class; scoping it to a four-hour slot buys a security margin most properties do not need. Ask for the arrival time at booking and confirm it again the day before, which is one of the few pre-arrival questions that reliably earns its place — the wider case for that pre-arrival sequence is in automating check-in without making guests feel like a ticket number.
The recovery. Keep one override that is not time-bound, held by the on-call person, and treat its use as a normal event rather than an exception. Whoever is covering the night needs to be able to issue it without waking you, which is a question about how your messaging is set up rather than about locks — if everything arrives on your personal phone under your personal identity, nobody can cover for you, which is one of the practical consequences of the difference between the WhatsApp Business app and the Platform.
The 01:00 Recovery Path
Five things determine whether a failed arrival takes eight minutes or fifty. None of them can be arranged at 01:00; all of them can be arranged now.
- The guest reaches a human in one step. One number, answered, no menu, no "our team will respond within 24 hours". How a lockout reads in the review usually turns on how long the guest spent unsure whether anyone had heard them.
- Whoever answers can identify the property without you. Reservation, address, lock type, quirks. If the on-call person has to phone you to find out which flat 3B is, you are not actually covered.
- Access details live somewhere current. One source, updated when codes change, openable by the on-call person at speed.
- A physical fallback exists. A second lockbox with a mechanical key, a neighbour who holds a spare, a 24-hour hotel two streets away with a standing arrangement. Decide which one you have before you need it.
- The failure gets written down. The hash key nobody mentioned is worth fixing permanently the next morning, for every future guest. A lockout that changes nothing will happen again.
Most hosts have one and two of these and think they have all five. The test is simple: could someone else resolve tonight's lockout without contacting you? If not, self check-in has not removed you from the process — it has only moved when you get called.
What Self Check-In Does Not Solve
It does not reduce the number of things that can go wrong. It changes their character. Presence failures become instruction failures, and instruction failures are cheaper and more fixable, but they are not zero and they never become zero.
No automation fixes a flat battery. Software cannot detect that a keypad is dead, cannot open a mechanical door, and cannot be at the property in twenty minutes. If your plan for a dead lock is a message template, you do not have a plan. Someone has to drive over, and the only question you control is who and how fast.
Everything above assumes the guest can receive a message. A guest who lands with no roaming, no local SIM, and no WiFi — because the WiFi is inside the flat they cannot enter — is unreachable by every channel you have. The counter to that is unfashionable and physical: instructions sent before travel so they are already on the phone, a printed card in the lockbox, and a phone number that works as a phone call rather than only as a chat.
Counting matters too. Most hosts have a strong opinion about how often check-in fails and no record of it. Until you log every failed arrival with its cause, you are guessing about which of the six is actually costing you, and the six are not equally likely at your properties.
As for Welco: it answers guest questions on WhatsApp and flags the ones that need a person, which helps with the four failures that are really information failures. It does not operate locks, does not know your battery is low, and will never be the thing that gets a spare key across town. On a dead keypad it does one useful thing — makes sure the message reaches someone awake with an urgency flag on it — and nothing else. That is worth being clear about before you buy anything.
The Operational Picture
Self check-in is not a product you install. It is a set of written instructions, a maintenance schedule and an on-call arrangement, and it fails at whichever of the three you neglected. The six failure modes above are each a decision someone made months earlier, which is also why each one is fixable permanently rather than repeatedly.
Welco sits on the communication side of this: guests message from their own WhatsApp, get answered in their own language at whatever hour they land, and anything that needs you — a door that will not open, a code that has expired — is escalated with an urgency level rather than left in a thread. It is one layer of the arrangement described above, not the whole of it. For the broader view of what that layer is being asked to do, see the guide to vacation rental guest experience automation, and if you want to see how the conversation actually reads, request a demo.