Internal Support Policy

The named inbox, the response-time targets, and the routes for refunds, trial disputes and data-rights requests — for three apps that are not yet released.

This document is different from the other five: it is not mostly a legal question, it is an operational commitment, and the only thing that makes it true is a person reading an inbox. The suite's monetization standard requires a support path shipped in the first phase — refunds, trial disputes, data-rights requests, a named inbox and a response-time target.

The response times below are placeholders and must be set by whoever will actually answer. A published target that is missed is worse than a longer one that is met — and for the Art. 12(3) deadline it is not merely worse, it is a breach with a date on it. Do not tighten these numbers to look responsive.

1. The inbox

What already exists, stated as fact and not as a substitute. This site publishes hello@infoash.de as the company's general contact, and /contact states a 2–3 working-day target for non-urgent enquiries. That is a real, live inbox and a real, published target. It is not yet a support path for these three apps, because it is not named in any of these documents, it has no routing for rights requests, and it carries no per-app volume. Two lawful options:

1. Reuse it, extending the existing published target to cover these apps explicitly and adding rights-request routing behind it.
2. Create a dedicated inbox per suite or per app.

2. Response-time targets

The distinction that matters and is routinely blurred: the commercial targets are promises we choose. The Art. 12(3) month is law. Missing the first is a bad review; missing the second is a breach, and the clock starts when the request arrives, not when someone notices it. Any inbox arrangement that can let a message sit unread for a month is not fit for purpose regardless of what this table says.

3. What support does not do — cancellation

Support never cancels a subscription, and is never the route to cancel one.

Cancellation is one tap, inside the app, through your platform's native subscription controls. The monetization standard forbids "contact support to cancel" by name; the terms commit to no retention flow.

If someone emails asking to cancel, the answer is the shortest possible route to the native control, with no offer, no discount and no "before you go". A retention pitch delivered by email is the same dark pattern as a retention screen, and it also runs into § 312k BGB, which requires a cancellation route of equivalent prominence. Support may explain where the control is. It may not stand between the user and it.

Same for deletion: point at Settings → Delete everything. Do not require an email; do not add a step.

4. Refunds

Apple and Google are the merchant of record. We cannot issue a store refund, cannot reverse a charge, and cannot see payment details.

What we do:

• Explain the store's refund route accurately and give the current link for the user's platform.
• Support a request without obstructing it. If a store asks whether we object, we do not object as a matter of course.
• Where a refund is granted, the entitlement is revoked through the subscription layer — part of the webhook gate that must be observed end-to-end on both stores before launch.
• Log every refund reason. A pattern of "I didn't know the trial would charge me" is not a support problem, it is a paywall-disclosure problem, and it is the earliest available warning of a ROSCA-shaped exposure. Route it to whoever owns the paywall copy, monthly, as a standing item.

What we do not do: promise a refund we cannot deliver, or tell someone they are not entitled to one. Both are the store's call, and asserting either is a claim we have no standing to make.

5. Trial disputes

The three that will actually arrive, with the honest answer to each.

"I was charged and I didn't realise the trial converted."

The mechanics are: 7-day trial, payment method required up front, converts automatically unless cancelled, and a reminder on day 5 — two days before any charge. Confirm whether that reminder was actually delivered to that user. If it was not, that is our defect, and it is a support-supported refund request, not a user error.

"I already used a trial and can't get another one."

Trials are once per store account. It is a platform rule we cannot vary, it applies across multiple profiles inside the app, and deleting your data and signing up again does not reset it. This has to be said the same way here and on the deletion confirmation screen.

"I paid for the reading or report and lost it."

All three apps sell a one-time non-consumable. Restore purchases is the answer, and it must recover the entitlement end-to-end on a second device or after reinstall, on both stores — phrased behaviourally, because verifying the affordance renders is not verifying the entitlement recovers.

6. Data-rights requests

7. What support is not allowed to say

Support replies are user-facing copy and route through the claims gate like everything else. The gate has no support exemption, and a one-to-one email is where an unreviewed claim is most likely to be written, because it feels private and it is written under time pressure.

• Never describe the product as AI-powered. The engine is a deterministic weighted rules engine over reviewed content banks. This is mechanically blocked in the lint; it must not be reintroduced by a human typing a reply.
• No medical, psychiatric or physiological claims, and none of the blocked constructions — including "healing crystals", "healing energy", and any verb acting on a chakra, an energy field or a body system. A chakra is a label on a stone, never something the product operates on. These are blocked in a support reply exactly as in a store listing.
• No guaranteed outcomes, no prediction stated as fact, no claim that a reading is correct or will come true.
• Transactional and billing copy is plain language and exempt from the product's voice layer. A refund email written in the product voice is both confusing and, on a payment matter, a real problem.
• No promises about future features with dates, especially on the birth-time and geocoding paths that two of the apps defer.
• Never argue with a bug report. If the evidence and our belief conflict, the evidence wins and it gets investigated.

Macros for the recurring cases are drafted once, reviewed once through the gate, and then reused. Freehand replies are how blocked phrasing gets back in.

8. Escalation and volume

• One person answers, with a named backup for absence. ⚠ Both are placeholders.
• Anything alleging harm, involving a minor, or alleging that content was taken as medical advice escalates immediately and is logged. That last category is the direct early-warning signal for the net-impression exposure the claims gate exists to manage — if users are reporting it, the disclaimer is not curing it, and a disclaimer never cures misleading copy anyway.
• ⚠ Support volume is a real cost of three simultaneous launches under one inbox and it is not currently in any plan's schedule. Not estimated here — flagged so it is not discovered at launch.

9. Before this is published

• Inbox decided: reuse hello@infoash.de with extended scope, or create a dedicated address
• Inbox created, monitored, and tested with a real message that gets a real reply
• Named person and named backup assigned
• Response targets set by that person, not by this document
• Rights-request routing exists and the person behind it knows the Art. 12(3) clock
• Address inserted into the privacy policy, the terms, the Impressum, the Article 13 notice and the deletion policy — all five blockers close together or none of them do
• Store listing support URL and support email fields point here
• DPDP grievance officer named, if the India storefront ships
• Reply macros drafted and passed through the claims gate

10. Contact

Infoash UG (haftungsbeschränkt) · [registered address] · [support inbox — PLACEHOLDER]