Support — asking a human, and reaching the right one
In plain terms: when something is wrong or unclear, you ask a person. Your request goes to whoever is responsible for your organization — or for the product you named — and the whole conversation stays in the app.
Before this existed the platform could only talk outwards: five kinds of transactional email and one broadcast to P4P staff. There was nothing to write into. If you had a problem, you had to already know somebody's Telegram.
The interesting part is not the form, it is where a request lands. Everywhere else in the platform "tell whoever can handle this" means telling everyone who holds the right permission. Support does not: somebody is responsible for these people, so it goes to them, and telling everyone is what happens only when nobody is.
How to...
Asking
Ask for help — the avatar menu (top right) → Ask for help. It appears only inside a workspace, because a request is filed on an organization's behalf; outside one there is nothing to file it against. It also appears in My Account → Support, always.
Say which product it is about — the form offers only the products your organization actually uses. Leave it out when the question is about the organization itself — billing, access, somebody who left — because that is what sends it to whoever answers for the organization rather than for one product.
Choose who answers — your own organization, or P4P. The form asks every time and fills nothing in for you, because a request cannot be handed from one side to the other afterwards: a misaddressed one can only be closed and asked again. Your organization answers questions about itself — access, a colleague, anything internal. P4P answers questions about the platform and its products, and stays on the list even when your organization answers everything else, so a question about your own administrators always has somewhere to go.
See what your whole organization has asked — the workspace sidebar → Settings → Support requests. The organization's OWNER sees every request its people opened, read-only. Opening it subscribes you to nothing: the only support event that will ever reach an owner's bell is a request going overdue.
Read the answers — My Account → Support. One list across every organization you belong to, so you do not have to remember which one you were in when you asked; each row names its own.
Reply — on the request's own page, as often as you need to while it is open. Each message joins the same conversation and tells whoever is responsible; it does not open a second request. You cannot reply to a resolved request: open a new one and mention it. Replying would bring it back into somebody's queue without anybody deciding to.
Writing again hands the turn back and nothing else. If the request was waiting on you it becomes open again — and the time it spent waiting is added back to its deadline. If somebody had already marked it as being looked at, it stays that way: they did not stop because you added a detail.
Why there is no name on the answer
The page says Support, never a person. Putting a name on it invites writing to that person directly next time, which is how a request ends up in one individual's inbox while they are away.
Answering for your own organization
Open your organization's queue — the workspace sidebar → Settings → Support requests. You need the SUPPORT role, or any role your organization has granted workspace:support:answer to. Three views — Nobody owns, Mine, Everything. Nothing is assigned in advance inside an organization, so every new request lands unowned and the first view is where you find it.
Take one — open it → Take it. Answering an unowned request takes it anyway: whoever replied has in fact picked it up.
Answer — the box at the bottom of the conversation. The person who asked is told that their request was answered, never which of you answered it — the same rule that applies when P4P answers.
Close it — Mark resolved, and Reopen to put it back. Writing into a resolved request reopens it too, and the history says so.
What you do not see here are the requests your colleagues addressed to P4P. They are not hidden from this list, they are outside it — opening one by its own address answers "not found". That is the point: somebody writing to P4P may be writing about the organization's own administrators.
Answering
Find what needs doing — Platform Administration → Support. Three views: Nobody owns, Mine, Everything. The first is the default and the reason the page exists — a request nobody is responsible for is the failure this whole thing is built to avoid.
Sorted by what has been waiting longest, deliberately the reverse of a requester's own list: they want to see what they just said.
Narrow it to one product — the product picker beside the tabs. It offers only products some request is actually about, plus About the organization for everything that is about no product — billing, access, a former employee.
Take one — Take it on the request. Answering also takes it if nobody had it: whoever replies has in fact picked it up.
Answer — the box at the bottom. This does not mark the request as waiting on the requester — only you know whether your reply needs an answer, so set Waiting on the requester yourself when it does.
Close it — Mark resolved. The person who asked is told. Reopen brings it back and clears the resolution date rather than leaving a record that says both.
Writing first
Write to someone — Platform Administration → Support → the + in the header. Choose the organization, the person, a subject and the message. Only the organizations you answer for or supervise are offered, and only their active members; a super administrator can write in any.
It opens as waiting on them, so no deadline runs until they reply, and it is yours to answer. They see it under Support as from Support, without your name — like every answer. Every conversation started this way is recorded in the audit log.
Write into a resolved request — just write. Sending reopens it, and the history says so. The person who asked cannot do the same: for them a resolved request stays closed, and they open a new one.
Deciding who answers
Name a responsible person — Platform Administration → Workspaces → open one → Who answers for this organization. One person for the whole organization, and optionally one per product it uses.
This decides where the next request goes. Requests somebody has already taken stay with them — see what the chain does below.
Stop somebody answering — the bin next to their name. The group then has no responsible person, and its requests fall through to everyone who can answer.
Set a time to resolve — the Within (hours) box on the same row. Left blank, the group uses the platform's own limit, shown as the box's placeholder. Change that limit in Platform Administration → Support → the gear in the header.
Name who is told when it runs late — the Escalates to box on the same row. That person gets no everyday traffic at all; they hear only when a request in that group passes its deadline.
What happened, between the messages
The conversation shows more than messages. Between them, one quiet line says what happened to the request, and when: that it was taken, that its status changed, that it was resolved or reopened.
- The person who asked never sees a name in those lines — "The request was taken", not who took it. The answering side sees who is responsible and who changed what.
- Not everything is a line. A handover between support staff is not shown: nothing changes for the person waiting. Nor is the status a reply moves a request to by itself — the reply is already there. Picking the status a request already has records nothing.
- Answering a request nobody had takes it, and that shows as taken, right before the answer.
- Requests opened before this history existed start their history from the moment it did.
Where a request goes
Which chain runs depends on who the person chose to ask, and the two never mix.
Asked P4P — four steps, in order:
| # | Step | Why |
|---|---|---|
| 1 | Whoever already took it | Once a person is on the hook, changing who is responsible must not move the request out from under them |
| 2 | Responsible for this product in this organization | An organization with three subscriptions is three applications to its members |
| 3 | Responsible for the organization | Anything that is not about a product |
| 4 | Everyone who can answer | So a request with no owner is loud rather than lost |
Asked their own organization — two steps:
| # | Step | Why |
|---|---|---|
| 1 | Whoever already took it | Same reason as above |
| 2 | Everyone seated on that organization's support | Nothing is assigned in advance inside an organization, so somebody picks it up |
Seated means holding workspace:support:answer. Every organization starts with its OWNER holding it, so a request has somewhere to land even before anybody has been put on support.
Two behaviours that surprise people:
- A responsible person whose account is suspended is not skipped in favour of the next step. The request becomes nobody's — which is visible — rather than quietly going to somebody who never agreed to answer for that product.
- Losing the permission does not reroute anything. Only the account's own status is re-checked. A person who can no longer answer shows up as a request needing reassignment, which a human sees, rather than as one that moved on its own.
Running late
Every request gets a deadline when it is opened: the group's own Within (hours), or the platform's limit if the group has not set one. Passing it turns the request red in the queue and in the owner's list, and sends one notification — to the group's supervisor if it has one, otherwise to whoever is responsible.
Three things about that clock are worth knowing:
- It stops while the request is waiting on the requester. Support asking a question and waiting three days for an answer is not support being late.
- A deadline is set once, at the moment the request is opened. Changing a group's limit — or the platform's — moves nothing that is already open. Everybody keeps the deadline they were given.
- The notification is sent once per request, not once per check. A request that stays late stays red, but says so quietly.
Requests opened before deadlines existed have none, and are never late.
Everything updates live. An open page — the queue, a request, your own list, an owner's list — refreshes by itself when somebody else changes a request it shows: a new request arriving, a reply, being taken, a status change. No reload needed.
Being told
One notification group, Support, with seven events: a request arriving, the request being taken, support answering, the person who asked writing again, a handover, a resolution, and a request running past its deadline.
Nothing sent to the person who asked names who answered — "Support replied", "Support marked it resolved". Same rule as the conversation, and it covers the stored notification too, not just the words on screen. Email is on by default — unlike the activity groups nobody asked to be in, this is the one conversation where the recipient is waiting.
The message is never in the email. Only the subject line the requester wrote themselves. The conversation stays in the app, which is the one place the platform can still take it back from — the same rule agent runs follow for their results.
Unread replies about one request fold into a single row saying the latest thing that happened. That stops the moment you read it, so a reply after that is its own notification and its own email.
Who may do what
| Permission | What it opens |
|---|---|
workspace:support:create | Asking for help on behalf of that organization |
workspace:support:read | An owner seeing every request their people opened |
workspace:support:answer | An organization answering the requests addressed to it |
platform:support:read | Seeing the queue and the conversations |
platform:support:manage | Answering, assigning, resolving, naming who is responsible, and setting the time to resolve |
platform:support:oversee | Being told when a request goes past its deadline — escalation, and nothing else |
Asking is a permission on purpose. Every seeded role has it, so it arrives switched on — but an organization that handles its own support, or one running where P4P cannot be reached, can take the button away rather than leave people writing into a channel nobody reads.
Reading is split from answering for the same reason payout visibility was split from payout management: seeing what people ask and answering them are different jobs.
workspace:support:read is on OWNER only among the seeded roles — these conversations can be about the administrators, so it sits in the same tier as ownership transfer. An organization that disagrees can grant it in the Roles screen.
workspace:support:answer is what lets an organization answer its own people, and it is an organization permission — seating somebody on your support needs no P4P role of any kind. There is a seeded SUPPORT role holding exactly this one key. It deliberately does not include workspace:support:read: that is the owner's view of everything, including what your people addressed to P4P, and somebody seated to answer colleagues has no business reading those.
Roles stack, so an organization that wants its support people to also read the members list gives them SUPPORT alongside MEMBER rather than widening either.
There is also a seeded platform role, P4P Support, holding exactly the two platform keys and nothing else. Before it existed, hiring somebody to answer support meant giving them P4P Admin, which also manages organizations, users, products, roles and notification policy.
Being able to see is not being told
Four kinds of people can read a request: the person who asked, whoever answers, the organization's owner, and a super administrator. Only one of them is notified. Arrivals, replies and handovers reach the responsible person; a resolution reaches the requester. Owners and super administrators watch silently.
There is one exception, and it arrived with organizations answering their own people: an owner IS told about requests addressed to the organization, because they are the person answering them until somebody else is seated. What their people sent to P4P stays as silent as before.
A supervisor is the other exception that proves the rule: naming one subscribes them to nothing except the request going late. That is the whole point — it is how oversight scales past the number of conversations a person can read.
That is deliberate, and it is what keeps oversight usable as responsibility is split across more groups: you are out of it until something goes wrong, and the thing that goes wrong travels upward.
Installations without P4P
Nothing in this knows whether the responsible person works for P4P. An assignment names a user, and platform:support:manage is a permission anybody's administrators can hold — so on an On-Premise installation the customer's own administrators are the support, through these same screens, with no separate mode.
Where there is no email at all, the request still arrives: the in-app notification is the channel and email is the addition, so an offline installation simply sends no mail (docs/VISION.md §6).
Escalating from such an installation up to P4P is deliberately not built — it needs an outbound channel that may not exist there.
Not built on purpose
No categories or tags, no public knowledge base, no requests without signing in, no internal staff-only notes, and no agent answering automatically. The last is the most tempting, since the platform has agents — but support has to work with people first, or an automatic reply becomes a way of not noticing that it doesn't.
Attachments are the first follow-up: screenshots are exactly what a support conversation wants, and the file storage that backs task and chat attachments is already there.
Testing this module
SupportRoutingService is the part with a test per level of the chain, and per way a level can be skipped — "the message went to the wrong person" is the failure that makes a support system worse than none, because the requester cannot tell it apart from "nobody has answered yet".