Ticket management

The problem

Small teams end up with support in one tool, project tasks in another, and bugs in a third, because each tool was built for one kind of work. A support request that turns out to be a bug gets re-created by hand, loses its history, and is billed differently from the work it caused. Nobody has one list of what is open for a client.

How SAQ solves it

SAQ has one ticket type. Its kind says whether it is support, a bug, planning, or implementation, and you can add kinds of your own. Changing the kind changes nothing else: the conversation, attachments, time entries, and links stay. Every door into SAQ opens the same ticket page: email, the board where tickets sit in columns by state, the filterable ticket list, search, and the API.

What a ticket has

Id

A stable, readable id with your prefix, like ACME-184. It works in email subjects and commit messages, and old ids keep resolving if you change the prefix.

Kind and priority

Configurable lists per workspace. Priorities are ordered and boards sort by them. One kind is the default for tickets created from email.

Workflow state

Your own ordered states, each marked open or closed. The defaults are backlog, to do, in progress, review, and done.

Assignee and viewers

One assignee. Any number of viewers, including client users. The reporter is always a viewer.

Description and conversation

A Markdown description, then an append-only thread of comments, emails, and system events, with a filter for comments only or activity only.

Comment audiences

Every comment is shared (everyone on the ticket, including the client), internal (your team and elevated client users on the project), or staff (your team only). The composer shows the audience before you post.

Dates and estimate

Start date, due date, and an estimate in minutes on leaf tickets. Parent tickets show the sum of their children.

Labels and links

Workspace-defined labels. Links: parent and child, blocks and blocked by, relates, and duplicates.

Attachments

On the ticket or on a comment. Files are quarantined and checked before anyone can open them.

Billing fields

Billing client, billing policy, billing mode, and a client-facing billing description that appears on the timesheet instead of the raw title.

Key benefits

• One list of open work per client, across support and projects
• A support request becomes project work by changing its kind, with its history intact
• Clear ownership: one assignee, visible on every board card
• Clients see their tickets and shared comments, never internal notes
• Configurable in minutes, not weeks: rename states and kinds, add labels, and go
• Every change is a system event on the ticket, so you can see who did what

Typical use cases

• Support desk. Mail arrives in the shared Inbox, is triaged to the Support project, answered in a shared comment, and closed. A reply within 14 days reopens the ticket; a later reply becomes a new linked ticket.
• Bug that came from support. The support ticket is re-kinded to bug and moved into the Website project. The client keeps following it. The time logged on it follows the billing policy for bugs, which may be free under your agreement.
• Internal work. Meetings, admin, and absence are tickets in an internal project with no billing client, so the weekly grid reconciles to a full week.

Why this is simpler

Tools that separate support from projects need integrations, duplicate records, and rules for keeping them in sync. SAQ does not have that problem because there is nothing to sync. The cost is that SAQ has no per-project custom workflows in the first version: one workflow per workspace, which for small teams is what they wanted anyway.