How We Send Review Requests Reliably at Scale (RCS, SMS & Deliverability)

If you squint at a review platform, it's really a messaging system with a strong sense of timing. A request goes out at the right moment, a follow-up sends on schedule, and everything stops the instant a customer leaves a review. That sounds simple. Making it true — at volume, across different message channels, without ever double-sending or silently dropping a request — is where the engineering actually lives. This is an honest look at how we're building the sending side of RepSaaS, and why the boring reliability decisions matter more than the flashy ones.

The deliverability problem, stated plainly

Every review request has one job: arrive, look legitimate, and be one tap from the review form. Three things can stop that happening, and each one is a different problem:

1. The message doesn't reach the customer at all — a provider hiccup, an unreachable device, a transient failure.
2. The message reaches them but looks untrustworthy — a plain grey text with a bare link that people instinctively distrust.
3. The message reaches them twice — a retry that fired when it shouldn't have, so the customer gets pestered.

Good deliverability isn't one feature. It's the combination of choosing the right channel, sending it reliably, and making absolutely sure "try again" can never become "send again." We design for all three at once.

Channel: prefer RCS, fall back to SMS, automatically

The most common misconception about modern messaging is that you choose RCS instead of SMS. You don't. You send a message that prefers RCS — so it arrives as a verified, branded card with your business name, logo, and a tappable "Leave a review" button — and falls back to SMS, per recipient, whenever RCS isn't available on that device or carrier.

That fallback is the whole game. The right architecture isn't "RCS or SMS," it's "RCS then SMS," decided automatically for each customer, without anyone configuring it. Where a verified RCS message is the best available channel, that's what goes out; where it isn't, the request still lands as a dependable SMS rather than failing silently. My co-founder Lewis wrote about that tradeoff from the marketing side in RCS vs SMS for review requests; the engineering takeaway is that capability detection and graceful degradation have to be built into the send path itself, not bolted on as an afterthought.

Reliability: queue it, retry it, never lose it

The naive way to send a message is to call the provider's API directly and hope it works. At volume, that's a guarantee you'll eventually lose requests — a provider has a momentary blip, the call fails, and a review you should have collected just evaporates.

So we don't send directly. Every request goes through a queue. The send is a job; if the provider has a transient failure, the job is retried rather than dropped. Sending should be eventually reliable, not best-effort — a momentary hiccup with an external provider should never mean a lost request. The customer-facing promise is "requests go out at the right moment, every time, without anyone watching," and a queue with retries is what makes that promise hold when external services aren't always up.

Idempotency: why "retry" never means "double-send"

Here's the subtle trap. The moment you add retries, you create a new risk: what if the first attempt did succeed, the acknowledgement got lost, and the retry fires anyway? Now the customer gets two review requests, which is exactly the annoyance that erodes trust.

The answer is idempotency. Every send is keyed so that a retry can never produce a second message — the system can recognise "I've already sent this one" and safely do nothing. When you're sending at scale, you design so that "try again" is always safe by construction, not by luck. This is one of those decisions that's invisible when it works and catastrophic when it's missing, which is why we treat it as table stakes rather than an optimisation.

Timing and stopping

Reliability isn't only about the first message. A review flow is a small sequence: send at the moment of value, send one well-timed follow-up if there's no response, and — critically — stop the instant the customer leaves a review. That stop condition is as important as the send. Nothing makes a business look more careless than chasing a customer for a review they already left.

So the timing engine and the stop logic are part of the same reliability story. The sequence has to be precise about when it sends, disciplined about how often, and immediate about when it ends. A single missed message shouldn't mean a lost review; an already-collected review should never mean another nudge.

Doing this per tenant, under each agency's brand

There's a multiplier on all of this that's specific to a white-label platform: we're not running one sending pipeline, we're running it for many agencies, each with many clients, and every message has to carry the right brand. The verified sender profile, the business name and logo on an RCS card, the sender identity on the fallback SMS — all of it is resolved per tenant, so a customer sees a message from the local business they recognise, never from RepSaaS. That isolation discipline is the same one we apply to data and billing; I wrote more about the architecture behind it in building RepSaaS on Google Cloud. And the deliverability of those branded requests is what feeds everything downstream — they route customers straight to the right review form, including a client's connected Google Business Profile.

The honest bottom line

There's no secret sauce here, and I'm wary of anyone who claims one. Reliable review-request sending is a handful of unglamorous, well-understood engineering choices applied consistently: prefer RCS and fall back to SMS automatically, queue every send and retry on failure, make every send idempotent so retries are safe, and be precise about timing and stopping. Do all of that, per tenant, under each agency's brand, and the user-facing result is the simple thing they actually wanted: requests that go out at the right moment, every time, and actually arrive.