White-label app-review replies: put your agency's brand on it

If you manage app reviews for clients, the tool you use should read as yours, not as a third party your client could have hired directly. White-label makes that true on two fronts that clients actually notice: the product chrome carries your logo and your product name instead of Reply Argus, and the emails your clients receive come from your own verified sending domain instead of a generic sender. Underneath, every client runs as its own isolated workspace, so one client's voice, rules, and knowledge never bleed into another's.

This guide covers what white-label replaces, how the verified-domain sending works and why it fails closed until you prove the domain, how per-client isolation is structured, and how team roles and seats fit an agency that adds and removes people as engagements start and end.

Two things carry your brand where clients see it. First, the app chrome: your custom logo and your product name replace the Reply Argus branding, so a client logging in, or a screenshot in your monthly report, shows your brand rather than a vendor's. Second, and more consequential, the customer-facing emails go out from your own sending domain once you have verified it. A notification that arrives from your agency's domain reinforces that the client hired you; one from an unfamiliar sender invites the question of who that is.

The domain step is the one to get right, because it fails closed. Until your sending domain is verified, emails fall back to the default sender rather than spoofing an unverified address. That is deliberate: sending from an unverified domain is how you land in spam folders and damage deliverability for everyone. Verify the domain and the fallback lifts; until then your clients still get their emails, just from the safe default.

Isolation is the part that makes white-label safe to run at scale. Each client is its own org: a separate workspace with its own brand-voice profiles, its own do-not-say rules, and its own knowledge base. One client per org is the model, and it is not just cosmetic separation. Cross-org reads are scoped in code, so a person or process working in one client's workspace cannot see another's data. When you switch between clients you switch active org, and everything (apps, reviews, voice, rules, knowledge) switches with it.

This matters because agency clients are often competitors, or at least would never want their tone-of-voice guide, their banned-claims list, or their product knowledge visible to another company you also serve. Keeping each client in its own org means that separation is structural, not a policy you have to remember to enforce.

Agencies churn people through engagements, so roles and seats are built for that. The ladder is owner, admin, publisher, drafter, and viewer. An owner handles billing and ownership; an admin configures the workspace and manages teammates; a publisher drafts and publishes replies; a drafter can draft but never publish, which is ideal for a junior who should not push to a client's store unreviewed; and a viewer is read-only. Seats are bundled with the tier rather than sold per head, and viewers do not consume a seat at all, so you can give a client stakeholder read-only visibility into their own workspace for free.

The drafter role is the one agencies underuse. It lets you put new or contract staff to work generating replies without ever risking an unreviewed reply going live on a client's public listing. Publishing stays with the people you trust to publish, while the drafting volume can come from anyone.

White-label is available on the Studio tier. It bundles the custom logo and product name, verified-domain sending, per-client org isolation, and the full role ladder with included seats and free viewers. The model is one org per client, which is what keeps each client's voice, rules, and knowledge cleanly separate.