Customer feedback, ready for engineering review.

A prepared example from Reventure’s public reviews, with source evidence and QA checks.

Download Jira CSVfor import after mapping fields in your Jira

Prepared from public feedback. Current status to be checked against your backlog.

RVD-1Investigation draft

Verify paid access when home listings return "unauthorized"

Three reviewers, on both stores and across ten months, report that a paid subscription did not open the screens they expected. The most recent one names the message on the screen. Whether this is one fault, three unrelated account states, or a mix of the two is not observable from outside the product, so this draft is the check rather than the conclusion.

Action

Pull the subscription and entitlement state for these three accounts at the dates below, on both stores, and compare what the plan should grant against what the account was granted at that moment.

Evidence
“I paid for a subscription and the app will not let me look up home listings! It says unauthorized no matter what I do”
App Store, Aug 2026, v4.15
“none of the premium features that i tried accessing, are becoming available after paying the monthly subscription cost.”
App Store, Feb 2026, v4.6
“I paid for premium and 2 days later it says I need to pay for premium again.”
Google Play, Nov 2025, v43.1
Developer reply

“We reviewed your account and followed up with you directly, and our team responded within hours to assist.”

The reply says the account was reviewed. It does not say what was found, so the report stays open here.

Cases to test

None of them reproduced.

  • Purchase made on one store, then signed in on the other with the same account.
  • Entitlement resolved while the device is offline, then reconnecting.
  • Renewal inside a billing-retry grace period, which both stores treat as still subscribed.
2 more
  • A refund issued by the store, where access should drop and should not look like a failure.
  • An account created with a store sign-in on one platform and with an email address on the other.
Exit criteria

Any one of them ends the check.

  • The refusal is reproduced on a test account and the entitlement source that returned it is named.
  • Or the three accounts are shown to have been inactive on those dates, which turns this into a question about the message rather than about access.
  • Or the records are inconclusive, and the open question is recorded: which entitlement source was consulted at the moment the refusal was returned.
What would close this, link it, or change its priority

Closes, or links to an existing ticket, if the three purchase records show the subscription inactive on the review dates, or if a known incident already covers this message on those dates.

View as Jira API body
{
  "fields": {
    "project": {
      "key": "RVD"
    },
    "summary": "Verify paid access when home listings return \"unauthorized\"",
    ...

3 more in the CSV and the JSON export

RVD-2Confirm purchase channel and subscription state behind reports of billing after cancellation

Three reviewers believed they had cancelled and describe being charged afterwards. One of them offers a mechanism, a retention offer that has to be actively declined before the cancellation completes. That is one person reading the behaviour from outside, so it is the first thing to test and not a finding.

Action

For each report, establish where the subscription was bought and what state it was in at the time. Then walk the cancellation path once per channel and record where each one ends.

Evidence
“I thought I had canceled, but apparently that wasn’t the case because I didn’t decline a pop-up offer for a reduced rate.”
App Store, Jul 2026, v4.12
“Impossible to cancel the subscription they keep charging”
App Store, Apr 2026, v4.9
“not able to cancel”
Google Play, Dec 2025, v43.2

A cancellation route exists on the web app, which is where the walkthrough starts

https://map.reventure.app/cancel
Cases to test

None of them reproduced.

  • Leaving the retention screen by browser back, by closing the tab, and by the system back gesture.
  • Cancelling on the web a subscription bought in a store, and the reverse.
  • Cancelling twice, where the second attempt should be a no-op rather than an error.
2 more
  • Accepting the retention offer, then cancelling again the same day.
  • Cancelling while a payment retry is in flight.
Exit criteria

Any one of them ends the check.

  • A path is found where the flow ends without the subscription cancelled, and it is written down step by step.
  • Or every path cancels, and these reports trace to a store-side subscription that the web flow never governed.
  • Or the accounts cannot be matched, and the open question is recorded: which channel each of these three purchases came through.
What would close this, link it, or change its priority

Closes if every cancellation path completes when the retention offer is dismissed, and the three reports trace to a store-side subscription instead.

RVD-3Attempt to reproduce the Android startup freeze reported on 44.11

One Play review from August reports a freeze on 44.11, in a single word. Three older reports, from early 2025, describe the app closing shortly after launch, and a later reviewer writes that an update fixed that. Whether the August report is the same thing cannot be read from one word, which is what makes this a question rather than a defect.

Action

Read the crash and ANR rate for 44.11 against the versions either side of it, then attempt a cold start on a low-memory device on that version.

Evidence
“freezes”
Google Play, Aug 2026, v44.11
Developer reply

“We'd love to help get this resolved.”

Answered the same day. The exchange left the store, so what came of it is not visible here.

“App launches then shortly closes (in approximately 4 secs). App is inoperable on Android for my experience.”
Google Play, Feb 2025, v18.0
“Doesn't work. Always crash”
Google Play, Mar 2025
“it continually glitches itself closed on my Droid phone”
Google Play, Feb 2025
Counter-evidence
“New update fixed a previous issue on Android where it was repeatedly crashing when preparing and loading data during the app initiation.”
Google Play, Jun 2025, v36.5

A reviewer reporting a fix for the 2025 reports. It is why those three are listed as history rather than as open reports.

Cases to test

None of them reproduced.

  • Cold start on a low-memory device on the reported version.
  • First launch after install with no network.
  • The data-loading path named by the 2025 reports, which is where the earlier reports sat.
2 more
  • Rotating the device during initial load.
  • A build installed from a staged rollout that was later halted.
Exit criteria

Any one of them ends the check.

  • A reproduction on 44.11 with a trace attached.
  • Or the console shows no elevated crash or ANR rate on that version, and the August report is left recorded as unexplained rather than closed.
  • Or nothing reproduces, and the open question is written down: which device and Android version that report came from, which is the one thing the review does not carry.
What would close this, link it, or change its priority

Links to the 2025 startup reports only if a trace matches them. A higher version number on its own does not close it: the version on a review is what the reporter had installed, not a record of what shipped.

RVD-4Check how a store review is matched to an account before a public reply

Twenty of the seventy-eight Play reviews carry a public reply, so the answering is already being done. Two of those replies say the account could not be found from the name on the store, and the most recent one asks someone who has already described a problem to describe it again somewhere else. Nothing here says a reply was wrong. It says the person writing it had no handle on the account.

Action

List the identifiers a store review actually exposes, compare them against what the account system can match on, and write down which of them, if any, closes the gap.

Evidence
We couldn’t find an account under the username you entered
Developer reply on Google Play, Dec 2025
We couldn’t locate an account under this username
Developer reply on Google Play, Nov 2025
Please reach out to us at helpdesk@reventure.app so our team can investigate and assist.
Developer reply on Google Play, Aug 2026
Cases to test

None of them reproduced.

  • A reviewer who never created an account.
  • A store display name that differs from the account name, which is the case these replies ran into.
  • A review edited by its author after the reply: the sample contains one that was edited to say the issue had been fixed.
2 more
  • The same person reviewing on both stores.
  • A review with a rating and no text.
Exit criteria

Any one of them ends the check.

  • A matching identifier is found, and what it can and cannot resolve is written down.
  • Or no identifier exists, and the finding is that a public reply can only ever ask for an email address, which is worth knowing before anyone builds around it.
What would close this, link it, or change its priority

Closes if recent low-rated reviews already reach the help desk with an account attached, which would make these two replies the exception rather than the pattern.