ToneCustoms — Support Dashboard
Staff workspace · GitHub Issues
Use the links below to manage incoming support without another service. These are live filtered GitHub Issue views, not a separate hosted dashboard or GitHub Projects board.
Ticket queue
| Queue | GitHub view |
|---|---|
| High priority | Urgent tickets |
| Normal priority | Standard tickets |
| Unassigned | Unassigned tickets |
| All open requests | Open tickets |
| New / awaiting review | New tickets |
| Investigating | In progress |
| Waiting on customer | Customer reply needed |
| Closed tickets | Resolved/closed history |
| Technical support | Script support requests |
| Documentation | Documentation reports |
| Partnership inquiries | Partnership proposals |
| Suggestions | Feature requests |
Partnership inquiries are public, non-confidential summaries. Staff should move sensitive negotiations to an appropriate private channel and record only non-sensitive status updates on the issue.
Status workflow
New → Investigating → Waiting on Customer (if needed) → Resolved
- New: Incoming issues receive the
status: newlabel automatically from the ToneCustoms Support Triage GitHub Action. - Investigating: Assigning a new issue automatically changes
status: newtostatus: investigating. Staff can also update status manually. - Waiting on Customer: Staff replace the status with
status: waiting-on-customerif logs or additional information are needed. - Resolved: Close the issue after confirming the outcome. GitHub Actions automatically replaces the status label with
status: resolved. - Reopened: Reopening a ticket automatically resets its status to
status: newwithout posting a duplicate welcome message.
Important: GitHub issue labels are not mutually exclusive. When changing a status, remove the old status: label so the ticket appears in the correct filtered view. Status and priority labels are provisioned by the triage workflow when the first new issue is opened after the updated workflow is active.
Team ownership
Assign an issue to the responsible GitHub team member through the Assignees sidebar. No staff member is automatically assigned without an explicit team decision. New issues default to priority: normal; staff may change to priority: high or priority: low after assessing actual customer impact. These labels do not guarantee response time.
Verified support roles and public introductions
When a GitHub user is assigned to an issue, the support workflow posts a public ownership comment showing their GitHub username and support identity. This makes it clear who is responsible for the ticket.
| Support identity | Verification |
|---|---|
| ToneCustoms Founder | tonyiswavy is configured as the official Founder |
| ToneCustoms Support | Add the approved GitHub username to the workflow's verifiedRoles mapping |
| ToneCustoms Developer | Add the approved GitHub username to the same mapping |
| Community Helper | Can help in public replies but must not be described as official staff unless approved |
The workflow uses a trusted username allowlist, not self-declared role names. Assignment alone does not establish staff identity. Do not add anyone to this list until the Founder approves their role. This identifies staff in the issue comment; it does not create custom GitHub badges or grant repository permissions.
Assignment: GitHub posts a role-aware ownership introduction and moves a new ticket to Investigating.
Unassignment: If the last handler is removed, the workflow posts an unassigned notice and resets an Investigating ticket to New.
Staff handoff: Assign the next handler and remove the previous handler; the issue history preserves both changes.
Important: This workflow is committed but assignment and unassignment events still need a live verification run.
Handling common cases
- Check for an existing issue before investigating a new report.
- Keep troubleshooting replies in the original issue for an auditable support history.
- Ask for a redacted console error, reproduction steps, and resource version if needed.
- Link the appropriate Known Issues & Fixes entry when a confirmed fix exists.
- Close resolved cases with a concise explanation so future customers can find the answer.
Security and customer privacy
Issues are public. Never ask customers to post license keys, order details, protected source code, tokens, database credentials, or personal information. Direct billing and order-verification questions to the customer's original private Tebex order-support thread.