A ticket with a status, a priority and an owner, sitting on the same list toolbar as every other module. Replies stay on the record instead of scattered across email threads.
Included from Pro upwards
A subject, an optional category (General, Bug, Feature Request, Billing, Access, Other), a priority and a description are all it takes to raise one.
Open, In progress, Waiting, Resolved and Closed, grouped and filterable on the same list toolbar, columns and CSV export every other module uses.
An owner or admin sets the status, priority and assignee from the ticket’s detail view. The person who raised it can close their own ticket at any time while it is open.
Replies form a threaded conversation on the ticket itself, each one timestamped and attributed, visible to the requester and to staff.
KPI cards for Open, In progress, Resolved and Total sit above the list, with an attention bar that flags tickets still waiting on a first response.
A support-domain agent can read the queue and propose replies or actions, approve-first: a person still clicks approve before anything is sent.
The part you would otherwise find out in week three. If one of these is central to how you work, raise it before you buy rather than after.
The ticket’s requester and any owner or admin. Admin controls (status, priority, assignee) are limited to owners and admins; the requester can only close their own ticket.
Not today. Ticket events are not yet part of the Automations trigger library, so you cannot wire a rule to fire the moment one is created or its status changes.
Yes. The standard Support Agent role template scopes a person to this page rather than the whole workspace.
No. Tickets are read and replied to from inside your workspace. There is no separate customer portal today.
The full product documentation for this module is at /docs/modules.
Free for up to 5 seats, no card required. Every module is in the same workspace, so nothing needs connecting to anything.