Operate

Service desk

Tickets arrive from email, the client portal, alerts and technicians, and land in one queue with SLA tracking that you can turn off for clients who do not have one.

Where tickets come from

• Email: connect a support mailbox (per-tenant IMAP) and inbound mail becomes tickets. Replies thread onto the right ticket via the [Ticket #ID] subject tag, and duplicate webhook deliveries are de-duplicated.
• Client portal: end users submit requests, or describe the problem to Ask Helio, which investigates first and raises a well-written ticket if a human is needed.
• Alerts: criticals, security findings and backup failures auto-ticket per the noise policy.
• Manual and API: technicians, or your own systems via the public API.

Working a ticket

Tickets carry status, priority, category, assignment and a full comment trail. Public comments email the client contact; internal notes never leave the team. Tickets link to the device they concern, so the live device state is one click from the conversation. Helio can draft replies and propose fixes on email tickets; how autonomous that is allowed to be is a per-tenant setting.

SLAs, honestly

Response and resolution targets are tracked per priority, with per-client overrides. Two honest details: breach and due-soon states are surfaced on the dashboard before they happen, not after; and clients without an SLA can have SLA tracking switched off entirely, so internal or best-effort clients never generate fake urgency.

Internal work

Tickets categorised as internal are for MSP operations and never appear on any client-facing surface or email. Your own housekeeping does not leak into a client's portal.

Reports and QBRs

Scheduled email reports summarise each client's health, tickets and patching on a cadence you choose, built to render in real inboxes. Quarterly, the QBR generator drafts a business review per client that you edit and print.