Skip to main content
Tickets are the core unit of work in Regentra’s PSA. Every client interaction — whether it starts as an email, portal submission, live chat, or SMS — becomes a ticket that flows through a defined lifecycle.

Ticket lifecycle

1

Open

Ticket is created and awaiting triage or assignment.
2

In Progress

A technician is actively working the ticket. SLA response timer stops when the first reply is sent.
3

Waiting on Customer

The technician has replied and is awaiting a customer response. SLA resolution timer pauses in this state.
4

Escalated

Ticket has been escalated to a senior technician or team lead due to complexity or SLA risk.
5

Resolved

The issue is fixed. The ticket auto-closes after 24 hours if the customer does not reopen it.
6

Closed

Terminal state — work is complete and SLA timers stop accruing. A technician can manually reopen a closed ticket from the status dropdown if the customer comes back, and an inbound customer reply on a closed ticket spawns a linked follow-up ticket.
Resolved and Closed tickets display with muted status badges to visually distinguish them from active work.

Creating tickets

Tickets can be created through five channels:
ChannelHow it works
ManualTechnician creates a ticket from the PSA dashboard
Email inboundEmails sent to your support address automatically create tickets
PortalCustomers submit tickets through the branded support portal
Live chatChat conversations convert to tickets when the session ends
SMSInbound SMS messages create tickets (requires phone number configuration)

Ticket detail page

Each ticket includes:
  • Replies — Threaded conversation between technician and customer
  • Internal notes — Private notes visible only to your team
  • Time entries — Logged time with billable/non-billable designation
  • SLA badge — Real-time SLA status (On Track, At Risk, Breached, Met)
  • AI draft — AI-generated reply suggestion based on ticket context and knowledge base articles
The AI draft pulls from your knowledge base using RAG. The more KB articles you maintain, the better the draft quality.

Priority is customer-controlled

The priority chosen at ticket creation is the source of truth across the system. The AI auto-analyzer reads priority for context and may suggest a different value (visible on the ticket sidebar), but it cannot change ticket.priority on its own — not up, not down. Customer-set CRITICAL stays CRITICAL. Priority changes after creation happen only through:
  • Operator edit on the ticket detail page
  • Operator-authored automation rules (Settings → Automations) using the Change Priority action
  • Policy escalations — VIP override, ticket-spike pattern, and AI security/frustration escalation can each bump LOW/MEDIUM → HIGH, never downgrade
See Automations & AI for the full matrix.

Board view vs list view

Kanban-style columns organized by ticket status. Drag tickets between columns to update status. Best for visual triage and daily standups.
Filter tickets by status, priority, assignee, client, SLA status, or date range. Combine filters to narrow results. Full-text search covers ticket subjects, descriptions, and reply content.

Auto-close behavior

Tickets in Resolved status automatically transition to Closed after 24 hours. If a customer replies to a resolved ticket within that window, the ticket reopens to In Progress.

Master and child tickets

When the same incident affects several customers — a vendor outage, a regional ISP problem, a phishing wave — promote one ticket to a master and link the rest as children. The master’s status, assignee, and resolution cascade to its children on demand: when you flip the master to RESOLVED or CLOSED, you’re prompted to apply the same status to every linked child (resolved/closed children are left alone so a previously-fixed customer isn’t yanked back into a queue). Mark a ticket as a master from the Linked Tickets section on the ticket detail page; link or unlink children from the same panel. Master and child tickets are first-class — they appear in board view, list view, reports, and SLA tracking like any other ticket. Use cases:
  • Vendor outage: open one master ticket against the vendor, link every customer ticket reporting the outage. One reply on the master can be cascaded to all children.
  • Phishing wave: one master incident ticket; each reported phishing email becomes a child, so the response team works one timeline instead of dozens.
  • Site-wide maintenance: master for the maintenance window, children for any customer who logs an issue during it — closes the loop when the window ends.