KAMI Tasks
4 articles in KAMI Tasks
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 article is a tour of the main…
Read article →KAMI PM, your AI project manager
KAMI PM is the AI built into KAMI Tasks. It reads your projects and does the project-management legwork — answering questions, drafting whole project plans, flagging risks, writing the weekly report…
Read article →My Work: your daily view
My Work is your personal landing page in KAMI Tasks. It answers one question — what needs my attention today? — without you having to trawl boards or filters.
Read article →Notifications in KAMI Tasks
Two things live under this name: the notifications inbox — everything that happened that involves you — and the preferences that decide how each kind of event reaches you.
Read article →Tickets
Creating and editing tickets
A ticket is one unit of work: a bug, a task, a story. This article covers creating one, the fields that matter, and what lives on the ticket page.
Read article →Epics, subtasks and linked tickets
Tickets rarely stand alone. KAMI Tasks gives you three ways to relate them, and each answers a different question.
Read article →Estimates and logging time
KAMI Tasks tracks two different kinds of "how big": story points for sizing, and time for hours actually planned and spent. You don't have to use both, but everything downstream — My Work's remaining…
Read article →Statuses, priorities and ticket types
Three small vocabularies do most of the organising in KAMI Tasks. Getting them straight — especially the difference between a status and a column — saves a lot of confusion.
Read article →Planning
List and Timeline views
The board is for working a sprint; these two views are for everything the board is bad at. The List is every ticket as a table you can slice and bulk-edit. The Timeline lays work out over time.
Read article →Projects and access
A project is the container everything else sits in: its tickets, sprints, epics and board all belong to one project. Projects are also where access is decided — people see a project through the…
Read article →Sprints
A sprint is a short, fixed period — usually one to four weeks — in which your team commits to a set of tickets. The Sprint Manager is where sprints are created and moved through their lifecycle.
Read article →The Kanban board
The board is where a sprint gets worked: every ticket as a card, in columns that mirror your workflow. Drag a card to move it; the board is the ticket's status, made physical.
Read article →Ticket templates
Templates are reusable tickets, organised by epic, that you can drop into any sprint. If your team runs the same checklist every cycle — a release ritual, onboarding steps, a monthly close — build it…
Read article →Reports
Sprint Insights
Insights is the reporting page for sprints: how the current one is going, how past ones went, and where the workload actually sits. Pick a sprint at the top and the page reads on it.
Read article →Timelog
The Timelog is the company-wide view of time logged in KAMI Tasks: every work-log entry, summarised and sliceable. Where a ticket's work log answers "what was spent on this ticket?", the Timelog…
Read article →Settings
Automations
Automations are the rules that chase things so a person doesn't have to: a ticket goes blocked and someone is told, a critical ticket sits unassigned and someone is told, a sprint end approaches and…
Read article →Importing tickets from a spreadsheet
Moving to KAMI Tasks from another tool — or from a planning spreadsheet — doesn't mean retyping the backlog. The import takes a spreadsheet and turns its rows into tickets.
Read article →Integrations: GitLab, Slack and Claude Code
Integrations connect KAMI Tasks with your development tools so tickets stay in sync automatically — code activity lands on tickets, ticket activity lands in Slack, and an AI assistant can work your…
Read article →Ticket Standards
Ticket Standards are your company-wide rules for how tickets are written — one format for titles, one structure for descriptions, applying to every ticket type in every project. They exist so a board…
Read article →Users and groups
People reach KAMI Tasks through two layers: users — everyone in your organisation who can be assigned work — and groups, the teams they are organised into. Groups are what projects actually grant…
Read article →