Project management and boards

The problem

Project tools built for large organizations need a configuration phase before the first task can be created, and they still know nothing about which client is paying or who may see what. Small teams either over-invest in setup or fall back to a shared document that nobody updates.

How SAQ solves it

A project in SAQ is the collaboration boundary: it has members, a default billing client, optional collaborating clients, and a board. It is created in a minute. Everything else you need, states, kinds, priorities, and labels, is already there at the workspace level and can be changed later without migrating anything.

What you get

Project board

Columns are your workflow states. Drag and drop with the mouse, or move cards with the keyboard and a menu. Filters for assignee, viewer, priority, kind, label, client, and due date (overdue, due this week, none).

Workspace board

The same layout across every project you can see, plus the shared Inbox column for untriaged mail.

Ticket list and search

A filterable table view of the same tickets, and full-text search that only returns what you may read.

Epics and milestones

A parent ticket with children is an epic. A parent ticket with a due date is a milestone. Estimates, time spent, and child state counts roll up from the children you may see.

Dependencies

Blocks and blocked-by links between tickets, with cycle detection. Blocked tickets and their blockers appear in the context pack the API exposes.

My work

Assigned to me, reported by me, watching, and due soon. One page per person, kept current.

Moving between projects

A ticket moves with its conversation, links, and time. If the move would change which client sees it, SAQ refuses unless an owner or admin confirms.

Roles

Project managers and members. A workspace member sees the projects they belong to; owners and admins see all.

Key benefits

• Create a project and start working in the same minute
• One board layout for your team and for elevated client users, each seeing their own scope
• Breakdown and dependencies without a planning module
• Estimate against actuals per ticket and per epic
• A personal work list that does not need a saved filter

Typical use cases

• A website project for one client. The client's project manager is elevated on the project, assigns and comments internally, and sees only that client's tickets and shared or internal comments.
• One project, two clients. Two clients share a project. Each client's users see only tickets billed to their own client unless they are explicitly added as viewers, and the team can use staff comments to discuss one client without the other reading it.
• Quarterly plan. A parent ticket per initiative with a due date, children per deliverable, and the rollup showing spent against estimate.

Why this is simpler

SAQ has one workflow per workspace and one board per project. There are no custom fields, no board schemes, and no permission schemes to design. What SAQ does have, and most project tools do not, is knowledge of which client each ticket belongs to, so visibility and billing follow automatically.