How to write an app review reply playbook
A reply playbook is a short document that everyone who answers your app reviews works from. It lists where to send people for help, the approved wording for known issues, how your team sounds, and what nobody promises in public. Write it once, keep it to a page or two, and update it after every release.
Each reply is still written to the review in front of you. The playbook holds the facts and the limits, so five people answering on two stores give the same true answer in the same voice.
Why do review replies need a playbook?
Review replies need a playbook because several people write them, in public, to customers who get notified.
- Replies reach the reviewer. On the App Store, “the reviewer is notified and has the option to update their review” (Apple). On Google Play, the reviewer gets a push notification and an email.
- More than one person replies. In App Store Connect, the Account Holder, Admin and Customer Support roles can all respond, and “you don’t need to be the person who wrote the response to edit it” (Apple).
- Both stores have rules for what replies say. Google asks for replies that address the user’s comment “in a clear, valuable, and truthful manner” (Google). Apple asks you to keep responses “targeted to the user’s comments” with no personal information, spam or marketing (App Review Guidelines 5.6.1).
Without a shared page, each person fills the gaps from memory, with an old support address or a fix date someone mentioned in a meeting. The tone drifts too, from friendly to defensive by Friday afternoon.
Why not just use reply templates?
Templates make replies consistent by making them identical, and readers notice. On the K-9 Mail forum, one user described a navigation app that constantly replied to negative reviews with “Your opinion is very important to us. To better help you, please contact us at…” and said that “seeing this reply all over the place seems dishonest” (K-9 Mail forum).
Apple’s guidance points the same way: “when possible, we recommend personalizing your responses rather than using generic responses for similar reviews” (Apple).
A playbook keeps the parts that should be identical (the support address, the status of a known bug, the things you never say) and leaves the sentence itself to the person replying.
What goes in an app review reply playbook?
An app review reply playbook needs seven sections, and most teams can fill in a first version in an afternoon.
| Section | What it answers | Example entry |
|---|---|---|
| Voice | How do we sound? | “Plain and warm. First person plural. No exclamation marks.” |
| Support channels | Where do we send people? | “Login problems: [email protected]. App Store billing: Apple Support.” |
| Approved statements | What’s true right now about known issues? | “Sync bug in 4.2: fixed in 4.2.1, rolling out this week.” |
| Never say | What’s off limits in public? | Refund promises, fix dates, admissions of fault, personal data |
| Hand to a person | Which reviews skip the playbook? | Refunds, hacked accounts, data requests, legal threats |
| Length and format | How long, what format? | “Under 350 characters, plain text, no links unless listed here.” |
| Languages | What if we don’t speak it? | “Reply in English; Google Play shows users a translation.” |
Voice
Apple’s advice is to “strive for a friendly tone that’s consistent with the voice of your brand” (Apple). Turn that into three or four lines a new teammate can follow: how you greet, whether you sign off with a name or the team, words you use and words you avoid. One good reply and one bad reply, side by side, teach more than a paragraph of adjectives.
Support channels
List each kind of problem and where it goes, and keep this section the most current: it ends up in nearly every reply. If people keep using reviews as a help desk, consider a Hacker News commenter’s diagnosis: “This probably means you’ve made your support system too hard to find/use” (Hacker News).
Some routes are set by the store, not by you:
- App Store billing and download problems go to Apple. Apple’s guidance is to “direct them to Apple Support” (Apple), and customers request App Store refunds from Apple (Apple Support).
- On Google Play, developers can refund orders themselves in Play Console, so a refund question goes to whoever handles orders on your team.
- Google’s reply notification email includes a link to contact you at the email address on your store listing (Google). If that address is an unread inbox, fix it before you point anyone to it.
If you use Play Console’s suggested replies, check their contact details too; Google says to update them on your Account details page.
Approved statements
These are the facts a reply may state about current issues, each with a date and an owner. “Known crash on Android 15 when opening the map. Fix in testing, no date yet. Checked 14 Oct by Sam.” The person replying writes their own sentence around the fact and doesn’t have to guess whether the fix shipped.
Remove a statement when it stops being true. An approved statement from two releases ago is how a reply ends up announcing a fix for a bug that has since come back.
Never say
The first four items come from the stores’ rules; the last covers commitments that can’t be taken back.
- No personal information about the reviewer or anyone else. Apple’s guidelines rule it out (Apple 5.6.1), and Google says not to include sensitive information about users, because replies are public (Google Play API docs).
- No marketing or promotion. Apple’s guidelines say not to include “spam, or marketing” in a response (Apple 5.6.1); Google’s policy says “don’t solicit or promote” (Google).
- No rewards for a better rating. Google Play’s policy is explicit: “Don’t offer rewards or incentives for ratings or reviews” (Google).
- No arguing. Google bans replies that are “abusive, hateful, dismissive” (Google). A misunderstanding can be corrected without an argument in public.
- No refund promises, fix dates or admissions of fault. These come from your team, not the stores: each one is a commitment someone else on your team has to keep, made before anyone has checked the order, the roadmap or the facts.
Hand to a person
Some reviews shouldn’t be answered from the playbook. Refund requests, possible account takeovers, personal data requests, legal threats, abuse and reviews from people with an audience need someone to look first. We covered the six reviews you should never auto-reply to in a separate post; the playbook only needs a one-line pointer to who owns each.
Length and format
Google Play’s reply API accepts “at most 350 characters”, and Google recommends plain text (Google Play Developer API). Apple asks for a response that is “concise and clearly addresses your customer’s feedback” (Apple). Keeping every reply under 350 characters of plain text fits Google Play’s limit, matches Apple’s ask for concise responses, and keeps replies readable on a phone.
Languages
Decide what happens when a review arrives in a language nobody on the team reads. Google’s own advice: “If you don’t have a native language speaker to reply to feedback in a particular language, reply in your native language,” and users can read a translation (Google Play). If you use machine translation to reply in the reviewer’s language, say who checks it.
What does a reply playbook template look like?
Copy it and fill in the brackets.
APP REVIEW REPLY PLAYBOOK — [App name]
Owner: [name] Last updated: [date] Next review: after [version]
1. VOICE
- We sound: [three words, e.g. plain, warm, brief]
- We write as: [we / first name] — sign-off: [e.g. "— Sam from the [App] team"]
- We avoid: [exclamation marks, "unfortunately", jargon, ...]
- Good reply: "[example]"
- Not like this: "[example]"
2. SUPPORT CHANNELS
- Account and login: [address or in-app path]
- Bugs and crashes: [address / in-app report]
- App Store billing or download problems: Apple Support
- Google Play orders and refunds: [who handles them]
- Account and data deletion: [in-app path + web link]
3. APPROVED STATEMENTS (each with date and owner)
- [Issue]: [what's true] — checked [date] by [name]
- [Feature request we hear often]: [what we can honestly say]
4. NEVER SAY
- Personal information about anyone
- Marketing, promotions, or rewards for a better rating
- Refund promises, fix dates, admissions of fault
- Anything that argues with the reviewer
5. HAND TO A PERSON
- Refunds and billing → [owner]
- Hacked or compromised accounts → [owner]
- Personal data requests → [owner]
- Legal threats → [owner]
- Abuse → report the review / [moderation owner]
- People with an audience → [owner]
6. LENGTH AND FORMAT
- Under 350 characters, plain text
- Links: only [list]
7. LANGUAGES
- We reply in: [languages]
- Everything else: reply in [language] / translated by [tool], checked by [name]What does a reply written from the playbook look like?
Take a 2-star review: “Since the last update my workouts don’t sync to my watch. Paying for premium and this is what I get.”
A template reply: “Thanks for your feedback. Your opinion is very important to us. Please contact [email protected].”
A reply built from the playbook above: “Sorry your workouts stopped syncing after 4.2. It’s a known sync bug, and 4.2.1 fixes it; it’s rolling out this week. If it still fails after updating, write to [email protected] and we’ll look at your account. — Sam”
Both fit in 350 characters. The second names the reviewer’s problem, states an approved fact, gives the right channel and promises nothing that isn’t already true. It’s also worth revisiting: when you ship a fix, Apple suggests putting it in your release notes and replying to the reviews that raised it (Apple).
How do you keep the playbook current?
Keep a reply playbook current by giving it one owner and a fixed review point: after every release, check the approved statements, retire the ones that are no longer true and add the issues the new version brought in. Check the support channels then too, since addresses and in-app paths change with releases.
When a reply goes out that the team wishes it hadn’t, add a line to “Never say” or “Hand to a person”, so the next person doesn’t repeat it.
We’re building Heedo around the same idea: you write the playbook once in plain text, Heedo drafts each reply from it in your voice, and a person approves the draft before it’s sent.