The problem was not 'get more five-star reviews'
Public reviews have a selection problem. A friction-free trip gives a customer little reason to open an app store and write about it. A bad trip creates urgency. The small fraction of painful experiences can therefore occupy far more public attention than the much larger set of good or neutral trips, making the review surface look more negative than the underlying experience distribution and slowly damaging brand trust.
AIB-Tanisha was designed to give satisfied customers a low-friction opportunity to leave an honest app review. The word honest is the centre of the design. The agent could not ask for a particular rating, offer an incentive, hide criticism or keep pushing after hesitation. The objective was representation, not manufactured positivity.
This article is intentionally public-safe. It explains the engineering decisions and lessons without exposing customer data, proprietary prompts, internal identifiers, operational commands or confidential decision thresholds.
- ELIGIBILITYUse a recent positive-experience signal
- VERIFYAsk and listen for what the signal actually meant
- BRANCHSuppress the ask when feedback is mixed or negative
- REQUESTInvite one honest store review without a rating target
- CLOSEAccept refusal or hesitation and end cleanly
The eligibility signal could be wrong
A post-booking rating was useful but not sufficient evidence. A customer might have rated the host, the car or the handover—not Zoomcar's app or end-to-end platform. A high score could coexist with a payment problem or support complaint. Treating the number as permission to request a positive store review would be both a product mistake and a trust risk.
The call therefore began with verification rather than persuasion. Tanisha asked about the experience, listened for the subject of the praise and changed course when the answer revealed ambiguity. Eligibility selected a conversation; it did not predetermine its outcome.
Policy became a product constraint
Google Play prohibits manipulating ratings and reviews, including incentivised feedback and forced prompts, and advises developers not to ask customers to raise a rating. Apple prohibits review manipulation, requires its provided in-app review mechanism rather than custom in-app prompts, and treats repeated manipulative behaviour as a trust violation. An outbound call is a different surface, but those principles still define the safe product boundary.
So the agent never offered discounts, credits or support outcomes in exchange for a review; never specified a star rating; never framed refusal as a loss; and never repeated the ask after a clear no. If a complaint emerged, the review objective was suppressed. The agent could acknowledge the concern but could not invent a resolution, promise escalation or turn customer support into leverage.
A short state machine, not a long sales script
The final conversation had five states: continue from the fixed opening, verify the experience, acknowledge one useful detail, make a brief honest-review request when appropriate and close. The prompt described allowed transitions and forbidden actions. That structure was easier to test than pages of ideal dialogue.
Spoken turns stayed short because voice is interruptible. Persuasive context was reserved for one mild hesitation, not front-loaded into the opening. A clear refusal ended the request. A complaint moved the call away from persuasion. A goodbye was terminal; the model was not allowed to restart the loop with another question.
Language and interruption are part of correctness
Tanisha started in English, switched to Hindi when the customer did and used Hinglish when the customer naturally mixed both. It matched register rather than translating every sentence literally. Brand and app names remained stable, and acknowledgements stayed cautious when meaning was uncertain.
Interruption recovery was explicit. If the agent spoke over someone, it apologised, invited them to continue, listened and then resumed the unfinished state. An interruption was not treated as consent, completion or a reason to jump to the review ask.
Evaluation: test complete calls and uncomfortable cases
The evaluation unit was a complete call. The scenario matrix covered enthusiastic customers, terse answers, host-only praise, mixed platform feedback, complaints, suggestions, silence, repeated interruptions, language switching, hesitation, refusal and attempts to reopen a finished conversation.
Each run was judged on eligibility interpretation, phase order, whether the review ask should occur, rating neutrality, incentives, unsupported promises, pressure, language consistency, interruption recovery, turn length and clean termination. A fluent transcript failed if it asked the wrong customer at the wrong time.
What AIB-Tanisha taught me
The project produced a concise, versioned conversation policy and an adversarial test set. More importantly, it reframed the metric. The system should not maximise asks or positive reviews; it should maximise appropriate opportunities for genuine feedback while minimising pressure and misclassification.
Review systems are trust systems. The quiet majority deserves representation, but the customer owns the opinion. A good agent knows the difference between opening a door and steering someone through it.