Getting started with KAMI Tasks
KAMI Tasks is KAMI's project and work management module: tickets, sprints, boards and reports for any team's work — development, HR, operations or anything else. This is a map of where things are and how they fit; each screen has its own article.
Where: Tasks in the main menu
The idea in one paragraph
Work is recorded as tickets. Tickets belong to a project, which gives them a key like KDV-123 that never changes. Tickets are planned into sprints — short, fixed periods — and grouped under epics for larger initiatives. You work your sprint from the board or the List, watch your own workload on My Work, and read how it went in Insights.
The two things worth knowing early: access comes through groups, never individuals, and the ticket key is permanent — so a project's slug is a decision you make once.
Where to go for what
| My Work | What needs you today |
| Kanban board | Working the sprint |
| List and Timeline | Bulk changes, and work over time |
| Tickets | Creating and editing the work itself |
| Projects and Sprints | The containers |
| Users and groups | Who is here, and what they can reach |
| Templates | Reusable tickets for repeated rituals |
| Insights and Timelog | How it went, and where time went |
| KAMI PM | The AI project manager |
| Notifications and Automations | Being told what matters |
If you are using it day to day
- Check My Work each morning — overdue, due today, blocked.
- Work the board during the day, moving cards as work moves.
- Log your time as you go, so estimates and reports mean something.
If you are setting it up
In this order — each step depends on the last:
- Create a project — its slug becomes every ticket key, permanently
- Organise people into groups and grant the groups access
- Create your first sprint, with dates and a goal
- Optionally set ticket standards, so every ticket is written the same way
- Optionally connect GitLab, Slack or Claude Code