The Task Management Guide: Introducing It to a Team That Has Never Had It

Teams reach for task software for different reasons, and the reason determines what "working" looks like three months later. Be specific before you configure anything.

• Work goes missing. Requests are made verbally or in chat and nobody can say what is outstanding. Your first job is intake and ownership.
• Work is late and nobody knew. Things are assigned but their state is invisible until a deadline passes. Your first job is status and due dates.
• Work stops when someone is away. Knowledge and queues both live with individuals. Your first job is department queues and handovers.
• The routine quietly stops happening. Repeated work has no requester chasing it, so it slips. Your first job is recurring schedules.

If you want the conceptual grounding first — what a task is, what ownership means, how priorities and due dates differ — read What is task management? and come back. This guide assumes you already agree with the idea and want to know how to land it.

1. 01Departments first. They decide who is eligible for which queue and how reports group. Creating them after people means reassigning everyone.
2. 02Roles second. Build them from the permissions people actually need, not from job titles. Someone who needs to read reports should get the report permission, not an admin role.
3. 03People third. Add them, or import a staff list in one pass. Everyone gets a role and a department at the moment they are created.
4. 04Task forms fourth. One form per request type you handle regularly. This is the step most teams skip and most regret.
5. 05Recurring schedules fifth. Turn the work that repeats into schedules before anyone re-types it manually again.
6. 06Notifications last. Switch them on once there is something worth being notified about, so the first messages people receive are useful rather than noise.

The whole sequence is usually one afternoon for a team of twenty to thirty. It is not a project, and treating it as one is itself a risk — a rollout with a steering group attached rarely survives contact with a busy week.

The title is an instruction, not a topic

"Invoices" is a topic. "Fix the pagination on invoices over 50 line items" is a task. The difference is that the second one can be finished, and therefore can be judged finished.

Capture the detail as fields, not as prose

If the first three comments on most of your tasks are "which site?", "what is the order number?" and "who approved this?", those are three missing fields. Put them on the task form and they stop being questions permanently — and because they are typed fields rather than sentences, they can also appear in the notification and in a report.

Give it a date, and mean it

A due date on everything is the same as a due date on nothing. Use dates where something genuinely depends on the timing, and use priority for relative urgency. They answer different questions: priority says what to do next, a date says when it stops being acceptable.

Assign it to one person, or to a team on purpose

Naming an individual is right when you know who should do it. When you do not, raising it for a department is better than guessing — the request goes to everyone eligible, and the first person free claims it. What is never right is addressing it to nobody and hoping.

Do not migrate

The instinct is to move existing work in so that everything is in one place. Resist it. Migrating means a day of data entry followed by two systems running in parallel, and the old one always wins because it already has everything in it. Let in-flight work finish where it started and raise only new work in the new system. Within three weeks the old one is empty by attrition.

Keep the channel, move the record

If your team lives on WhatsApp, do not ask them to stop. Pair your own number and let task creation, handover and completion notifications arrive where they already read. What changes is that the state of the work lives on the task rather than in the thread — the alert is disposable, the record is not.

Announce one rule, not a policy

One sentence works better than a training session: "from Monday, if you want someone to do something, raise it as a task." Everything else — statuses, reviews, reports — can be learned by doing. A policy document is read once, by the person who wrote it.

Managers have to go first

The fastest way to kill a rollout is for a manager to keep assigning work by message. Staff will correctly conclude that the system is optional. The fastest way to secure one is for the manager to reply to a verbal request with "raise it as a task and I will pick it up" — twice.

1. 01Week one — raise everything. All new requests become tasks. Nothing else changes. Expect the tasks to be badly written; that is fine and it corrects itself.
2. 02Week two — notifications on. Creation and handover alerts to the channel the team reads. This is usually the week adoption becomes self-sustaining.
3. 03Week three — schedules and forms. By now you know which requests repeat and which questions keep being asked in comments. Turn the first into schedules and the second into fields.
4. 04Week four — look at the numbers. Overdue Tasks and Workload first, then acceptance time. Do not draw conclusions about people from four weeks of data; do draw conclusions about queues.

A task list assumes each item is independent. Plenty of business work is not: a purchase has to be approved before it is placed, a repair has to be checked before it is signed off, a complaint has to be resolved by somebody other than the person who caused it. That is workflow, and the distinguishing feature is that the system refuses the steps which break the sequence.

Workflow management covers that territory — and Task management vs workflow management covers where the boundary actually sits, which is less obvious than the two names suggest.