How to reach us, how fast we aim to respond, and what we do when something breaks. This is a statement of how we operate — read the last section for what it deliberately does not promise.
Green Package Pro LLC · Version 1.0.0 · Effective August 4, 2026
Email [email protected]. Clients can also raise an issue through the client portal. There is one route to a human either way — we do not operate a tiered queue that has to be escalated through.
We are a small team operating across time zones from Thailand and the United States. In practice that means good coverage across most of the day and slower nights and weekends.
These are the targets we hold ourselves to, measured from when a report reaches us to when a human responds — not to when the issue is resolved.
| Severity | What it means | We aim to respond within |
|---|---|---|
| Critical | The service is down, or an assistant is answering no one. Nobody can work around it. | 4 hours |
| High | A major function is broken or answers are materially wrong, but there is a workaround. | 1 business day |
| Normal | Something is wrong but the service is usable — a display issue, a configuration question. | 3 business days |
| Low | A question, a feature request, or a cosmetic issue. | When we can, and we will tell you if the answer is “not soon”. |
Security reports follow a separate track with its own targets, set out in the Vulnerability Disclosure Policy.
Most changes ship without any interruption at all. Where a change genuinely requires downtime, we schedule it outside business hours in the client's primary time zone and give at least 48 hours' notice by email. Emergency maintenance — a security fix that cannot wait — may happen without notice, and we will tell you what happened afterwards.
During an incident affecting clients we will tell affected clients what is happening rather than waiting until it is fixed, keep updating while it is ongoing, and follow up afterwards with what went wrong and what we changed so it does not recur. We would rather send an unflattering explanation than a vague one.
The service depends on external AI model providers, hosting, and network infrastructure, all listed in Subprocessors. When one of them has an outage, we work around it where we can — routing across several model providers means one provider failing is usually survivable — but a hosting or network failure can take the service down regardless of what we do. We will tell you when that is what has happened rather than implying it was something we chose.
This is not a service level agreement. We do not promise a specific uptime percentage and we do not offer service credits.
The reason is straightforward: we do not yet publish a status page or retain the independent measurements that would let you verify such a promise. Publishing a number we cannot evidence would be a claim you have no way to check, and this site's standing rule is that a claim without a measurement behind it does not get published.
If your business needs a contractual uptime commitment with credits, tell us during procurement. It is a reasonable thing to need, and we would rather negotiate it deliberately than have you assume one exists. Your rights if the service fails are otherwise governed by the Terms of Service.
Every published version of this document. The full corpus history is at changelog.
| Version | Effective | What changed |
|---|---|---|
| 1.0.0 | August 4, 2026 | Initial publication. Sets support response targets and incident communication. Deliberately states no uptime percentage and offers no service credits — see the note on that page. |
Questions about this document? Email [email protected].