Seven support cases,step by step

What the operator asked for

A member named after the marketplace, with the bio “Official … Support”, showed a verified badge five minutes after signing up and contacted a real seller. A member reported it; the operator banned the account 36 hours later. The question, pasted into a support case on the day the marketplace was connected: how did they get verified, what did they do, and are there other accounts like this?

The problem

What Empavision did, step by step

1. 1

   The case, as the operator asked it

   Pasted as written, with the member’s name and email. The marketplace had been connected to Empavision the same morning.

   

2. 2

   The first answer: the facts right, the case missed

   “They are verified, but Empavision cannot show how.” Every fact about the account was correct and cited, and it said plainly what it could not see. But it had no history from before the connection, never looked at what the account did, and searched for look-alikes on the incident day only. Its plan pointed at staff tools: the wrong direction.

   

3. 3

   What was fixed in Empavision, the same day

   Connecting a marketplace now also stores its last 90 days of change history, without replaying it. The change history says who wrote each change: the member’s own session or the operator’s tools. Before the report says who set a flag, a new check compares that member’s write with every other member’s write of the same flag. A new step lists everything a member did through transactions. Look-alike searches cover the whole marketplace, strongest matches first, and long result lists are no longer cut short before the report is written.

4. 4

   The same question, asked again

   “The badge appears to be app-set, not manually granted.” The report compared this account’s badge write with every other member’s: the same member-session source as 209 writes across 177 members, seconds after an email is confirmed or a payment account is created, so the marketplace’s own app granted it. The real seller this account targeted got her badge the same way. The impostor confirmed its email, created a payment account without finishing the identity checks, and the app granted the badge 14 seconds later. It then opened three enquiries, 25, 26 and 27 minutes after sign-up, all to one seller on one listing, with no message in any of them.

   

5. 5

   The look-alikes, by name

   A second account built from the marketplace’s name, created two months earlier and never banned, plus the marketplace’s own shop account. Schools and clubs came up for staff words like “team”; the report lists them for review and does not call them abusive.

   

Verified after

• ✓Checked against the marketplace’s own event log, read independently: the flag was written from the member’s session at the second the report gives, the same way and after the same trigger as for every other member, and the three enquiries carry no messages.
• ✓First answer in 2 minutes, the answer after the fixes in under 2 minutes, both on a marketplace connected the same day.

Empavision features used

What the operator asked for

A homeowner wrote that her upcoming housesit and the messages with her sitter had disappeared, and asked whether the latest update had wiped data. The operator pasted her words and five WhatsApp screenshots into a support case.

The problem

What Empavision did, step by step

1. 1

   The screenshots were read, as claims

   One vision pass transcribed the names, emails, user id and dates in the pictures. They entered the investigation as operator-pasted values to check, never as evidence.

2. 2

   Two accounts for the same homeowner

   One created in 2025 on one email address, one in 2026 on another. The screenshots showed the older one.

3. 3

   The booking bound to the newer account

   The transaction’s provider id pointed at the 2026 account. The change log held no deletion events.

4. 4

   The answer, and a one-step plan

   “Data loss not observed; housesit linked to a different account.” Both accounts side by side, the newer one marked recommended. The plan: one decision step, tell the member which account to sign in with, plus a drafted reply. A later run proposed deactivating the unused account as a reversible step.

   

Verified after

• ✓Matched a hand investigation (mirror queries plus the Integration API) point for point.
• ✓2.0 minutes as text, 2.2 minutes with the five photos.

Empavision features used

What the operator asked for

A member who had never completed checkout saw “incomplete_expired” and a Cancel button on her subscriptions page, with no way to renew.

The problem

What Empavision did, step by step

1. 1

   One ticket, then a count

   The investigation traced the state to the unpaid subscription. A count against the mirror showed 602 members on the live marketplace in the same state.

2. 2

   The fix on the marketplace’s own page

   The subscriptions page now states the membership in plain words, always offers “Choose a plan” when nothing is live, and shows never-paid or ended objects as history with no actions. Deployed by the marketplace’s developer.

