Support Tickets

Overview

The platform ships a full multi-tenant helpdesk - customers open tickets from the user panel, your team works them from the admin panel, and everything (departments, priorities, SLA timers, notifications, attachments) is configured from inside the platform. No external ticketing tool or separate login is required.

This page covers the system end to end from the admin side: how tickets are organized and move through their lifecycle, how SLA timers work, what staff see on a ticket, AI triage and the resource-context card, attachments, notifications, reports, and the permissions that gate all of it.

Concepts

Term	Plain English
Department	A named queue (e.g. "Billing", "Technical") a ticket is opened against. Departments can have their own set of admins for notification routing and a "my department" filter - membership is not an access control; any admin with ticket permissions can open any ticket regardless of department.
Priority	Low, normal, high or urgent. Drives which SLA policy applies.
SLA policy	A first-response and resolution time target for a (department, priority) pair, or a global default when no department-specific policy exists.
Pause-aware timer	An SLA resolution clock that stops counting while a ticket is pending (waiting on the customer) and resumes on the next reply, so time spent waiting on the customer is never held against your team.
Internal note	A staff-only message on the ticket thread that a customer can never see, in any payload or view.
System row	An automated audit line on the thread (assignment change, priority change, SLA breach) - customer-visible ones use plain language ("Priority changed to High"); assignment changes and SLA-breach flags are staff-only.
Linked resource	An instance, volume, Kubernetes cluster, managed database, load balancer, object-storage bucket or VPC the customer has attached to the ticket, picked only from resources the account actually owns.
Resource context	The live status, metrics, tasks, alerts and events the platform gathers for each linked resource and shows on the admin ticket page.
AI triage	An automatic (or on-demand) AI pass over a new ticket that files an internal note with an assessment, a suggested reply, and suggested actions.
Kill switch	The admin support.enabled setting that disables the entire customer-facing support surface at once. The admin panel stays reachable regardless, so staff can keep working existing tickets and find the toggle again.

Departments, priorities and lifecycle

Departments

Go to Support > Departments to create and order departments. Each department has a name, description, active flag and sort order, and can be given its own set of admins (Support > Departments > department admins) purely for notification routing and queue filtering - it is not an access boundary.

Priorities and lifecycle

Customers pick one of four priorities when opening a ticket: low, normal, high, urgent. A ticket then moves through:

open → pending (shown to customers as "Awaiting customer") → resolved → closed

• A resolved ticket auto-closes after a configurable window (default 72 hours, 1-720 hours).
• A closed ticket has a reopen grace period (default 7 days, 1-90 days) during which a new customer reply brings it back to open automatically.
• Moving a ticket to any active state clears its resolved/closed stamps, so an SLA report and the ticket's overdue status are never left pointing at stale data from a previous resolution.

Both windows are set from Settings > Support (see Settings below).

SLA policies

Go to Support > SLA Policies to define first-response and resolution targets (in minutes) per department and priority, or leave department blank for a global default that applies wherever no department-specific policy exists.

The timers are honest about waiting time:

• First response is stamped, then evaluated against the due time computed at ticket creation - pauses never affect it.
• Resolution is pause-aware: moving a ticket to pending pauses its resolution clock; the next reply resumes it. The accumulated paused time is subtracted from the elapsed time, so a customer who takes three days to reply never costs your team three days of SLA.
• Resolving a currently-paused ticket resumes the clock first, banking the live pause, before stamping the resolution time - so the "was this resolved late" check is always accurate at the moment of resolution.

SLA due times are stamped once, at ticket creation, from whichever policy resolves for that ticket's department and priority; changing a ticket's priority or department afterward does not re-stamp new due times.

Threaded replies and internal notes

Both the customer and your team reply on one thread. Staff can additionally post internal notes, which:

• Are never rendered to the customer, in the ticket view, any API payload, or the real-time broadcast channel - the visibility rule is a fail-closed allowlist (only replies and specific system rows are customer-visible), not a filter staff have to remember to apply.
• Can be posted even on a closed ticket, for post-mortem notes after the fact.
• Include AI-generated triage notes, visually distinguished from a human staff note.

The admin and customer ticket pages share the same rebuilt thread and composer components: a stacked conversation view, a sticky reply composer, and a properties/SLA rail alongside it. Status and priority are shown with neutral (non-branded) chips so the queue reads clearly regardless of your panel's accent color.

Linked resources and the resource context card

When opening a ticket, a customer can attach the specific resource they're having trouble with - an instance, volume, Kubernetes cluster, managed database, load balancer, object-storage bucket or VPC - picked from a list scoped to resources the account actually owns.

On the admin ticket page, each linked resource gets a Resource context card that pulls the resource's live state together in one place, so staff don't need a second tab open to see what's actually going on:

• Status pill - the resource's current state (for example an instance's deployed/suspended state, a load balancer's config status, a database's replica count and backup state).
• Metric sparklines - CPU, memory and network charts for the first few linked resources, with a 1h / 6h / 24h range toggle. If metrics can't be fetched (a dead slave, an unreachable metrics backend), the card says so instead of just going blank - one unreachable resource never blanks the whole card.
• Recent tasks - the last several background jobs against that resource (deploys, backups, migrations) with status and progress.
• Alerts and events - a merged, most-recent-first timeline of alert history and platform events for the resource.
• Admin actions - a short history of admin actions taken against that resource.
• A Refresh button and, when the AI Assistant is enabled, a Run AI analysis button (see below).

The card is scoped to the ticket owner's resources - even if a resource ID somehow points at another account's row, the card renders it as "no longer exists" rather than exposing another customer's data. A resource that has been deleted or is no longer owned by the customer renders the same way, using the name captured when it was first linked.

AI triage

