A reviewer may paste an email address, describe a payment problem or include details from a private support exchange. Your reply appears in a public place too. The first job is to help the person without repeating information that does not belong in the review thread.
Read for privacy before drafting
Separate the issue from the identifying details. You might need to acknowledge a sign-in problem, but you do not need to repeat the email address the reviewer used. Look for account identifiers, order details, phone numbers and information about other people before copying any text into a response.
Apple’s review-response guidance says to keep replies respectful and avoid personal information, marketing language and spam. If the review itself appears to violate store rules, use the store’s reporting process. A developer reply does not remove the original review.
Use a public acknowledgement and a private next step
A useful response states what you understood and tells the person how to reach your actual support channel. Verify that the channel works and that the support team can handle the request. Do not ask the person to post receipts, passwords or account details in another public reply.
For a hypothetical account-access complaint, a draft could be: “I’m sorry you’re having trouble signing in. Please contact us through the support link on our app’s store page so we can investigate privately. Please don’t post account details here.” Replace that route only with a real, verified support option.
Avoid confirming that you found a particular customer account or payment in a public response. You can address the reported problem without disclosing the outcome of a private lookup.
Check the app and platform before sending
When you manage several products, confirm the selected app and store. A support link for a different app creates another problem for the reviewer. Check whether a teammate already replied, and read the existing response before adding or changing anything.
In ReviewTower, use the app filter and review context to keep the response attached to the right product. Treat a private support handoff as an operational step for your team; do not assume the review dashboard automatically creates a support ticket.
Review AI drafts for copied details
If you use an AI reply draft or Polish, read the complete output before sending. A fluent draft can still repeat an identifier from the review or make an unsupported promise. Remove those details and check every statement about fixes, refunds or recovery against facts your team has confirmed.
- Does the reply repeat any identifying information?
- Is the support route correct for this app?
- Does it promise an outcome we have not verified?
- Can a reader understand the next step without sharing more information publicly?
Keep the handoff useful
In your approved internal support system, record enough context to help the teammate receiving the request. Keep private details out of the public reply and avoid moving them into unnecessary places. A short acknowledgement with a working next step is more useful than a detailed public investigation.
ReviewTower’s review workflow brings reviews into one workspace while leaving the final response under your control.
Sources and further reading
Reviewed October 21, 2026. Examples are hypothetical.