3. 3

   The mirror became event-driven

   Stripe subscription events now update Empavision’s copy within a second; the nightly run stays as reconciliation.

Verified after

• ✓Recorded test on the dev marketplace, then live: a test subscription created, updated and cancelled was mirrored within one second of each event.
• ✓The live page served the new state the same morning.

Empavision features used

What the operator asked for

In the Copilot: “give me a list of expired homeowners”.

The problem

What Empavision did, step by step

1. 1

   The cause, from the stored query

   Every Copilot answer keeps the query it ran. This one filtered on account state, which no expired member has.

2. 2

   Membership words now mean membership

   On a marketplace with a Stripe subscription mirror, “expired”, “lapsed”, “cancelled”, “not renewed” resolve against Stripe’s own statuses through the member’s most relevant subscription. On a marketplace without the mirror they fall back to marketplace fields, and the answer says which.

Verified after

• ✓The same question in the real chat returned 149 members, answered from Stripe and the marketplace together, with an export.

Empavision features used

What the operator asked for

A member had two accounts. Her paid membership and her billing were on the one she no longer used. Move them to the account she keeps.

The problem

What Empavision did, step by step

1. 1

   The investigation found both accounts and the Stripe customer

   With the dates of each membership read from Stripe, not from the marketplace’s copy.

2. 2

   The first attempt refused a step it could not verify

   The step did not pass the live pre-check, so nothing was written. The pre-check was fixed, the case re-run.

3. 3

   Billing email changed, entitlement copied

   Each step shown as before → after in the approval modal and applied with a receipt. A follow-up turn corrected the entitlement step; it was re-applied once a writer fix landed, with the stored value now the right type.

   

Verified after

• ✓Billing email verified live on Stripe after the change.
• ✓The entitlement on the kept account, with correct types and dates, all audited with receipts.

Empavision features used

What the operator asked for

“Duplicate account — can I cancel this £89 subscription, or will it affect her live account?”

The problem

What Empavision did, step by step

1. 1

   Who is who, with dates and amounts

   The investigation listed every subscription on the customer with its start date and amount, instead of trusting the “duplicate” label.

   

2. 2

   The remedy

   Cancel the £89 at period end, keep the £129. A refund of the latest £89 charge left as the operator’s decision, with the amounts in front of her.

   

3. 3

   What else was in the data

   Dead twin subscriptions from double-fired checkouts, raised with the operator rather than silently cleaned.

Verified after

• ✓The same situation was cloned onto the dev marketplace (role-neutral names, real dates) and the investigator’s answer is checked automatically before every change to it: who is who with dates and amounts, and the money step bound to the right subscription.

Empavision features used

What the operator asked for

In a support case on one member's account, the operator had approved a plan step: set the member's paid membership to run until 4 March 2027.

The problem

What Empavision did, step by step

1. 1

   The writer was fixed first

   Only text shaped like a JSON array or object that actually parses is decoded; plain values are left untouched.

2. 2

   The case was reopened from the case list

   The whole thread reopens from its list row: the operator's original request, the investigation, the plan and their history.

3. 3

   The stored plan step still offered “Review & apply”

   The record was repaired by re-running the same approved step from the same stored report. No new values, no hand-written SQL.

4. 4

   The approval modal: before → after, and the guarantee

   The operator sees the field, the current value and the new value before approving, and the line “Reversible — creates rollback receipts”.

   

5. 5

   A reason, recorded on the audit receipt

   Optional, but kept with the receipt, so the audit trail says why, not just what.

   

6. 6

   “Applied 1 change across 1 user”

   The plan step is marked applied, with the exact before → after value and “Reversible — backup saved”.

   

Verified after

• ✓The stored type of the membership field is now an array, with one entry: status “active”, end date 4 March 2027, payment gateway recorded.
• ✓The membership level label and the skip-check flag are intact.
• ✓The rollback payload captured the real prior value (the string), so the change is genuinely reversible.

Empavision features used