Support desk · private beta

Support that can actually see your app.

Live chat and email in one inbox, answered by an agent that reads your real application data — not a bot that paraphrases your help centre. With hard permission gates, so it can never read the wrong customer's account.

01 — One inbox

Chat and email stop being two products.

A widget in your app and a support address on your own domain arrive in the same thread, with the same history, ticket number and assignee. Whoever is on support answers in one place instead of reconciling two.

Replies know which channel they are going out on, and say so. If the customer is still sitting in the chat, you do not accidentally send them an email about the conversation happening in front of them.

CHAT

Authenticated, not anonymous

The widget proves who the user is against your own app, so an operator sees a verified account rather than a name someone typed.

EMAIL

Your address, your domain

Forward from whatever you already use. No MX changes, no migration, no second inbox to keep an eye on.

THREADS

Replies that thread properly

Answers land in the conversation they belong to, in the customer's mail client as well as in yours.

02 — Agents with real context

Most support AI can only read your docs. That is why it is useless.

“Where is my order?” is not a documentation question. Nor is “why did this charge fail”, or “which plan am I on”. Answering those needs the row in your database, and a help-centre summariser will never have it.

helphelphelp connects to your app and your data. You expose the reads that make sense — an order, a subscription, a recent error — and the agent answers from the actual record, scoped to the customer who is asking.

// what the agent is allowed to look at, per product
expose("order.byId")      scope: install + customer
expose("subscription.current") scope: install + customer
expose("shipment.latest")   scope: install + customer

// everything else is unreachable, including to the agent

Answers cite the record they came from, so an operator can check them.
Your docs still get indexed — they are just no longer the only source.
On email every draft waits for a human to approve it, because a wrong email cannot be taken back.

03 — Gates, not guidelines

The agent cannot reach another customer's data. Not “is told not to”.

Prompting a model to respect boundaries is not a boundary. Every read is scoped in software to the install and customer the conversation belongs to, before the agent is involved — so a question crafted to extract someone else's account returns nothing, because there is nothing to return.

Tenant isolation in code. A conversation is reachable only with a credential for its own install, including the same storefront on a different product.
Verified context, kept separate. What your app signs and what a browser claims are stored apart and never merged.
Retrieval never crosses products. One customer's documentation cannot surface in another's answer.
The admin is not on the public internet. It sits behind your identity provider, not a password field.

04 — MCP

Your coding agent can set it up, and check its own work.

helphelphelp exposes a remote MCP server, so the agent you already code with can integrate the widget, configure email, index your docs and then verify the integration against the live deployment — rather than guessing from a README.

$ claude mcp add --transport http helphelphelp \
    https://hhh.support/mcp --header "Authorization: Bearer …"

› integration_status        is the widget actually working?
› email_setup              what is left to do, in order
› search_docs              what the agent would answer with

The same permission model applies. An MCP caller sees only the products it has been granted, and read scopes are enforced in the service rather than in the prompt.

Want it?

It is in private beta while the first products are onboarded. Leave your email and you will hear from us when there is a slot — nothing else, and no list to unsubscribe from.