What SAQ is

SAQ keeps support, project work, and billable time on one ticket, so the same record is followed from the first email to the client's timesheet.

Written for
user, admin
Roles
Requires
Feature
docs

SAQ is a ticket system with project management, time tracking, and client billing. It is built around one object, the ticket. A support request, a planned piece of project work, and the hours you bill for it are not three records in three tools; they are one ticket, its comments, and the time logged on it.

The name is said like the Norwegian word sak, which is what a ticket is called in the Norwegian interface. The header writes the pronunciation as [saːk] beside the logo.

One ticket, three jobs

  • Support. An email to your connected mailbox lands in the shared Inbox as a ticket. A workspace user routes it to a project or merges it into an existing ticket. Replies from the client thread onto the same ticket, and the client can follow it with their own login.
  • Project work. A ticket on a project has a kind, a state on the board, a priority, an assignee, dates, labels, and an estimate. Larger pieces of work are parent tickets with children; SAQ has no separate epic or milestone object.
  • Billable time. Workspace users log time entries on the ticket. When the period is closed, the work facts are frozen. A billing run prices the time with the client's rate card and policies and produces the client timesheet, which shows the ticket's billing description, never its title or the internal notes.

Because everything hangs on the ticket, the question "what did we do for this client, and what does it cost" has one answer, and the client sees the same ticket the consultant worked on.

Who SAQ is for

  • Organisations that do work for clients and bill by the hour or by deliverable: consultancies, agencies, managed-service providers, and internal teams that charge other units. Their people are workspace users.
  • Their clients. Every client can have client users with their own login. A regular client user sees the tickets they started or were given access to. An elevated client user works on a project alongside the workspace users.
  • Integrations and AI assistants. Other systems use the REST API; assistants use the MCP server. Both act with an API token, either on behalf of a person or as an agent account.

What SAQ is not

SAQ deliberately leaves some things to other tools. Knowing this up front saves time.

  • No invoicing or accounting. A billing run produces client timesheets (HTML, PDF, CSV) with amounts excluding VAT. The invoice is made in your accounting system from that document.
  • No CRM. Clients hold users, contacts, billing recipients, and pricing; not pipelines, deals, or activities.
  • No timer. Every time entry is a date plus a duration, with an optional start time. Nothing runs in the background.
  • No planning or capacity module. There are no sprints, resource allocations, or availability calendars. Parent tickets, start and due dates, and estimates cover planning needs.
  • No timesheet approval workflow. Closing a period is the lock. There is no submit-and-approve step.
  • No webhooks. Notifications leave SAQ as email only. An integration reads changes through the API or MCP.
  • No teams, custom fields, or comment editing. Membership is per project; a comment stays as written.
  • No SAML. Single sign-on is OpenID Connect, with SCIM for provisioning.

Three doors into the same workspace

Door Who uses it What it is for
The app Workspace users and client users, in a browser Everything: tickets, boards, time, billing, settings
Email Clients and anyone writing to the connected mailbox New requests arrive in the Inbox; replies thread onto tickets; notifications and timesheets go out
API and MCP Integrations and AI assistants, with an API token Read and write tickets, comments, time, and documents; the MCP server for assistants such as Claude Code or Cursor

All three doors follow the same permission rules. An email correspondent, an API token, and a person in the app can never see more than the role behind them allows. See Documentation by role for what each role can do, and the integration developer overview for the API and MCP.

Where to go next

Read Core concepts for how workspace, clients, projects, tickets, time, and billing fit together, then First login to get into your workspace.

  • Core concepts How a workspace, its users, clients, projects, tickets, comments, time entries, periods, and billing relate to each other in SAQ.
  • First login Accept your invitation, choose a login method, set up two-factor authentication if you are an Owner or Admin, and find your workspace.
  • Documentation by role How workspace role, client user mode, and project role combine into what a person can do in SAQ, with the full permission matrix and a page for each role.
  • Terminology Every product term in SAQ with a one-line definition and a link to its concept page, plus the words SAQ does not use and what to look for instead.
  • Integration developer overview What you can connect to SAQ, what does not exist, where the OpenAPI document is, and a five-minute first call with an API token.