SolutionDeskThe ticket desk that ships inside your product
One hub where your team — and your AI agents — work every feature request, bug and support case. Your enterprise customers follow along in a white-label portal, one MagicLink away — no second login, no “any news on this?”.
Portal link in one POST·Your domain, your branding·Agents connect over MCP
SSO login loops back to /signin
Mara · Acme staff
Reproduced on your staging tenant — the callback URL drops the state param. Fix is on the way.
Triage Agent · AI agentInternal — never reaches your customer
Same root cause as 260628-QX7M. BigCorp is on the enterprise plan — bumped priority to high.
Lena · BigCorp · via portal
Thanks — our rollout is blocked on this, appreciate the quick look.
The problem
Your issue tracker was built for your team. Then the enterprise customers arrived.
GitHub Issues and Notion carry a SaaS team a long way — right up to the first customer with custom requirements, change requests, and a legitimate need to know where things stand. From that day on, support runs on scattered threads and goodwill.
The conversation is everywhere
Half of it lives in the support tool, the other half in email threads, and the decisions in a doc nobody links. When a customer asks what happened to their request, someone goes digging.
“Any update on this?”
Enterprise customers expect to see the status of their requests and the plan behind them — at any time. A weekly summary email is not a shared overview. It's homework.
Every update is manual
Ship a fix, close a bug, reprioritize the roadmap — and then write it up, per customer, by hand. The bigger the account, the more of your week disappears into status reporting.
The solution — one desk, four ways in
Your team gets the whole picture. Everyone else gets exactly their slice.
Every request lands in the same desk, whoever files it. What differs is how each audience gets in — and how much of the desk they can see once they're there.
Email + password
Your team
The dashboard: every request as a ticket or on the board, with statuses, priorities, labels, due dates and assignees. Internal notes and internal tickets stay behind the staff line.
app.solutiondesk.io/acme
OAuth · MCP
Your AI agents
Not a chatbot bolted on top. An agent connects its MCP client to your workspace, gets a member account with a role, and works the same tickets your colleagues do.
api.solutiondesk.io/v1/mcp
Host-brokered MagicLink
Your customers
Your backend mints a portal link and redirects. They land signed in, on your domain, in your branding — no SolutionDesk account, nothing to remember, no second password.
support.your-saas.com
Capability link
Anyone with the link
A guest portal for a group with no host account at all — a tester cohort, a beta round, a feedback session. Share the link, optionally behind a password; flip it off when the round ends.
/guest/acme/beta-round-2
How it works
The Stripe Customer Portal way — for support.
- 01
Sync the user once
Your backend upserts the end-user by the id they already carry in your system, together with the company they belong to. It's idempotent, so calling it on every login is fine.
- 02
Mint a link, redirect
One POST returns a single-use portal URL. Wire it to the “Support” button in your app. No SDK, no iframe gymnastics, no user directory to keep in sync.
- 03
They see exactly their slice
They land signed in — on your domain, in your branding. Their own tickets and progress, plus anything an access rule grants them. Internal notes never reach the portal: enforced on the server, not hidden in the UI.
your-saas/backend — the whole integration
Server-to-server · Bearer API key
POST /v1/integration/end-users
{ "externalId": "usr_8f2", "email": "lena@bigcorp.com", "name": "Lena Sørensen", "companyExternalId": "org_412" }
→ 200 { "endUserId": "eu_3c1" }
POST /v1/integration/portal/links
{ "externalId": "usr_8f2" }
→ 200 { "url": "https://support.your-saas.com/portal?token=…" }For your AI agents
Your agents don't need a chatbot. They need an account.
Point Claude, Cursor, or your own agent at the MCP endpoint. It authorizes over OAuth as a member of your workspace, and gets the same desk your colleagues use — these ten tools, and nothing you didn't grant.
Every action on the record
Status changes, assignments, comments — an agent's writes land in the same immutable per-ticket timeline as a human's. When a customer asks who decided what, the answer is already written.
Bound to your workspace
The MCP connection resolves to the workspaces that one staff account is a member of. An agent cannot read across tenants, because the cross-tenant query doesn't exist.
api.solutiondesk.io/v1/mcp
OAuth · 10 tools
- Reads
list_workspacesThe workspaces this agent can reach
list_ticketsThe queue
get_ticketOne ticket, in full
list_commentsThe conversation, staff-only notes included
list_membersWho's on the team, and which one it is
- Writes
create_ticketFile a request
add_commentReply — or leave an internal note
set_ticket_statusMove it along
assign_ticketHand it to a colleague
create_companyRegister an end-customer
Point any MCP client at the endpoint. It discovers the authorization server, asks you to approve the connection, and then lists itself under your connected apps — where you can revoke it again.
/.well-known/oauth-protected-resource
Built in
Everything a shared desk needs. Nothing your customers shouldn’t see.
Visibility, per ticket
Public for everyone. Internal for staff only. Restricted for exactly the end-users an access rule matches — by plan, region, or any attribute you send us. The default is always less exposure.
White-label, down to the domain
The portal is your product's support area, not ours: your domain, your logo, your colors. Your customers never learn the name SolutionDesk — unless you want the discreet credit.
support.your-saas.com
Not every request is yours to answer
Big customers have their own support people. Let them triage on their own board first and escalate only what they can't solve. Until they do, the request stays theirs — your queue never sees it.
tier: "team" → "provider"
Mail from your own domain
Status changes and replies reach customers through your SMTP, from your address — so notifications look like you, land like you, and build your sender reputation, not ours.
from: support@your-saas.com
The board moves while you watch
A colleague claims a ticket, a customer replies, an agent changes a status — it appears. Every open board streams changes live, so two people stop working the same ticket by accident.
text/event-stream
Tenant isolation by design
Every read and write is keyed to your workspace's partition. One tenant's data is never one bad query away from another's — the cross-tenant query simply doesn't exist.
partition key: /workspaceId
And the rest
- Kanban board & list view
- Labels, per company
- Priorities & due dates
- File attachments
- Ticket types with their own fields
- Watchers & @mentions
- Portal in your customers' languages
- Roles, invitations & per-company portal roles
- API keys, hashed at rest
- Readable ticket references — 260701-F4KR
- Light & dark theme
- Embeddable widget — on the roadmap
FAQ
The questions your team will ask.
- Do my customers need a SolutionDesk account?
- No. Your backend requests a MagicLink from the SolutionDesk API and redirects the user into the portal — the same pattern as the Stripe Customer Portal. No signup, no password, nothing for them to remember.
- Can customers ever see our internal notes?
- No. Visibility is a property of every ticket and comment, enforced on the server. Internal tickets and internal notes never reach the portal — not styled away, simply never delivered.
- Does the portal look like SolutionDesk or like our product?
- Like your product. The portal runs on your custom domain with your logo and colors. The only trace of us is an optional, discreet “Powered by SolutionDesk”.
- How does the integration authenticate?
- With a per-tenant API key, server-to-server. Keys are stored hashed; you only ever see a display prefix after creation. Minting a MagicLink is one POST request from your backend.
- What do AI agents actually do here?
- They work the desk. An agent connects its MCP client — Claude, Cursor, or your own — and authorizes over OAuth as a member of your workspace. From there it reads the queue and files, answers, reassigns and closes tickets through ten tools, with every write attributed in the same timeline as a colleague's.
- We need feedback from people who aren't customers yet. Testers, a beta round.
- Open a guest portal. It's a shareable link — no account, no host system involved — where a group can file requests and follow the ones already there. Put a password on it if the group is sensitive, and switch it off when the round ends. The history stays.
- Our biggest customers have their own support team. Can they filter first?
- Yes. Turn on two-tier for that company and their requests land on their own board first, visible to their people and not to yours. What they can't solve, they escalate to you — same ticket, same reference, now in your queue.
- Our customers aren't all English-speaking. Is the portal?
- The portal chrome and your own configured texts — ticket types, statuses, priorities, field labels — carry translations per language, so each end-user reads it in theirs.
- How is our data isolated from other tenants?
- Every record is keyed to your workspace's partition, and every read and write carries that key. Cross-tenant access isn't a permission that can be misconfigured — it's a query shape that doesn't exist.
Stop forwarding status updates. Start sharing them.
Set up a workspace for your team, invite your colleagues and your agents — and hand your enterprise customers a portal instead of an email thread.