Our /support page opens with the two places that answer before a person can, and then spends half its length on what we cannot do for you. We wrote it that way because a support page that only lists remedies describes a different product.
This post is why the page exists at all, why it points at the product before a mailbox, and the four limits it states up front.
The page existed because a form said no
The ChatGPT plugin submission form asks for a Customer support URL. We filled it in on 2026-09-03 and measured what the site answered:
Path on juudd.com | Answer |
|---|---|
/privacy | 200 |
/terms | 200 |
/abuse | 200 |
/support | 404 |
The obvious answer was the address /privacy and /terms already carried. The form refused it: a mailto: link gets "Enter a valid HTTPS URL." So the requirement was not "publish a contact". It was publish a page.
That exposed a gap that had nothing to do with the form. /abuse is a report about somebody else's site. The legal pages carry an address in a closing paragraph, which is where a reader looks last. A customer whose deploy was refused, or whose database stopped answering, had no page to arrive at.
The tools answer first, and that is not a deflection
The page opens with list_refusals and the panel, above any address.
A refused call here keeps the exact sentence the caller was given. list_refusals reads back what an account has been told no about, newest first, each in those words, and it covers every site the account owns. It carries refusals only, because what succeeded is already derived by list_deploys. A customer returning in a later conversation, where the assistant that was refused is gone, can have its replacement read the record instead of guessing.
So most of what would reach a mailbox is already answered, in the words of the call that failed. Naming that first points at a feature we built on purpose, not at a FAQ standing in for support. The panel is the second place. It shows one account, the customer's own, and nobody else's.
What we cannot do is half the page
Four things, and each is a property of a decision recorded elsewhere rather than a limit of staffing.
- Read a database we have handed over.
transfer_databasemints a link, and once a person opens it the platform cannot read the database, back it up, or get it back. The tool's own description calls it the exit door with no deadline, and says it has no undo. Support cannot look inside. - Recover a credential. A site's database password exists in one place, a write-only binding on the deployed site. We cannot read it back, so we cannot tell you what it is.
reset_database_credentialrebuilds one rather than recovering it. - Delete a deployed version. Every version is kept, because that is what makes rollback possible. Stopping a site from being served is available and erasing what was served is not.
- Answer a billing question. The page says there is nothing to bill yet, that nothing is charged, and that the terms will be updated before that changes.
These four are the ones a customer discovers at the worst moment. Each is the cost of a promise they were given the good half of. The handover is irreversible because it is a real exit. The credential is unreadable because it lives in one write-only place. Telling them on the page is kinder than telling them mid-incident.
The other half says what we can do: read the record of an account's writes and refusals, put back an earlier version by publishing it, and remove identity records and action history on request, by hand, because a self-serve path is not built.
What it does not promise
There is no response time. Who answers, and how fast, is still an open question for one operator, and we decided the same for /abuse for the same reason. An address that answers late is recoverable. A page that publicly missed its own deadline is the thing a reader forwards to somebody else.
The page does say what to send so one message can be acted on in a single pass: the site id, what you asked your assistant to do and what came back, and when it happened. Every action and every refusal is written down with a time, so a time is what finds it.
The address was the compromise
A role address is better than a person's mailbox, and the first version of the page named the person's, because the role address did not exist yet. A page naming an address that bounces is worse than no page. The role address replaced it once a message had been seen to arrive.
What was rejected
- Pointing the form at
/abuse. It is a real page, but its subject is somebody else's site. A reviewer following a support URL to a page headed "Report abuse" would learn that we do not tell our customers apart from the people complaining about them. - Making the address first, then the page. It is the right order and it was not available that day. Shipping the page against an address that already answers costs one line to change later. Shipping it against one that does not costs a customer.
- A response time, to look more professional. Refused for the reason above.
The rule, once
A support page should point at the product's own answers before a mailbox, state what the platform cannot do as plainly as what it can, and promise nothing it has not decided. The tools and their limits are listed in the docs.