When enabled, the AI Assistant reviews tickets and files its findings as an internal note - never customer-visible - so your team gets a head start without the customer seeing an AI-authored message.

What it produces

Each triage run posts one internal note with three sections:

• Assessment - what the AI thinks is going on, citing the actual evidence available (a failed backup task, a recent alert, a metric out of range) rather than a generic guess.
• Suggested reply - a drafted response your team can review and, with one click, load straight into the reply composer instead of retyping it.
• Suggested actions - concrete next steps, preferring checks tied to what the resource context actually shows.

The evidence behind that assessment is exactly the same data shown on the resource context card: it's passed to the model as trusted platform context, clearly separated from (and evaluated independently of) whatever the customer wrote in the ticket, which is always treated as untrusted input. The AI run is read-only - it can inspect linked resources but cannot create, modify or delete anything - and it never sees the platform's own earlier AI notes on the same ticket, so it can't reason from its own prior output.

When it runs

• On ticket creation - runs automatically whenever support.ai_triage is enabled in settings.
• On customer reply - optionally re-runs on every new customer reply when support.ai_triage_on_reply is also enabled, so the assessment stays current as the conversation develops.
• On demand - the Run AI analysis button on the ticket page queues a fresh run at any time the AI Assistant itself is enabled, independent of the two toggles above (rate-limited to one request per minute per ticket, per admin).

Triage is best-effort: it never blocks or delays normal ticket handling, and a triage failure (provider timeout, no context available) is simply logged rather than surfaced as an error on the ticket.

Attachments

Customers and staff can attach files to a ticket up to a configurable size limit (Settings > Support, 1-100 MB, 10 MB by default).

• Virus scanning. Every upload is scanned with ClamAV before it's accepted. You choose whether a scanner outage fails open (accept anyway) or fails closed (reject the upload) from the same settings tab, plus the ClamAV socket path.
• In-browser preview. Images and PDFs render inline instead of forcing a download.
• Storage backend. Attachments are stored on local disk or an S3-compatible bucket (RustFS, MinIO, AWS S3, etc.) you configure with an endpoint, bucket, access key and secret key. The secret key is write-only - the settings page never sends a saved secret back to the browser, and leaving the field blank on a later save keeps the existing value rather than blanking it. Switching backends only changes where the next upload lands; existing attachments keep resolving from whichever backend they were originally written to.

Notifications

Ticket events fan out over your choice of channel, configured under Support > Notification Channels:

• Slack, Discord, Telegram, or a generic webhook, each with its own credential (webhook URL, bot token, etc.) and a selectable set of events to notify on (ticket created, resolved, staff reply, customer reply, SLA breach).
• Channels can be scoped to a specific department or left global.
• Delivery is best-effort per channel - a broken webhook can never block an email or another channel from sending, and a channel that fails repeatedly is automatically disabled with the reason recorded (never the raw error text, which can carry the webhook URL itself).
• The ticket thread also updates live over WebSocket for anyone with it open - new replies, status changes and SLA breaches appear without a refresh.

Reports

Support > Reports gives you SLA attainment for a date range and, optionally, a single department: first-response and resolution attainment percentages, average and median times, and a breach count. Attainment is computed directly from the actual due-date columns on each ticket rather than from timing-sensitive flags, so the numbers hold up even if a ticket was resolved just after a breach flag would otherwise have been set. A truncated indicator appears if the date range pulled more rows than the report's internal cap, so you know to narrow the range for an exact figure.

Settings and the kill switch

Settings > Support (folded into the main System Settings page) holds:

• Enabled - the kill switch for the entire customer-facing support surface. Turning it off hides ticket creation and the support nav from customers immediately; the admin panel and existing tickets stay fully reachable so staff can keep working the queue and find the toggle again.
• Auto-close hours and reopen days (see Lifecycle above).
• Attachment max size, storage backend and its credentials, and the ClamAV scan/fail-open settings.
• AI triage and AI triage on reply toggles.

Support is deliberately reachable even for suspended and unbilled accounts - support is how a customer disputes a bill or asks about a suspension - so the kill switch is the only way to take the whole system offline, not account status.

Team permissions

Two sets of permissions apply, at different levels:

Customer team members (a subuser of a customer account, gated under Team Management on that account):

Permission	Grants
support.view	View that account's support tickets and their conversations.
support.manage	Open tickets, reply, close and reopen, and manage linked resources.

Staff admins (your own team, gated under admin roles):

Permission	Grants
support.tickets.view	View the ticket queue, individual tickets, and the resource context card.
support.tickets.manage	Reply, change status/priority/department/assignment, and trigger a manual AI analysis.
support.settings.manage	Configure departments, SLA policies, notification channels and the settings tab above.
support.reports.view	View the SLA reports page.

Troubleshooting

A customer says they can't see support anywhere Check the kill switch (Settings > Support > Enabled). If it's off, the customer-facing surface is intentionally hidden; the admin panel is unaffected.

Attachments are being rejected Check the ClamAV socket is reachable and the fail-open/fail-closed setting matches what you want during a scanner outage - fail-closed will reject uploads outright if ClamAV itself is down.

A notification channel stopped sending Channels auto-disable after repeated failures. Re-enable the channel from Support > Notification Channels after fixing the underlying issue (an expired webhook URL or revoked bot token are the usual causes).

The resource context card shows "metrics unavailable" That one collector (a slave round-trip or a metrics backend query) failed or ran out of its time budget - the rest of the card still renders normally. Retry with Refresh, or check the resource's own page directly if the problem persists.

AI triage isn't producing notes Confirm the AI Assistant itself is configured and enabled, then check the support.ai_triage (and, if you expect re-runs on reply, support.ai_triage_on_reply) toggles under Settings > Support. A triage failure is logged rather than shown on the ticket, so check the admin logs if a note never appears after some time.