Task Tracker for IT Departments: Requests, Incidents and Projects

A task tracker for an IT department needs to hold three different streams of work: user requests, incidents, and projects and changes. Each stream has its own task type, statuses and deadlines. If you dump everything onto one board, the urgent crowds out the important, and the IT lead cannot say what the department is busy with. If you separate the streams, one system is enough, without a separate helpdesk, a separate tracker and a spreadsheet of projects.

This article is for IT department heads and team leads of in-house teams in Kazakhstan. We cover how to set up the streams in Plane or Jira, how to take in requests, agree on SLAs, organize on-call duty and build a report for management. At the end we list the signs that a task tracker is no longer enough and you need ITSM.

The three streams of IT department work

An in-house IT department works in three modes at once.

Requests. A user asks for something: grant access, set up a laptop, connect a printer, export a report. The work is small, repetitive and there is a lot of it. What matters is response time and making sure no request gets lost.

Incidents. Something broke: email is down, the accounting system does not work, the VPN is down, the website returns an error. The work is unpredictable and urgent. What matters is quickly finding an owner, restoring the service and then analyzing the cause.

Projects and changes. Moving to a new server, implementing a system, upgrading the network, improving an internal service. The work is planned, long and has dependencies. What matters is deadlines, milestones and transparency for the internal customer.

The typical picture in a department without a system: requests come through WhatsApp, email and verbally in the hallway, incidents are handled in a group chat, and projects live in the IT lead’s spreadsheet. In our implementation experience, the first tangible benefit of a tracker comes not from automation but from all three streams being visible in one place for the first time.

Task types, statuses and deadlines by stream

The foundation of the setup is a separate task type for each stream. In Plane these are Work item types; in Jira, issue types with their own workflows. The scheme we usually start with:

Stream	Task type	Statuses	Deadline and SLA
Requests	Request	New → In progress → Waiting for user → Resolved → Closed	Response and resolution by priority
Incidents	Incident	Logged → Diagnosis → Restored → Review → Closed	Response in minutes, restoration in hours
Recurring outages	Problem	Open → Root cause analysis → Fix → Closed	No strict SLA, reviewed at the weekly meeting
Changes	Change	Requested → Approved → Scheduled → Done → Verified	Maintenance window and approval
Projects	Task, epic	Backlog → In progress → Review → Done	Milestone and cycle deadlines

A few principles.

• Fewer statuses than you would like. Five or six per type are enough. Every extra status is a place where a task will get stuck.
• A “Waiting for user” status is mandatory for requests. Without it, waiting for a reply eats into the SLA, and engineers start closing requests without waiting for confirmation.
• An incident and a problem are different entities. An incident is closed when the service is restored. A problem is closed when the cause is eliminated. Recurring incidents are linked to a single problem.
• Changes to production systems go through approval. Even if there is only one approver, the approval is recorded in the task.

The logic of priorities and deadlines for product bugs works the same way; we covered it in detail in our article on bug tracking, workflow and fix SLAs.

Request intake: one entry point instead of five

The main rule: work starts only with a task. A messenger message, a call or a hallway conversation is a reason to create a task, not the task itself.

Intake channels:

1. Form. A short form with fields: what happened, who the requester is, department, urgency, attachment. In Plane this is Intake: requests from a form or an email address go into a separate queue, where the on-call engineer accepts or rejects them.
2. Email. A dedicated address for requests. The email becomes a task, and the conversation stays in its history.
3. Messenger. The on-call engineer moves requests from WhatsApp and Telegram into the queue manually or via a bot. The reply to the user is a link to the task or the request number.

Intake is useful because it keeps raw requests out of the working backlog. Triage comes first: confirm it really is an IT task, set the type and priority, assign an owner. Only then does the request go into the project.

Kazakhstan context. In most Kazakhstani companies, employees are used to writing in WhatsApp, and banning it will not work. A workable compromise: the messenger stays a communication channel, and the task is the only place where work is tracked. Make the intake form available in Russian and Kazakh if the company has employees who are more comfortable in Kazakh. And remember that requests can contain names, phone numbers and sometimes employee documents. If the company wants to keep such data in Kazakhstan, a self-hosted tracker on a server in the country will do; cloud services that store data abroad will not.

Priorities and SLAs

An SLA is an agreement with the business, not an internal department goal. So the values are agreed with company management and published for all employees.

Priority is determined by two questions: how many people are affected, and is there a workaround. An example starting matrix, which you then adjust to real data:

Priority	When to set	Response	Resolution
P1 Critical	A service is down for the whole company or a key process, no workaround	15 minutes	4 hours
P2 High	A department or executive is affected, the workaround is inconvenient	1 hour	1 business day
P3 Normal	One user, a workaround exists	4 hours	3 business days
P4 Low	A wish, a planned configuration	1 business day	As planned

The values in the table are a starting benchmark, not a norm. After a month, look at actual response and resolution times and adjust. An SLA that is breached every day disciplines nobody.

How to track SLAs in practice. Jira Service Management has built-in SLA timers with a business-hours calendar. In Plane, and in Jira without the service module, SLAs are tracked through the task due date, priority and automations: the due date is set during triage according to the priority table, scheduled automations (Runner in Plane, Jira Automation in Jira) remind the owner about tasks approaching their deadline, and a dashboard shows overdue items. For a department of 10–30 people, this setup is usually enough.

