Client workspaces

Each customer gets their own workspace under your organisation, fully isolated and inheriting your brand.

Provisioning

Reseller → Client workspaces → New client: enter a client name, the client email (required — see Handover), and a starting plan — Free, Starter or Pro (Business isn't offered to resold clients) — then Create client.

Two things are checked at creation: a free client seat, and enough unallocated pooled knowledge sources to fund the plan's source default. If either is short, the button is disabled with an upgrade hint and the server refuses with USAGE_LIMIT_REACHED as a backstop. The same gate guards every path that turns a workspace into a live client — this dialog, an invite, self-serve sign-up, and an admin restore-from-trash. Your own primary workspace never consumes a seat.

Clients can also arrive without you. With self-serve sign-up open on your live domain, a visitor creates their own account and a client workspace they own. You are not added as a member and take no seat there — you keep read-only client-view access like any other client — and the row carries a Client-owned badge (the same badge a completed handover invite shows). You get a New client signed up notification. It costs a seat like any other client. See Client sign-up.

Handover: every client starts as an invite

The New client dialog requires a client email, and the workspace is provisioned for that client: no membership row is written for you, and a 30-day owner-handover invite is sent to the address. The seat is consumed the moment the workspace is created, not on acceptance.

• While the invite is outstanding, the row shows an amber Invite pending · a@b.c badge. You already have read-only client-view access to it.
• After 30 days unaccepted it turns to a red Invite expired — resend. Use ⋯ → Resend invite to re-mint a fresh 30-day invite to the same address; it invalidates the old token, is rate-limited to 20/hour per org (shared with new-client creation), and is audited on your own workspace's log. A client that already accepted, or was created without an email, has nothing to resend.
• The moment the client accepts, ownership transfers to them: they become the workspace Owner, any seat you held on it is released, and the badge becomes Client-owned. You keep the same read-only client-view access as every other client.

Per-client limits

Every client row carries a Limits editor with three overrides:

The rules that govern them:

• Overrides win in both directions. A set value replaces the plan default whether it is higher or lower — lift a small client above their plan, or hold a large one below it.
• Blank inherits, and each knob floors at 1. Clear a value to drop the override; a 0 is rejected (a client left with a legacy zero cap shows its "paused" label rather than being editable back to zero).
• Ceilings. Team seats cap at 50. Chatbots and team seats can't exceed the client's own plan default — to raise them, move the client to a higher plan (below) or sell them a client plan. Knowledge sources are pooled org-wide (below).
• A limit can't drop below current usage. The save is refused 422, naming each count (e.g. Chatbots: 3 active, the limit can't go below 3.); remove the resources first. (A client left over a cap by a plan change is grandfathered — only that leftover, not a manual lower.)
• A live BYO subscription owns its plan's fields. For a client on one of your Stripe-checkout plans, the three limits and the billed amount are read-only — editing them is refused 422 naming the plan. Agent cost and the AI-disclosure mandate stay editable.

Overrides drive the same gates as plan limits: chatbot creation and re-enabling, team invites, and knowledge-source creation and re-enabling. Changes are audited.

Changing a client's plan

A client row's ⋯ → Change plan… moves the client to Free, Starter or Pro (API: POST /api/v1/reseller/clients/{workspaceId}/plan). The new plan's limits and features apply at once; the platform doesn't bill for it.

• Up from Free turns credit metering on and brings back bots the old plan had suspended.
• Down is refused 422 while the client uses more than the new plan allows, or has a chatbot or team-seat override above it — lower the override first. A knowledge-source override stays; moving to Free leaves credit metering as it was.
• The new plan's source allotment must fit your pool; a change that doesn't grow it is never refused.
• A client on a live BYO subscription can't be moved here — change their client plan or send a new checkout link.

Per-client API access is not a reseller control. Whether a client can use the API follows the organisation's API-access decision, which only a platform admin sets; a client with no per-workspace override inherits it. See Per-client API access.

The org-wide knowledge ceiling

