Reading a Guest's Requests Back Before a Claim

A claim is decided on what was asked and what you answered. A short written recap, sent while the thread is still live, is worth more than a long explanation later.

Last updated: November 2, 2026

Most hosts write their version of events after the claim lands. By then the thread is closed, the guest has stopped answering, and every sentence reads like a defence. Write it while the stay is still running instead. Four lines, one question, one reply — and the record starts arguing on your side before anyone has decided to argue.

Key Takeaways

• A recap is shorter than a transcript and easier to check. The reader gets the shape of the conversation in ten seconds instead of forty messages.
• Four fields cover almost every dispute. What was asked, what you answered, when, and where it stands.
• Ask the guest to correct you. A correction early is cheap. A correction in a dispute reads as a contradiction.
• Timestamps come from the thread, not from memory. Copy them. Retyped times are the first thing that looks wrong.
• The original beats the copy. A screenshot is a picture of a conversation. The platform's own thread is the conversation.

Why a recap beats a transcript

A transcript is complete and useless at the same time. Forty messages, half of them one line, and the thing that actually matters — a request for a late check-out, an answer that said yes but not until four — is buried somewhere in the middle. Whoever reads it next is reading to find a decision, and a long thread hides decisions well.

A recap does the opposite. It says what was asked, what you said, and when. It's short enough that the guest will actually read it, which matters more than it sounds, because the point of the message isn't to build evidence. It's to agree on the facts while agreeing is still easy.

There's a second effect, and it's the one hosts underestimate. Sending a recap creates a timestamp of its own. If the guest replies "yes, that's right", you now have a conversation where both sides described the same week, in writing, on a date. If the guest replies "no, I asked for six", you've learned something you'd rather learn now than in a claim.

It also changes the tone of the thread, which is harder to measure but real. A guest who's been sending three messages an hour tends to slow down once someone has read their request back to them properly. Being understood is most of what they wanted.

The four fields worth capturing

The ask, in the guest's words. Not "requested early access", but something closer to what they wrote: "asked whether they could drop bags at eleven, before the listed check-in time". Quote the phrase when it's short. The guest should recognise their own request when they read it, and that recognition is what makes a recap credible.

The answer, in yours. The same discipline applies. "Told them yes for bags, no for the room." A recap that flatters your own response is a recap the guest will argue with, and you'll have lost the agreement you were trying to build.

The time on both. When the request came in, when you answered, and — this is the part people skip — how long the gap was in the guest's experience. A reply at 9am to a message sent at 11pm the night before is fast. It doesn't read that way to someone who spent the night waiting.

Where it stands. Done, not possible, or waiting on something. Not "we're looking into it", which tells the reader nothing and ages badly. If a part is still open, say what would close it and by when.

Then one closing line, and it's a question rather than a statement: "Have I got that right?" It costs nothing and it does two things. It invites a correction while the correction is free, and it puts a second writer on the record without asking the guest to agree with anything they didn't say.

Turning a thread into a timeline

A recap handles one request. A timeline handles the stay, and the two work together, because a claim is rarely about a single message. It's about a sequence: when the noise started, when you were told, what you offered, when someone came.

Keep one line per event, and keep it dull. "14:06 — guest reports no hot water." "14:31 — plumber called, arrival within the hour." "16:10 — guest confirms hot water restored." Dull is good. Dull is checkable.

Copy the times out of the thread rather than typing them from memory, and don't tidy the wording of anything you quote. If the guest wrote "the water is FREEZING", leave the capitals. A cleaned-up quote is the first thing a careful reader distrusts.

Then anchor the dates to the booking rather than to your recollection. Arrival day, in-house days, departure day — those are facts you can look up rather than reconstruct. A read-only question such as "who's arriving today, who's in house, who's due out" is exactly the kind of thing worth asking the system instead of your own memory at eleven at night.

localsbnb.com keeps Airbnb threads in one inbox and answers those read-only questions on arrivals, in-house stays and departures, so the dates in your timeline come from the booking and the words come from the thread. That's the whole split a claim needs.

One rule on screenshots. Take them, keep them, and treat them as a supplement. A screenshot is a copy of a conversation, and copies invite arguments about cropping that the original never has. Where the platform holds the thread, point at the thread first.

What a platform will actually accept

Different platforms read different things, and none of them publishes a scoring sheet you can optimise against. What they share is a preference for the original record: the conversation as it happened, on their own system, with their own timestamps.

That's why the recap is worth sending inside the thread rather than by email. An email with the same words is a document you wrote. A message in the thread is part of the record the platform already holds.

Send it once. A second and third version, each slightly tighter than the last, reads as coaching rather than recollection, and it hands the other side an easy point. If you remember something later, add it as a new line with its own date rather than editing the old one.

Be careful about what you claim to have done. If a plumber was booked but never came, the timeline says booked and not attended. The version where you imply the repair happened is the version that collapses the moment anyone checks, and a record that collapses takes the rest of your account with it.

And keep the outcome in perspective. A good record makes your side easier to understand. It doesn't decide the case, and it can't make a weak position strong. What it does is remove the most common reason hosts lose arguments they should have won: nobody could tell, afterwards, what had actually been asked.

FAQ

Won't a recap annoy the guest?

Usually not, if it's short and blameless. Four lines, no adjectives, one question at the end. What annoys guests is a summary that quietly assigns fault, and that's a writing problem rather than a reason to skip the message.

Should the recap go in a message or in the booking notes?

The message first, because the guest can reply to it. Then the same lines in the notes, so you can find them in three weeks without scrolling. The message builds the agreement. The note keeps it.

What if the guest's version differs from mine?

Then they've just corrected the record, which is what you asked for. Note the difference, don't argue it in the same message, and keep both versions with their dates. Two dated accounts are still far better than one undated memory.

Write it early, keep it short, and ask the question at the end. localsbnb.com is where the Airbnb thread and the stay dates sit side by side, which is most of what a four-line recap needs to be checkable.

---

This article is general guidance for hosts and isn't legal, tax or insurance advice. How a platform weighs a conversation, and what it will act on, differs by platform and changes over time. Confirm the current dispute process of the platform you use before you rely on any record.