Google Play reviews in Zendesk

Google Play rejects a developer reply longer than 350 characters. It is a hard limit in the API, spaces count, and a reply that goes over does not post. Most teams find that out by having one bounce.

That cap is the argument for automating the reply rather than against it. Three hundred and fifty characters is four sentences, and to “works fine since the update” it is the same four sentences every day. That is typing, not writing.

The draft comes from replies you have already posted: five to ten of them, matched on your brand, the reviewer’s language, the sentiment and whether the review had any text. It reads the replies you wrote on the store itself, not only the ones you sent through Reviewflowz.

The number lives in one place. The counter in the composer, the instruction the model writes to, the condense pass after it and the check on the way out all read the same 350, and the model is aimed at 320 so it rarely gets close.

The flow that opens tickets carries its own filter, in the same shape as the rule: the listings that feed it, the star rating, whether the review has text, the language. Point it at what your reply rules leave alone and your agents open a queue with nothing else in it.

That is worth doing because almost nobody who leaves a one-star also opens a support ticket. The review is the whole conversation and the developer reply is the only channel back to that person, so it has to arrive where your agents already answer people.

The subject carries the reviewer, the review id and the rating. The body carries the review in its own words, the listing, the date, and links back to it in Reviewflowz and on Google Play. The requester is a Reviewflowz contact rather than the reviewer, so nobody emails a customer by accident.

Only a public reply from an agent leaves the ticket. Internal notes stay internal, a comment from the requester goes nowhere, and the signature Zendesk appends is stripped before the reply reaches Google Play, where Google notifies the reviewer that you responded.

Google Play reviews come in the reviewer’s language, and the same bug reads completely differently in two of them. A one-star written in Hindi should be as easy to work as a one-star written in English, for whichever agent picks it up, rather than waiting for the one person who reads Hindi.

The ticket body always stays in the original. Pick a language for the flow and the translation arrives beside it as a private note headed “Translated review”. Only agents see it. It never reaches the customer and it never posts back to Google Play.

The draft is written in the reviewer’s language, from the replies you have already posted in that language. If you have never answered in Hindi it still drafts, and you can regenerate the same reply in another language before it goes out.

Every ticket is tagged with the review’s language, reviewflowz_hi, reviewflowz_pt, reviewflowz_de, so an ordinary Zendesk trigger sends each language to the agents who speak it.

Connect Claude or ChatGPT to Reviewflowz over MCP and the model reads across your Google Play reviews to answer the question the dashboard was not built for.

Three tools: list your review profiles, fetch reviews, get stats. Filter by rating, date range, keyword, language, topic, tag, or whether a reply has gone out. Stats come back as counts per star, average score and reply rate, with a daily, weekly or monthly series if you ask for one.

“What did the one-stars in the last week complain about, and which app version were they on.” A Google Play review arrives with the build the reviewer was running, which an App Store review does not, and Reviewflowz keeps it on the review. That is the difference between “ratings are down” and “8.4.2 broke checkout”.

The same tools answer the operational question. How many Google Play reviews from the last seven days still have no reply, which listing they sit on, and how many are about to fall out of Google’s answering window. Ask it on a Monday and you have your week.