Two-Way vs One-Way OTA Connections
The overbooking risk is the famous problem. The quiet one costs more.
A two-way connection moves information in both directions automatically: your availability goes out to the channel, and bookings, cancellations and amendments come back into your system without anybody retyping anything.
Everything else is a partial version of that, and the word "connected" gets applied to all of them. Knowing which one you actually have is the difference between availability you can trust and availability you are hoping about.
The three connection types
Two-way API. Availability pushes out as it changes; bookings, cancellations and amendments arrive back automatically. The channel and your system hold the same picture, continuously. This is the only one of the three that actually prevents the problem people buy channel management to solve.
One-way push. You send availability outward, but what sells comes back as an email, a notification or a report you check. Somebody then enters it. The system is only as current as the last time a person did that.
iCal or calendar feed. A file the other system fetches periodically. It was designed for sharing calendars rather than selling inventory, so updates lag by minutes or hours, it usually carries no booking detail, and it frequently runs one way only. Useful for visibility, unsafe as the thing standing between you and a double booking.
Where double bookings come from
Not from selling on several channels. From the gap between a sale and every other channel knowing about it.
On a one-way setup that gap is however long it takes for someone to read an email and update a number. Overnight, that is hours. During a busy Saturday, it is however long until somebody sits down. On an iCal feed the gap is the refresh interval, whatever that happens to be.
Which is why "check the channels more often" never fixes it. The gap is structural, and the only real remedy is removing it — one shared pool that every channel reads from and writes to. The full treatment is here.
The quiet cost nobody counts
Here is the part that gets left out of every discussion of one-way connections, and it is probably the larger number.
Flow-back is not only about new bookings. It is about three things:
- New bookings — you notice these, because an email arrives.
- Cancellations — the place should return to your pool and become sellable everywhere again. On a one-way setup it frequently does not.
- Amendments — a party of four becomes two, releasing two places. Almost nobody catches these.
Put numbers on it. A twelve-seat tour running two hundred departures at around sixty percent load takes roughly 1,440 bookings a year. If one in ten cancels and one in twenty shrinks by half, that is about 180 seat-equivalents returning to inventory annually — worth around $10,800 at $60 a place, and worth nothing at all if the channel is never told they are free again.
The reason this goes unnoticed is that nothing appears to go wrong. There is no angry guest and no refund. There is simply less revenue, spread thinly across a season, in departures that ran with empty seats you had already sold once.
Latency and the price of safety buffers
Operators who know their sync is slow do the sensible thing and hold capacity back. That works, and it is expensive.
- Holding one seat of twelve — 8.3% of capacity, about $12,000 a year unsold on the example above
- Holding two seats — 16.7%, about $24,000
- Holding three — a quarter of your capacity, about $36,000
That is the real price of a poor connection, and it never appears as a line item. It shows up as departures that ran two-thirds full while the operator felt they were being prudent. The same logic applies to long cut-off times set for safety — a buffer you can price is a buffer worth questioning.
How to test what you have
Do not read the marketing page. Every vendor calls their connection a channel manager. Run two tests instead, both of which take ten minutes:
- The inbound test. Make a booking on the channel. Does it appear in your system without anybody touching anything? Time how long it takes.
- The outbound test. Cancel a booking in your system. Does that place become bookable on the channel again, on its own?
Most operators have never run the second one, and it is the test that catches the quiet problem above. A connection can pass the first and fail the second — which means you are protected against overbooking and losing inventory anyway.
Signals worth noticing while you look: if setup involved pasting a calendar URL, it is a feed. If bookings arrive as email notifications you action, it is one-way. If there is a field for how often to sync, that interval is your exposure window.
Questions before connecting
- Is this two-way, and does that include cancellations and amendments — not just new bookings?
- What is the maximum time between a sale on the channel and my availability updating elsewhere?
- What happens if the connection drops? Does the channel keep selling from a stale figure, or stop?
- Will I be told when a sync fails, or do I find out from a guest?
- Does the connection carry the detail I need — names, party size, contact, special requirements — or just a count?
- Who supports it when it breaks: the platform, the channel, or nobody in particular?
How Travelity handles it
Availability is held once and shared with connected channels and your own booking widget through the channel manager, with bookings arriving in one queue rather than an inbox. Which connections are live varies by account, so run the two tests above during your trial rather than taking anyone's word for it — including ours. Trials run 21 days with no card.
Frequently asked questions
What is a two-way channel manager?
One where information travels in both directions automatically — your availability goes out to the channel, and bookings, cancellations and amendments come back into your system without anybody retyping them. A one-way connection sends availability out but relies on you to enter what sold.
How do I stop getting double bookings from multiple OTA channels?
Make sure every channel draws from one shared pool of availability that updates the moment anything sells. Double bookings happen in the gap between a sale on one channel and that place closing on the others, so the fix is removing the gap rather than checking more often.
What is wrong with an iCal connection?
It was designed for sharing calendars, not for selling inventory. It works by the other system periodically fetching a file, so updates lag by minutes or hours, it usually carries no booking detail, and it frequently runs in one direction only. Fine for visibility, unsafe as the thing standing between you and a double booking.
Do one-way connections cost you money even without overbookings?
Yes, and this is the part most operators miss. When a booking is cancelled or a party shrinks, those places should return to your available pool and be resellable everywhere. On a one-way setup they frequently do not, so the inventory is quietly lost rather than resold — and nothing appears to go wrong.
How can I tell what kind of connection I have?
Test it rather than reading the marketing. Make a booking on the channel and see whether it appears in your system without anyone touching it. Then cancel something in your system and check whether the place becomes bookable on the channel again. If either needs manual work, it is not a two-way connection.
Bottom line
Run the outbound test today: cancel something and see whether the place reappears on your channels without help. Everyone tests inbound; almost nobody tests outbound, and that is where inventory quietly disappears.
Then price whatever safety buffer you are carrying. Holding two seats of twelve costs about a sixth of your capacity — real money, paid every departure, to compensate for a connection that could simply be better.
Related guides
See Travelity in action. Book a Personalized Demo.
30 minutes that can completely change the way you run your travel business. See how Travelity can help you work smarter, sell more, and operate with less stress.