[Feature] Private helpdesk / support ticketing system — current Discord-only model leaks customer PII
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 22
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
Summary
Z.AI currently has no dedicated helpdesk / support ticketing system for customer-side interactions. The only support channel is a Discord forum where users open support tickets — but those tickets are visible to everyone in the Discord server, not just to Z.AI staff. This is a serious privacy problem: customers are forced to disclose account details, billing info, API keys, error logs, and other sensitive context in front of the entire community, or to under-share and get a worse support outcome.
This is asking Z.AI to ship (or integrate) a proper helpdesk system with private, 1:1, auditable support tickets — accessible directly from the customer portal, not from a public Discord channel.
Current Behavior
- The official support path is a Discord forum channel. A user posts a thread; anyone in the server can read it.
- To get a useful answer, the user often has to include:
- Account email / Z.AI user ID
- Subscription plan and invoice IDs
- API keys (or partial keys) and request IDs
- Stack traces, headers, sometimes environment variables
- Screenshots of the customer portal showing usage / billing
- All of the above becomes public the moment it is posted. There is no way to mark a message "staff-only" or "private".
- Worse: Discord search and scroll-back mean this data stays accessible indefinitely to anyone who joins the server later.
- Users who realize this either (a) withhold critical context and get slow / wrong answers, or (b) DM a staff member — but DMs aren't tracked, have no SLA, and are invisible to the rest of the support team.
Desired Behavior
- Private ticketing system, accessible from the z.ai customer portal (single sign-on with the user's z.ai account). Each ticket is visible only to:
- the customer who opened it,
- Z.AI support staff,
- and (optionally) explicitly-added collaborators from the customer's org.
- No public visibility by default. The Discord forum may continue to exist for community Q&A, but it should be clearly labeled as "public community help" — not the official support channel.
- Structured ticket fields:
- Category (billing / account / API / bug / abuse / other)
- Severity (blocking / impacts work / minor)
- Attachments (screenshots, logs — up to a reasonable size limit)
- Related issue / request ID (auto-filled from the portal when possible)
- Status lifecycle: Open → In progress → Awaiting customer → Resolved → Closed. Email + in-portal notifications on every status change.
- SLA visibility: show expected first-response time per plan tier (Free / Pro / Max) right on the ticket, so users know what to expect.
- Audit history: every reply, status change, and assignment is logged and visible to the customer — no invisible DMs.
- PII handling: explicit warning when a user is about to paste something that looks like an API key, with a one-click "redact" action.
- Optional: Discord bridge. If the team wants to keep Discord as the front line, allow a user to
/ticket openfrom Discord — but the actual conversation is private, and only a one-line summary (ticket # + status) is posted in the channel.
Why this matters
- Privacy / compliance. Public tickets containing account IDs, partial keys, and billing screenshots is a data-leak risk for users — and arguably a compliance issue for Z.AI depending on jurisdiction (GDPR Art. 32, etc.).
- Trust. Paying customers (Pro / Max plan) expect a private support channel as table stakes; the current "post it in Discord" model reads as unprofessional and erodes trust.
- Support quality. Staff can't ask for sensitive repro details in public, so either they guess (slow) or push the user to DMs (untracked) — both make support worse.
- Searchability / knowledge base. Private tickets can be triaged into a public KB article after the fact, with PII stripped — better long-term than scattered Discord threads.
Use Cases
- Billing dispute — user needs to share an invoice ID and last 4 digits of their card. Impossible to do safely in Discord today.
- API key / OAuth leak — user suspects their key was compromised and needs Z.AI to rotate it. They cannot describe the leak publicly without making it worse.
- Production outage — user's pipeline is down, they need to share request IDs and stack traces. Currently they either redact too aggressively (slow triage) or over-share (privacy loss).
- Account takeover / abuse report — by definition cannot be filed in a public channel.
Related
- #123 — Customer portal 5H next reset shows date only. Same theme: the customer portal is missing basic features paying users expect.
- #122 — chat.z.ai: switch model mid-conversation. Same theme: portal / product UX gaps vs. competitors.
Notes
- A turnkey option: integrate an existing helpdesk (Zendesk / Intercom / Crisp / Plain / Front) behind the customer portal SSO, rather than building from scratch. Time-to-value is days, not months.
- If a from-scratch build is preferred, a minimal v1 (auth-gated ticket list + create / reply / status) is enough to retire the Discord-only model; SLA dashboards and KB can come later.
Regards,
Roman
http://www.rommark.dev
VIbe Coders Telegram Channel: https://t.me/VibeCodePrompterSystem
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No repository files or tests are identified. Start by mapping the customer portal entry point, its account authentication boundary, and the current Discord support workflow; done requires a scoped private ticket lifecycle with access controls, audit history, notifications, and PII handling, or a selected helpdesk integration.
Written by the indexing model from the issue text.
Assessment
- Domain
- authentication, backend-api-design, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100