When Your PMS and Your Channel Blame Each Other

Two systems pointing at each other is a data problem with a paper trail. Three artefacts settle it in an afternoon.

Last updated: November 1, 2026

A rate you changed on Tuesday is still showing on the channel on Thursday. Your software says the update went out. The channel says it received nothing. Both statements can be true, and neither one tells you where the change stopped. Three timestamped artefacts do, and they take about an hour to gather.

Key Takeaways

• The boundary is invisible, and that's where the argument lives. Nobody can see the handover between two systems, so both sides fill the gap with a story.
• Six steps carry one change. You make it, your software records it, it leaves, the channel receives it, the channel displays it, the guest sees it. Each step has an owner.
• Three artefacts locate the step. A status view with its last sync time, your own record of the change, and what the guest actually saw.
• A ticket asks for one action. "It's broken" gets a template reply. A dated sequence with a specific request gets a person.
• Hold the exposure while it's open. Stop selling the affected nights on the affected channel, write down what you did, and tell the guest before they arrive.

Who owns which step

Blame is what happens when a boundary is invisible. Two systems meet somewhere in the middle, neither side can see the other's screen, and each one can describe its own behaviour accurately while the guest still gets the wrong number.

Break the journey into steps and the argument mostly dissolves. You change a nightly rate. Something records that change with a time against it. Something sends it. The channel receives it. The channel decides how to display it. A guest reads it. Six steps, and only the last one has no clock on it.

Ownership follows the steps. You own the change and the instruction. Your software owns what it records, what it sends and what it reports about the last attempt. The channel owns what it receives and what it displays. The guest owns nothing and sees everything.

That sounds tidy, and in practice it usually is. The confusion comes from one detail: each side reports on a different step. Your software reports that an update left. The channel reports what it currently holds for a date. A message saying "sent" and a screen showing "unchanged" aren't a contradiction. They're two clocks on two steps.

Once you accept that, the question stops being who's at fault and becomes which step is late. That's a question with an answer, and the answer comes from timestamps rather than from opinion.

There's a second reason to work this way. The person answering your ticket handles dozens of them a day, and all of them arrive as complaints. A message that names the step and its time is a different kind of object. It's a bug report, and it gets triaged like one.

The three artefacts that settle it

You need three, and two won't do, because any two of them can be explained away.

The first is the status view for the affected channel, captured with its last sync time visible. Not a screenshot of the calendar, and not a description of it. The status line that says when the connection last did anything, and what it did. This is the artefact that tells you whether the problem is one change or every change.

The second is your own record of the change. What you altered, on which unit, on which dates, at what time, in which time zone. Most software keeps this without being asked, and most hosts never look. If your record says you changed Thursday at 14:20 and the channel's first report of the new rate is 09:05 the next morning, you've located a gap of one evening, and you've done it without either support desk.

The third is what the guest saw. A screenshot of the channel's own page for those dates, or the confirmation a guest received. This is the artefact people skip, and it's the one that decides the size of the problem. A stale rate on a date nobody searched costs nothing. A stale rate that produced a confirmed booking is a conversation with a guest, and that conversation needs the evidence in the right order.

Where the first artefact lives matters. localsbnb.com shows each connected channel's own rate and status beside the night it applies to, across Airbnb, Booking.com, Agoda and Trip.com on one calendar, so the status and the date appear in the same view instead of in two tabs. That's the difference between a screenshot that proves a point and one that starts an argument.

One warning about timestamps. Write the time zone on every capture, including your own. A four-hour gap and a two-hour gap are different problems, and an unlabelled clock has caused more escalations than any bug.

Writing a support ticket that gets answered

Order matters more than length. Five short blocks will beat a page of narrative every time.

Start with one sentence naming the step, not the emotion. "Rate change made at 14:20 on 3 November has not appeared on the channel as of 09:00 on 5 November" is a sentence a support agent can act on. "Your sync is broken again" is a sentence that gets a link to the help centre.

Then the artefacts, labelled and attached. Three files with timestamps in the names, and one line saying what each one shows. Don't make anyone open a PDF to find the time.

Then the scope. Is it one date, one unit, every date on that unit, or every unit on that channel? The answer changes who looks at it, and you know it already from the first artefact.

Then what you've tried. Re-saved the rate, re-sent it, disconnected and reconnected, waited an hour. This prevents the first reply from asking you to do exactly that.

Then the one action you want. Re-push the rate for those dates. Confirm whether the last update was received. Tell me which side holds the stale record. Support can answer a specific request. It can't answer "please fix".

One thing to leave out: your theory of who's at fault. It's usually right and always unhelpful. The step either has a late timestamp or it doesn't, and the person reading your ticket can check that faster than they can evaluate an argument.

Working manually while it is open

A ticket takes days. The dates don't wait, so decide what you're doing about the exposure before you send it.

The first move is the cheapest: stop selling the affected nights on the affected channel. Not everywhere, and not forever. Just the specific dates that carry the wrong number, blocked until the record agrees again. You lose some bookings. You avoid a confirmed one at a price you never set.

The second is to write down what you did, with times, in the same file as the artefacts. If the problem turns into a guest conversation, that log is the difference between a decision and an excuse.

The third is the one hosts avoid. If a guest already holds a confirmation at the stale rate, tell them before they arrive rather than at the door. A message that offers a choice lands differently from a surprise at check-in, and the choice can be as simple as keeping the booking at the price they were shown.

Then set a review point. Two working days, look again, and if the step hasn't moved, escalate with the same artefacts plus the ticket number. Re-sending the same evidence with a date attached is what turns a first reply into a second look.

None of this requires knowing how either system works inside. It requires knowing which step is late, and being able to show it with a clock on it.

FAQ

How do I know which side is wrong?

You usually can't, and you don't need to. Compare two clocks: the time your software says the update left, and the time the channel first reports holding the new value. The later of the two is the step you're chasing. Where both timestamps agree and the display is still wrong, the problem sits after receipt, which is a different conversation.

Should I disconnect and reconnect the channel?

It's a reasonable last resort and a poor first move. Reconnecting clears the status history you need, and it can drop settings you'll have to rebuild. Take the status screenshot first, then reconnect, then check whether the same change lands. That way the reconnect becomes evidence instead of a guess.

What if the guest was already given the wrong price?

Honour it or offer a choice, but say so before arrival. Then keep the confirmation, the message and the dated log together in one place. The guest conversation is usually short. The record is what stops the same failure repeating next month.

Six steps, three artefacts, one specific request. localsbnb.com keeps the four connected channels on a single calendar with each one's rate and status beside the night, which is where the first artefact comes from and where the second one gets checked.

---

This article is general guidance for hosts and isn't legal, tax or insurance advice. Sync behaviour, connection status and each platform's partner terms change without much notice, so confirm current behaviour with the platform and with your software provider before you rely on any timing assumption.