Clients

For whoever is running the desk, and agents who want to know what the pane is showing.

A client is an account in a brand. Where the brand is connected to a billing platform, the desk holds a light record (name, email, company, contacts, the platform’s id) and asks the platform for everything else when a staff member looks.

How the desk knows who somebody is

On proof of control, never on an email address matching.

That is the rule the whole design hangs off. A client record is linked to a person when:

• they arrive from their billing portal through the signed integration API: the platform has vouched for that browser session; or
• they follow a link carrying a token only the account holder’s mailbox received; or
• they reply to a ticket email carrying that ticket’s reply token.

Two people can hold the same address, an address can be forwarded, and a header can be forged. So a message whose sender merely looks like a client is filed as a guest sender on the ticket, never adopted into the account. This is unusual and it is deliberate.

Guests

Somebody with no account who opens a ticket through a guest form or by writing in is a guest sender. They get a link with a token to read and answer their own ticket, and nothing else. Guest access is per department, and there are per-brand submission limits and flood alerts for the days somebody discovers the form.

The client pane

Beside a ticket, and on the client’s own page:

• The desk’s own record: name, company, email, the contacts you hold, their tickets, their tags, their reputation where it is switched on, and their local time read from the address they last connected from.
• The platform’s account, where the brand is connected: name, company, email, postal address, telephone numbers, account status, client group, the platform’s client code, when they signed up, and a link into the platform’s admin area. Where the two disagree on name, company or email, both are shown and the platform’s is marked “differs from the desk”, the desk’s record is never silently overwritten, because tickets hang off it.
• What they owe: balance per currency, the overdue part in red with how many invoices are late, and any credit held.
• Sign-ins: when anyone on the account last signed in, from where, and how many attempts have failed in the last 30 days. For answering “I cannot get in” without leaving the ticket.
• Payment methods: folded away until opened: card and bank types, last four digits, expiry (red if expired, amber if it expires within 60 days), which the platform charges by default. The full number, the gateway token and routing numbers are never sent to the desk at all.
• The other contacts: everyone on the account, their role, what they may do, and whether they may use support. So you can see whether the person writing is the billing contact.
• Services, invoices, transactions and emails: tabs, paged at the platform. A service row opens in place to show everything the platform holds about that one service.

Each block appears only if the connected platform can answer for it; an older module simply shows less rather than erroring.

Reputation

Optional, per brand. A standing from 0–100 and a band, computed from twelve weighted factors across billing standing, behaviour on the desk, and where they connect from, each carrying the sentence that explains it. A factor with no facts is unavailable rather than zero, so a desk with no billing platform still produces a meaningful score.

Agents see the band and the trend; administrators see the breakdown. Weights are per brand, and the whole thing has an off switch. It is there to answer “should I bend the rules for this person”, not to decide anything automatically.

Human verification

Per brand, with a per-department switch for guest and client forms: Cloudflare Turnstile in front of the new-ticket form, the guest form and the public report form. Worth switching on the day the guest form is discovered by a script, and usually not before.