How to Implement a Task Tracker: From WhatsApp Tasks to a System

Almost every company in Kazakhstan that has grown to 10–15 people reaches the same point: tasks are assigned through WhatsApp voice messages, deadlines live in chat threads, and the manager finds out about a missed deadline when the client is already calling. In this situation, a task tracker gets bought quickly, and just as quickly it turns into a graveyard of tasks nobody updates.

The problem isn’t the tool. In our experience implementing trackers at IT teams, agencies and service companies, success comes down to four things that are done before the system is chosen. Below is the plan we follow for implementation and a table for choosing a tool.

Why implementations fail

Let’s look at the four typical scenarios we see during diagnostics.

The tool was chosen before the process. The manager read about Jira, bought a license and asked everyone to “log tasks.” A month later, the system has three hundred tasks without assignees or deadlines, because nobody agreed on what counts as a task, who creates it and when it’s closed.

There’s no owner. A contractor set up the system and then left. The statuses are outdated, new employees never got access, and the Git integration broke after an update. Six months later, the team is back in chats.

The scheme is too complex. Twenty statuses, eight work item types, required fields on every transition. The team spends more time filling in a task than doing it, and starts to quietly resist.

There are no rituals. The tracker exists, but planning happens verbally at a quick stand-up and nobody enters the results into the system. The board reflects reality a week late and stops being the source of truth.

Each of these scenarios is fixed during preparation, not after launch.

Step 1. Map the process and roles

Before choosing a tool, we answer five questions in writing, on a single page:

1. Where tasks come from: clients, the manager, the development plan, support.
2. Who has the right to create a task and who assigns the owner.
3. Which states a task goes through from creation to closure.
4. What “task closed” means: accepted by the client, deployed to production, paid for.
5. Which questions the manager asks every week, and which of them the system should answer.

An example for a 12-person product team: tasks come from the product backlog and from support, the product manager creates them, the team lead assigns the owner, the states are backlog, in progress, review, testing, done; closed means deployed and verified in production. Once a week, the manager wants to see what’s going into the next release and what’s stuck.

This document becomes the specification for configuring any tracker and the criterion for choosing one.

Step 2. Choose a tool

We compare tools on five criteria: does the model fit the process, where is the data stored, how much will it cost as the team grows, what integrations are available out of the box, and who will administer the system a year from now.

Tool	Best for	Strength	Limitation	Data in Kazakhstan
Jira Cloud	IT teams in the Atlassian ecosystem	Mature workflows, Marketplace, Jira Service Management	Price grows with the team, complex administration	No
Plane	Product and IT teams of 5 to 100+	Tasks, cycles and wiki in one, free self-hosted, Jira import	Young integration ecosystem, incomplete Russian localization	Yes, self-hosted
YouTrack	Developers using JetBrains tools	IDE integration, fast search, free for up to 10 people	Closed source, per-user pricing as you grow	Yes, self-hosted
Kaiten	Service teams and agencies	Kanban with limits, Jira import, Russian-language support	Unfamiliar model for people coming from Jira	No
Tasks in a CRM: Twenty or amoCRM	Sales and service without an IT team	Tasks right next to customers and deals	Weak model for development and releases	Twenty: yes, self-hosted. amoCRM: no
Trello	Small teams with a simple flow	Simplicity, quick start	No nesting, weak reporting	No

Two rules of thumb from practice. If the team includes developers and the data must be stored in the country, we start the comparison with self-hosted Plane. If the company runs sales in a CRM like Twenty or amoCRM and the tasks are mostly about customer service, a separate tracker is often overkill. We covered a detailed comparison of the two leaders for IT teams in our article Plane or Jira in 2026.

Kazakhstan context. A task tracker stores employees’ names, emails and correspondence, which is personal data. If it matters to the company to keep this data in Kazakhstan, cloud services with foreign data centers don’t meet that requirement, and for regulated industries this is the deciding selection criterion.

Step 3. A minimal workflow

The rule we apply in every implementation: at the start, no more than five statuses and no more than three work item types.

Status	What it means	Who moves it
Backlog	The task is recorded but not yet in the plan	Requester
In progress	An assignee is set and has started	Assignee
Review	Done on the assignee’s side, awaiting acceptance	Assignee
Done	Accepted by the client or deployed	Reviewer
Canceled	Won’t be done, reason in the comment	Requester

