A Booking That Never Arrived: Channel, Mapping or Queue?
A reservation that exists on the channel and not in your calendar failed at one of three places: the channel, the mapping or the queue. Each has its own signature, and each asks for a different first move.
When a reservation exists on one side and not the other, the layer that failed decides what you do next, and how fast you have to move.
Last updated: October 24, 2026
When a reservation exists on the channel and not in your calendar, it failed at one of three layers. The channel may never have created it. The channel created it but the unit mapping couldn't route it. Or the message is still in transit. The channel's own pages settle the first, your unit codes settle the second, and time is the only thing that settles the third.
Key Takeaways
- Block the dates before you investigate. A room sold twice costs more than an hour of diagnosis, and the block is reversible.
- Three layers, three signatures. Channel, mapping, queue — each fails in a way you can see from outside.
- The channel's reservation page is evidence. Timestamps, unit codes and status there outrank anything in your inbox.
- Mapping errors are selective. They break one unit or one channel, not all of them at once.
- A delay resolves on its own; a failure doesn't. Give the clock a deadline, not an open-ended wait.
Three layers, three symptoms
The first layer is the channel. A reservation can fail to be created at all: a payment that didn't clear, a guest who abandoned the flow, an inventory error on their side. If the channel's own reservation list doesn't show it, nothing downstream will, and the guest is holding a confirmation for something that never existed.
The second layer is the mapping. The channel sells a unit under its own identifier, and that identifier has to point at one of your units. When it points nowhere, or points at the wrong unit, the reservation exists on the channel and has nowhere to land. This is the layer that produces the strangest symptoms, because it works for most bookings and fails for a specific subset.
The third layer is the queue. The reservation was created and routed correctly, and the message is simply still moving. Nothing is broken. The only question is how long you're willing to call it a delay rather than a failure.
There's a fourth place people forget, and it isn't a layer: a second listing. An old account, a duplicate unit, an agency listing that never got closed. The reservation arrived somewhere. It just didn't arrive at the calendar you're looking at.
What the channel can confirm
Open the channel's own reservation page before you open anything else. It answers four questions in one screen: does the reservation exist, what unit code is attached to it, what status does it carry, and what timestamp is on the last change.
Write those four down. If the status says confirmed and the unit code matches one of yours, you're in the queue or the mapping. If the status says cancelled, you have a different conversation with the guest, and it's better to have it before they arrive.
Then block the dates by hand, in your own calendar, and note that you did. This is the one action worth taking before diagnosis, because the cost of an overbooking is asymmetric: an unnecessary block costs you a night's availability, a double sale costs you a guest, a review and possibly a relocation.
Don't cancel the reservation on the channel side to "force a resend". A cancellation may not reach your calendar either, and in the meantime the dates can resell to someone else. You'd be solving a visibility problem by creating an inventory one.
localsbnb.com connects Airbnb, Booking.com, Agoda and Trip.com in one calendar, with each channel's source rate and source status beside the dates. When a reservation lands, the dates close in that one view; when a channel reports a status you don't recognise, it's visible next to the dates it affects rather than buried in a separate tab.
What a mapping error looks like
A mapping error is selective, and that's its signature. Look for one of these four patterns.
It works for three units and fails for the fourth. That's usually a unit added after the original setup, whose identifier was never tied to anything on the channel side.
It works on three channels and fails on the fourth. That points at one channel's unit list, which may still carry an old code from a listing you renamed.
It fails only for a specific unit type. Some channels sell by room type rather than by unit, and a type that maps to no unit will accept bookings that can never land.
It fails from the day a listing was edited. A rename, a merge or a re-listing can break a link that had worked for a year, and the break is invisible until the next booking.
To confirm, open the channel's unit list and compare it to yours, code by code, rather than name by name. Names drift; codes are what the connection reads. If a code has no counterpart, you've found the layer. Fix the pairing, then make a test booking on that unit specifically — not on a unit that already works, which proves nothing.
When it is only a delay
A delay has a shape too: the reservation exists on both sides, the timestamps are close, and your calendar simply caught up later than the confirmation email did.
The honest test is to compare the channel's creation time with the time your calendar recorded it. If the gap is consistent with what you normally see on that channel, you're looking at a delay. If the gap keeps growing while you watch, it isn't a delay, it's a queue that has stopped.
Give the clock a deadline rather than waiting indefinitely. Pick a point — before the guest's arrival, and before your own cut-off for arranging a changeover — and decide now what you'll do when it passes. The decision is easier made in advance than at 9pm with a guest in the hallway.
If a guest is already travelling, tell them what you know rather than what you're investigating. One line saying the booking is visible on the channel and you're confirming the room is worth more than silence, and it takes less time than the message you'll write at midnight if you wait.
If the reservation does land after you blocked the dates by hand, remove the block and check that the two agree on the guest's name and dates. A manual block and a real reservation sitting on top of each other is how a host ends up refusing a guest who has a confirmation.
FAQ
Should I cancel on the channel side to force a resend?
No. A cancellation is another message that may not arrive, and while you wait the dates can sell again. Block the dates on your side, keep the reservation intact, and work the diagnosis from the channel's own page.
How long does a delay take before it becomes a failure?
There's no universal number, and anyone quoting one is guessing about your channels. Compare the gap you're seeing with the gap you normally see on that channel, and set your own cut-off before the guest's arrival. If the gap is still growing, stop calling it a delay.
What if the booking went to a listing I forgot about?
That's more common than a technical failure. Search the channel for your address and for the unit name, and look for a duplicate listing, an old account or an agency entry that was never closed. If you find one, close it before you fix anything else.
Most of these cases end with a reservation that was always fine and a calendar that was looking in the wrong place. The sequence is what keeps that from becoming an overbooking. If the four channels and their statuses are the part you'd rather see in one place, localsbnb.com puts them beside the dates they affect. A booking that lands and a channel that reports a status sit in the same view.
This article is general guidance for hosts and isn't legal, tax or insurance advice. How each channel creates, reports and cancels a reservation sits in its own terms and can change without notice. Confirm the current terms of each channel you sell on, and keep your own record of what a guest was promised.
Reviewed by
Localsbnb Editorial Team