Incidents and on-call duty

An incident needs an owner in the first minutes. So the department needs an on-call engineer, and the tracker should show who is on call today.

How we set it up:

• The on-call schedule is kept on a page in Pages or in Confluence. The on-call engineer is assigned all new incidents during their shift.
• Notifications. A new P1 incident goes immediately to the on-call engineer and the team channel via the Slack integration or a messenger bot.
• Incident handling. The task records the start time, affected services, actions taken and restoration time. Comments are written as things happen, not after the fact.
• Review. After restoration, a short review on a page linked to the incident: what happened, why, and what we will do to prevent it from recurring. Actions from the review become tasks with an owner and a due date.
• Escalation. If the on-call engineer has not picked up the incident within the response time, the IT lead is notified. This is set up with automation or fixed in policy.

If incidents recur, create a task of type “Problem” and link all similar incidents to it. Then you can see that the Monday VPN outage is not five different stories but one cause that needs to be fixed.

Projects and changes alongside operations

The most common complaint from IT leads: projects do not move because the team is drowning in requests. A tracker does not solve this on its own, but it makes the problem visible.

What helps:

• A separate project for requests and incidents. Operations live in their own project and do not mix with project work. Projects are split into Modules and Cycles in Plane, or epics and sprints in Jira.
• A quota for operations. Agree on what share of time the team gives to requests and incidents. The rest goes to projects. Time tracking in tasks shows whether the quota holds.
• Rotation. One or two engineers handle requests each week, and the rest work on projects. This reduces context switching.
• Changes through approval. Any work on a production system is filed as a “Change” task with a maintenance window and a rollback plan.

Metrics and the report for the IT lead

The report for the IT lead answers three questions: is the department keeping up with the flow, where are the fires, and where does the time go. In Plane it is built in Dashboards; in Jira, in dashboards based on JQL filters.

Metric	What it shows	How often to review
Incoming request volume by week	Workload and seasonality	Weekly
First response time by priority	Intake speed	Weekly
Resolution time by priority	Speed of work	Weekly
SLA breach rate	Meeting commitments to the business	Monthly
Open requests past their deadline	Forgotten loose ends	Weekly
Repeat incidents by service	Weak spots in infrastructure	Monthly
Share of time on projects vs operations	Quota adherence	Monthly
Status of key projects	Progress on initiatives	Every two weeks

Do not build a report with thirty metrics. Five to eight are enough to see the workload and talk to management about resources based on facts rather than impressions.

When a task tracker is not enough and you need ITSM

A task tracker with properly configured streams covers the needs of most small and mid-sized IT departments. But there are signs it is time to look at an ITSM system, such as Jira Service Management:

• you need a self-service portal with a service catalog where users choose a request type and see its status;
• the SLA is fixed in policy and requires timers that account for business hours, holidays and pauses;
• support is provided to external customers, not just employees;
• you need a knowledge base that users see before creating a request;
• change and problem processes are formalized and go through internal audit.

If two or three of these apply to you, ITSM is justified. If not, a separate system will add an extra interface and extra licenses. Project work can stay in the task tracker and be linked to requests.

Keep timelines and data location in mind. Atlassian’s cloud products store data in regions that do not include Kazakhstan. Data Center has not been sold to new customers since March 30, 2026, and support ends on March 28, 2029. If the requirements for in-country data storage are strict, request intake via Intake in self-hosted Plane often turns out to be more practical.

How we do it

We start with a diagnostic: which streams actually exist in the department, where requests come from, which agreements with the business already exist and who will administer the system a year from now. Then we run a two- to four-week pilot with one team, usually on the request stream. Based on the results, we refine statuses, priorities and SLAs and only then move incidents and projects over. The general implementation process is described in our article on how to implement a task tracker in a company.

If you want to bring order to your IT department’s work, see our Jira and Plane task tracker implementation page: it describes the process, timelines and what is included in the result.

---

Sources. Data Center timeline: atlassian.com/enterprise/data-center. Atlassian Cloud data residency regions: Atlassian documentation. Plane repository: github.com/makeplane/plane.

Terms in plain words

SLA

A response and resolution deadline agreed with the business, depending on request priority. It is published for all employees and revised based on actual data.

Incident and problem

An incident is a specific outage; it is closed when the service works again. A problem is the common cause of recurring outages; it is closed when the cause is eliminated.

ITSM

A class of systems for IT service management: an employee portal, service catalog, queues and deadline timers. Needed by large departments with formal policies; small ones are often fine with a tracker.

Intake

Plane's queue of incoming requests, where they arrive from a form or email. The on-call engineer reviews them first, and only then does a request go into work.

Triage

The initial review of a request: confirm it is an IT task, set the type and priority, assign an owner. It keeps raw requests out of the working list.

Escalation

Passing a task to a higher level if it was not picked up in time. For example, the IT lead is notified when the on-call engineer has not responded to a critical outage.

Self-service portal

A page where an employee chooses the request type and sees the status of their request. One of the signs that the department already needs an ITSM system.

Self-hosted

A tracker on the company's own server. If requests contain employee data, installing it on a server in Kazakhstan keeps the data in the country.