ProcBoss Cloud has a built-in ticket system: when something needs a human — a deploy that keeps failing, a billing question, a bug you can’t pin down — you open a ticket from the dashboard and the staff answers in the thread. Every hop notifies you on one channel you pick: email, Telegram or Discord.
Opening a ticket#
Dashboard → Support → New ticket. A ticket is a subject (≤120 characters) and the first message — say what you expected, what you saw, and name the repo/server/process if it’s fleet-related. The thread that follows is the whole conversation: replies from you and from staff, plus any status notes.
Tickets have three states, and the state tells you who owes the next move:
| State | Meaning |
|---|---|
| open | waiting on support — someone is on it |
| pending | support replied, the ball is with you |
| closed | resolved — writing a reply reopens it |
You can close your own ticket anytime (close ticket button); replying to a closed ticket brings it right back to open, so a “closed” ticket is never a dead end.
Your preferred channel#
Settings → Integrations → Notification channel. Pick the ONE channel you actually watch:
- Email — your account’s address. Delivery needs the server’s email sender configured (Resend); if it isn’t yet, the pick saves and delivery waits — the picker says so honestly.
- Telegram — your connected bot chat (the same pairing the alerts use).
- Discord — your linked bot (the DM delivery).
When you open a ticket you get a receipt; when staff replies, you get the reply and a link to the thread; when a ticket closes, you hear about that too. If your pick isn’t connected, delivery falls back to the next reachable channel rather than staying silent — nothing pretends to have been sent.
How tickets are assigned#
New tickets auto-assign to the support admin with the fewest live tickets (ties go to the longest-serving account, so assignment is stable). If there are no support admins, the ticket lands on the super admin. Either way you never pick a person — the queue routes itself, and the staff can reassign inside the console as needed.
The staff console (roles)#
The admin console has no separate password login — staff sign in with their normal GitHub/Google account, and the dashboard shows them the admin console → link. Three roles, one field:
| Role | What they can do |
|---|---|
| super admin | everything — the config email list owns this role (promoted automatically at sign-in) |
| support | the ticket queue, user context, ecosystem moderation, audit |
| basic | the ecosystem queue and read-only context — content chores, no tickets |
The super admin grants and revokes sub-admins on the console’s Users page (Staff role… in a user’s row menu). Sub-admins see only their sections — the console sidebar obeys the same matrix — and sub-admin redirects land on their own first tool: support staff on the ticket queue, basic staff on the ecosystem queue.
Internal notes#
Staff replies can be flagged internal note — coordination the team writes next to the conversation (known-issue references, who’s following up). You never see them; the thread you read is exactly what’s meant for you.