Feedback Requests: Private Feedback Before Public Reviews
Written By Chad McGuire (Sparrow Intel)
Overview
Public reviews are downstream. Feedback Requests sit upstream — reaching guests after checkout, collecting private feedback first, and routing the result intelligently. Happy guests get nudged to post publicly (especially on Google Business Profile, where the rich-get-richer effect on review volume is real). Unhappy guests get a path back to your team before they post.
This lesson covers what Feedback Requests are, the two-tab UI at /feedback-requests, the two patterns that matter, and how to brand the experience so it doesn't read as automation.
What a feedback request is
A feedback request is an automated message — sent via email or as a message on the guest's OTA — that asks the guest a small set of questions about their stay. Their answers come back into Sparrow Intel as a private signal, separate from anything public.
You configure when feedback requests go out (by rule), what they look like (branded with your logo and colors), and what happens with each response (auto-copy positives to OTAs, escalate negatives to your team).
This is the single highest-leverage growth tool in Reputation Management. Teams using it well see:
More public Google reviews — because the request can include a one-click link to leave a Google review for 5-star private feedback
Fewer surprise negative reviews — because the unhappy guest tells you privately first
A real internal feedback corpus — for properties that don't get enough public review volume to know how they're doing
The two tabs
Open Feedback Requests and you'll see two tabs:
The Rules tab is where you set the system up. The Sent tab is where you confirm it's working and inspect individual cases.
A rule, in plain language
A typical feedback request rule looks like:
Trigger: 24 hours after guest checkout
Conditions:
Reservation status = Completed
OTA = Airbnb OR Booking.com OR Vrbo OR Direct
Property group = "Lake District properties"
Send: Branded feedback request email
On response:
If overall rating = 5 stars → auto-copy to OTA review (where supported) and offer Google review link
If overall rating ≤ 3 stars → create a Conversation thread for the support team to follow up before any public review posts
The rule does three things in one configuration: collects the feedback, routes positives to public review surfaces, and intercepts negatives for human handling.
The two patterns that matter most
Pattern 1: Grow your Google review count
This is the one that pays off hardest for direct bookings and listings where Google visibility matters.
The flow:
Rule sends a feedback request 24h after checkout
Guest rates the stay 5 stars in the private form
Sparrow Intel includes a Google Business Profile review link in the thank-you screen
Guest who already gave 5 stars privately is far more likely to follow through publicly
Teams that wire this up typically see Google review volume multiply within a quarter — without paying for ads or touching any other channel.
Pattern 2: Intercept negative feedback before it posts
The opposite end of the same flow:
Rule sends the same feedback request
Guest gives 2 or 3 stars and writes a complaint
Sparrow Intel opens a Conversation thread (or creates a task) routed to your support team
Your team reaches out, resolves the issue, and — when the public review window opens — has already changed the narrative
This works best when paired with Review Predictions (next lesson), which flags many of the same at-risk stays before checkout even happens.
Feedback during the stay, not just after it
Everything above reaches the guest after checkout. That's the right moment to grow your review count and intercept the reviews headed for a public surface — but by then the stay is over. Whatever went wrong has already happened, and the best you can do is manage the fallout.
A post-check-in feedback request flips the timing. Instead of asking "how was your stay?" once it's too late to change the answer, it asks "how's everything looking so far?" while the guest is still standing in the unit — and while your team can still do something about it.
This is the difference between saving the review and saving the stay. A cold unit, a missing set of towels, a lockbox code that didn't work, a noise issue from the unit next door — caught four hours in, every one of those is a quick fix and a grateful guest. Caught at checkout, it's a 3-star review you're now playing defense against.
What it looks like
It's the same engine as a post-checkout request — just an earlier trigger. Instead of firing 24 hours after checkout, the rule fires a few hours after check-in.
In the Schedule Request row, set the request to go out a small number of hours after check-in (4 is a good default — early enough to matter, late enough that the guest has actually settled in and formed an impression).
One built-in guardrail is worth knowing: a request scheduled to send after check-in will never be sent after check-out. On a one-night stay or a short turn, the system simply suppresses it rather than pinging a guest who's already on their way out. You don't have to build separate rules for short stays — the scheduler protects you automatically.
Why the configuration is different
Moving the request upstream changes two things about how you set it up.
No external-review redirect. The "if a guest gives 5-star feedback, send them to leave a public review" option is intentionally disabled for check-in requests — it's only available on after-checkout rules. That's by design. A guest four hours into their stay has nothing to review yet, and asking them to post publicly mid-trip is premature. The goal of a check-in request isn't a review. It's an early signal. Leave the redirect set to No.
Diagnostic fields, not review-mirroring fields. A post-checkout request often collects the full set of OTA sub-ratings because it's feeding public surfaces. A check-in request should collect the fields that tell you whether something needs fixing right now. Overall Rating, Check-In Rating, and Cleanliness Rating plus a free-text box are usually all you need — they surface the issues you can still act on while the guest is in the door.
A rule, in plain language
Trigger: 4 hours after check-in
Method: OTA message (through your PMS)
Fields: Overall Rating, Check-In Rating, Cleanliness Rating,
Text
On response:
- Low or negative rating → open a Conversation thread for the support team to reach out immediately, while the guest is still on-site
- High rating → no action needed; log it as an early positive signal
External review redirect: No (collect the stay signal, not a review)The payoff lives entirely in the low-rating branch. When a guest flags a problem four hours in, your team has the rest of the stay to resolve it — and a guest whose AC got fixed the same afternoon writes a very different checkout review than one who shivered for three nights and then told the internet about it.
The copy does the real work
A check-in request that reads like a survey gets ignored. One that reads like a host checking in gets answered. The message should sound like a person who genuinely wants the stay to go well — and it should make the ask feel weightless:
Hi {Guest.FirstName}, welcome! We hope check-in went smoothly. If you have 30 seconds, we'd love a quick note on how everything's looking so far — it helps us make sure your stay is perfect. Just use the link below, and enjoy!
Two details in that template earn their place:
The framing is "so far," not "your stay." It signals you're asking early because you can still help, which is exactly the impression you want a guest to have.
The reassurance line at the bottom — a short note that this is an automated message, and that if they've already flagged something, the team is already on it — keeps the request from feeling like the left hand not knowing what the right is doing. A guest who reported a problem an hour ago shouldn't get an upbeat "how's everything!" that reads as if no one was listening.
Save this as its own template (e.g. Feedback Request (Check-In)) so it stays distinct from your checkout copy, and brand it the same way — logo, colors, sender name — so it lands as a message from your team, not a vendor.
When to use it
Run a post-check-in request when:
The stay is long enough to fix things. It earns its keep most on 3+ night stays, where there's runway to resolve an issue before checkout. (The short-stay guardrail handles the rest for you.)
Self-check-in is the norm. When no one greets the guest at the door, the check-in request becomes the moment you'd otherwise be missing — a structured "did everything work?" in place of a handshake.
You want your post-checkout reviews to start higher. A property running check-in requests is quietly resolving the exact problems that would otherwise show up as deductions later. The two patterns stack: catch it during the stay, and the after-checkout request has far less to intercept.
Pair it with the post-checkout flow and you've covered both ends of the trip — one request to fix the stay, one to capture it. The check-in request is the one that changes outcomes; the checkout request is the one that banks them.
Branding the request
A feedback request that looks like a generic survey gets ignored. Sparrow Intel lets you customize:
Logo and brand colors — set once on the Brand Settings page; every feedback request picks them up automatically
Sender name and reply-to address — so the request looks like it comes from your team, not from a vendor
Subject line and intro copy — set the tone
Spend 10 minutes on this. Open-rate and response-rate both lift meaningfully when the email looks like you.
See How to Use Feedback Requests for the configuration walkthrough.
Where Conversations and Feedback Requests overlap
If your team uses Conversations, there's one rule already documented on that side worth knowing about: "Skip sending message if guest left a review." This stops your post-stay automation in Conversations from nagging a guest who's already done what you wanted them to do.
The Feedback Requests rule and the Conversations skip rule are sibling controls — together they make the post-stay flow polite and quiet on guests who've already engaged.
A workflow that scales
Once Feedback Requests are running:
Weekly — scan the Sent tab to confirm requests are firing and responses are arriving at a reasonable rate
Monthly — review the response breakdown by rating; if a property is over-indexing on 3-stars, that's a real signal
Quarterly — refresh the email template; refresh the brand colors if anything has changed; review the auto-copy and escalation rules
For larger operations, designate a "Feedback Request owner" — someone responsible for the email template, the open-rate trend, and the rule edits as your operation changes. Without one, the flow gets stale and the open rate quietly drops.
Up next
Review Predictions: Acting Before Reviews Post — Feedback Requests reach out after checkout. Predictions tell you something even sooner.