You define the statuses, priorities and fields.
Tickets are how you organise your work, as a plain list or on a kanban board. What properties a ticket has is up to you. Statuses and priorities are configured per project, and you add your own properties when your workflow needs more than open and done.
- 01 Your own statuses and priorities per project, plus self-defined properties on the ticket
- 02 Sub-tasks with a progress indicator on the parent ticket
- 03 Comments, assignments, tags, attachments and the full history in one place
- 04 List and kanban board on the same data, with filters across every property
- 05 On a long ticket you ask the AI about its history instead of reading forty comments
- 06 For developers: access from your development environment via MCP server. Read, create and comment on tasks, secured by a personal access token that can be limited to individual projects
How this works
Description, assignees, tags, attachments. Status and priority are the ones you defined for this project, not the ones we consider right. If your workflow needs another field, you add it.
List or kanban board, both on the same data, filtered by any property you assigned. What belongs together hangs below as a sub-task.
Comments, hours and attachments gather on the same task. Whoever sits in the editor need not leave it: through the MCP server the development environment reads, creates and comments on tasks directly.
At forty comments you ask the history rather than read it. The answer names the comments it came from.
What it does not do
Two things you would otherwise spend a fortnight looking for.
- Sub-tasks go exactly one level deep, and that is a decision rather than a gap. A sub-task has no sub-tasks of its own.
- Beyond that there are no relations between tasks. No "blocks", no "depends on", no links from ticket to ticket.
What people ask at this point
- What happens to the sub-tasks when I delete the parent?
- They stay, and afterwards they stand on their own. Nothing disappears because you tidied up, and you need not check what hangs off a task before deleting it.
- Can several people be on the same task?
- Yes. An assignment is not a single person, and the task still stays one task instead of splitting into a copy per participant.
- What exactly may the development-environment access do?
- Read tasks, create tasks, comment on them. Nothing else. No deleting and no status changes from outside, and the personal access token can be limited to individual projects.
Look at it
rather than take our word for it.
Productive in under 5 minutes. No sales loop.
Particular data protection or compliance requirements? Talk to us. For cases like that we usually find a way.