Separate from any single client's cap, your reseller tier sets an org-wide knowledge-source ceiling counting active sources across all resold clients. Your own primary workspace is excluded. It is enforced on every creation path — manual, file, template, crawl — and on re-enabling a disabled source.

A lapsed plan resolves the ceiling to zero: new client sources are blocked org-wide while existing sources keep serving. Re-subscribing reopens it.

The ceiling is an allocated ceiling, not just a usage one. What's allocated is the sum of every live client's effective source limit — each client's override, or its plan default when it has none. The reseller panel shows allocated / total, with each client's used figure beneath. Raising one client's source limit past what the pool has left is refused 422, naming the remaining headroom; an unchanged or lowered value always saves, so an org that downgraded its tier is never locked out of its own editor. Creation-time enforcement stays as the backstop. When a client hits the ceiling they see a neutral message that leaks nothing about you or the platform:

Source limit reached — contact your support provider.

Agent cost per client

You can override a client's agent hourly cost, which feeds their savings figures. The override sets the rate only — the currency always comes from that workspace's own setting, so a client's report never mixes currencies. See Agent cost.

Per-client margin

The Limits editor also holds a You bill / month field — record what you actually charge this client. Set it, and the client row shows a live margin %: what you bill minus this month's usage COGS at your plan's pool rate (your reseller plan's price ÷ its included credits; voice burns the same ledger, so it counts too).

• Amber under 20%, red under water. When margin erodes below 20%, the org owner gets a client_margin_low email — once per calendar month, re-armed when you change the billed amount, so a fresh price gets a fresh warning.
• No billed amount → margin shows "—", never a fake 100%. The figure is only as honest as the number you enter.

The billed amount is monthlyBilledCents on the limits endpoint (POST /api/v1/reseller/clients/{id}/limits, reseller:write) — nullable to clear, optional to leave unchanged; editing it re-arms the alert.

ROI report per client

Every client row carries an ROI report link opening that client's full analytics — cost and hours saved at their configured agent rate, deflection, CSAT, leads, appointments — the same numbers your weekly digest emails, pulled live. CSV and a your-brand PDF export from the same page. Hand the PDF to the client at renewal; it makes the case for you.

The same bundle is available over the API at GET /api/v1/reseller/clients/{id}/analytics (reseller:read, with range and tz query parameters), so you can pull a client's ROI figures into your own reporting.

Viewing a client workspace (read-only)

You and any admin on your primary (agency) workspace get read-only access to every client workspace — no seat, no membership row, and you never appear on the client's Team page. Pick a client from the workspace switcher's "Client workspaces · view only" group. An amber banner marks the view, and every write is refused server-side:

You're viewing a client workspace — actions are disabled.

Each switch-in writes one Viewed a client workspace row on your own workspace's audit log. Back to my workspace returns you to the workspace you switched from (hopping straight to another client still returns you there). Plain members of your agency workspace, and users seated only in a client workspace, do not get this access; it is refused while your primary workspace is suspended, and the switcher list is capped at 1,000 clients.

Deleting a client workspace

⋯ → Delete… on a client row permanently removes it. Any primary manager on an active reseller plan (owner or admin) can do it; the confirm dialog makes you type the exact workspace name and pass a critical step-up (your current 2FA code, or your password if 2FA is off), and is rate-limited to 10/min and audited on your own workspace's log. It refuses your own primary (agency) workspace, and demo/preview workspaces.

The delete runs the same cascade as any workspace delete: chatbots frozen, Stripe subscriptions cancelled on both the platform and your BYO account, all data removed, and the client emailed that their workspace is gone. Any unspent pool-sourced credit the client still held returns to your pool. Every member left with no workspace anywhere — the client, and any colleague they invited onto it — is tombstoned immediately rather than entering the usual 30-day orphan grace, and each stays restorable by platform admins until the retention purge.

You, the provider, are emailed and belled on every client delete — whether you deleted the client here, the client deleted their own workspace, or platform support soft-deleted them. A lapsed reseller plan cannot delete a client.

Where to go next

• Pooled credits and caps
• Per-client API access