Required fields are kept to a minimum too: title, assignee, due date, priority. Everything else is added after the pilot, when the team itself says what’s missing.

If the process requires code review, testing and release, those states are added as a second step a month later, once the basic rhythm is working.

Step 4. Pilot with one team

We launch the system with one team of 8–20 people for two to four weeks. The pilot includes:

• migrating only active tasks, with old ones going to the archive;
• one hour of training using the team’s real tasks, not a demo project;
• a daily board check by the manager for the first two weeks;
• a list of the team’s questions and suggestions in a separate task.

After the pilot, we make three decisions: what to add to the scheme, what to remove and whether the system is ready for the other teams. If the pilot didn’t take hold, there’s no point scaling it, and it’s more honest to go back to step 1.

Step 5. Rituals and rules

A tool only works within the team’s rhythm. The minimum set, which we capture in a one-page policy:

• Planning once a week or every two weeks, using the board: what we take on, who owns it, when it’s due.
• A daily sync of 10 minutes: what’s stuck, who needs help. Statuses are updated before the meeting, not during it.
• Acceptance against the definition of done written in the task. Without that definition, the task isn’t taken into work.
• A retrospective once a month: what in the process gets in the way and what we change in the scheme.

And the main rule: a task exists only if it’s in the tracker. The manager accepts reports only through the system and asks “what’s the status of this task?” in comments, not in WhatsApp. After a month of consistent application, the conversation moves into the system on its own.

Step 6. Integrations and reporting

After the pilot, we connect whatever saves manual work:

• the Git repository, so commits and pull requests are linked to tasks;
• the CRM, so customer requests turn into tasks without copying;
• the team’s messenger, so notifications arrive where people already are;
• a management dashboard with three to five numbers, not twenty charts.

Metrics that show the implementation is working:

Metric	How to calculate	Benchmark after 2 months
Share of tasks in the tracker	Tasks in the system vs. tasks discussed in chats	Over 90%
Tasks without a due date or assignee	Share of all active tasks	Under 10%
Lead time	From start of work to done, median	Decreasing from sprint to sprint
Tasks in progress per person	Team average	No more than 3
Overdue tasks	Share of all tasks with a due date	Under 15%

Step 7. Scale up and hand over to an owner

The remaining teams are onboarded in waves of two or three at a time, with the same rules and training. We keep one common scheme: the same statuses and work item types across the whole company, so the manager sees a consolidated picture.

At this stage, an internal system owner is appointed. Their responsibilities: access, scheme changes, monitoring metrics and training new employees. Without this role, the system will start drifting away from reality within six months, no matter how good the setup is.

A typical six-week plan

Week	What we do	Outcome
1	Process map, tool choice, cost estimate	Decision and setup specification
2	Setting up projects, statuses, permissions and integrations, migrating active tasks	A working system
3–4	Pilot with one team, training, daily oversight	A validated scheme
5	Fine-tuning based on the pilot, management dashboard, policy	Ready to scale
6	Onboarding the remaining teams, appointing an owner	System in production

We take clients through this entire path, from the process map to the handover to an owner, including deploying Plane on servers in Kazakhstan or setting up Jira Cloud. Learn more on the Jira and Plane task tracker implementation service page.

Terms in plain words

Task tracker

A system for tracking tasks: who is doing what and by when. It replaces assignments in chats and shows the manager the real state of the work.

Workflow

The sequence of a task’s statuses from creation to closure, for example “backlog, in progress, review, done.” Five statuses are enough to start.

Backlog

A list of recorded tasks that haven’t been picked up yet. During planning, the team chooses from it what to work on next.

Sprint

A short period of team work, usually one to two weeks, with a list of tasks agreed in advance. Sprints make it easy to compare how the team’s pace changes.

Pilot

A trial launch of the system with one team for two to four weeks. Based on the results, you decide what to adjust before onboarding everyone else.

Retrospective

A regular team meeting to discuss what got in the way and what to change in the process. The article recommends holding one once a month.

Pull request

A developer’s request to add their code to the shared project. When the tracker is connected to Git, these requests are automatically linked to tasks.

Self-hosted

Installing the system on the company’s own server rather than in the vendor’s cloud. It lets you keep employee and customer personal data in Kazakhstan.