In brief: A Job Task sits inside a Deliverable with one due date, and each person on it gets their own service type and LOE.

Applies to: Anyone working on an Active Job. Job Tasks cannot be created while a Job is still Pending.

See also: Deliverables: Status, Due Dates, and Confidence Explained covers the unit tasks live inside, and Which Tasks Can Accept Time (and Which Cannot) covers which rows will take a timer.

Job Tasks live inside Deliverables. A task is one real thing that happens, with one due date, and as many people on it as it actually took. Each person on a task gets their own allocation: their service type and their own LOE in hours. The task's LOE is the sum of those allocations, never a separate number you type. Everything on the row edits in place, so you click a value and change it rather than opening a form.

You'll find them under Jobs → your Job → Tasks.

Where Job Tasks live

Every Job Task sits inside a Deliverable, the unit described in Deliverables: Status, Due Dates, and Confidence Explained. Open the Tasks tab, expand a Deliverable, and its task table is right there.

Work that belongs to the Job rather than to any single Deliverable lives in General Job Tasks, the grouping at the bottom of the Tasks tab. Kickoff coordination, status calls, client wrangling: real work, real time, just not attached to one promise. General Job Tasks behave exactly like Deliverable tasks in every way that matters. They take assignees, LOE, due dates, chat, and time.

Work that has no Job at all is a different animal, and Quick Tasks vs Job Tasks vs My Lists: Which to Use draws that line.

One task = one real activity

This is the mental model worth getting right, because it explains everything else.

A task is one thing that actually happens. A kickoff meeting is one task, even if three people attend and it touches both Strategy and Project Management. One task, three people, three allocations, one due date.

The alternative, splitting that meeting into three tasks so each person has their own row, is how most tools work and it is how effort data becomes useless. You end up with a task list that describes your software instead of your week. We put numbers on what that costs a firm in how poor task management drains agency productivity.

The task row

Left to right, a collapsed task row carries:

• Task name, click it to edit in place
• Status, sitting under the name as a dropdown
• Description, a one line preview
• Chat, the conversation indicator for this task, part of the wider structure in Chat Layout: Stream, General, Job Channels, and DMs
• Assignee(s), as avatars
• Service Type
• Due Date, one per task
• LOE, the total in hours
• Repeat, on Retainer Jobs only
• ⋮, the actions menu

A Draft badge appears next to the name when the task is not fully defined yet.

Display first, edit in place

Nothing on the row looks like a form until you touch it. Click the name and it becomes an input. Click the status and you get the dropdown. Click the due date and you get the calendar.

The heavier fields, description and the assignee allocations, live in the row expansion. Click the caret and they open underneath without the row jumping around. Interacting with anything inside the expansion will not collapse it.

Assignees and allocations

Expand a task and you get an allocation row per person. Each one holds:

• Assignee
• Service Type
• LOE (hrs)
• A progress meter showing that person's logged time against their own LOE

Use + Assignee to add another row. Use the ⋮ on an allocation row to remove one.

Two rules worth knowing

Task LOE is derived, not stored. The Xh on the collapsed row is the sum of every allocation's LOE. There is no separate task level number to keep in sync, which means it can never disagree with the allocations underneath it.

Service types have to exist on the Deliverable. An allocation can only use a service type that the Deliverable already has an effort pool for, chosen from your workspace's Service Types and Service Groups. This is the one structural gate in the task surface. Hours are never capped, but you cannot invent a category of work mid-flight that was never planned for.

Statuses

Four values, set by hand:

• Backlog, planned, not started
• In Progress, underway
• Completed, finished
• Archived, out of the active views

Two things happen quietly behind those changes. The first move to In Progress stamps the task's start. The move to Completed stamps its completion. Neither gets overwritten if you flip the status back and forth later, so the original dates survive a reopened task.

Archiving individual tasks is housekeeping, not a daily habit. The transition that actually matters day to day is moving finished work to Completed, because that is what keeps everyone's My Tasks list worth looking at.

Status and time

Status is what decides whether a task can take time. In Progress tasks accept both the timer and manual entry. Completed tasks accept manual missed time only, dated on or before the day they were completed. Draft, Backlog, and Archived tasks accept no new time at all.

The Job matters too, and both checks have to pass. The full picture is in Which Tasks Can Accept Time (and Which Cannot).

Stopping a timer

When you stop the timer, the tracker does not save silently. It holds the captured time and asks you to CONFIRM or DISCARD it, with the option to resume if you stopped by accident. Time only becomes a real entry when you say so. The timer itself, and manual entry alongside it, are covered in My Time: Log Your Effort and Fix What You Missed.

Draft tasks and ready tasks

Not every task is a commitment the moment you type it.

Draft tasks are planning notes. They carry a name and not much else. They accept no time, they do not affect capacity, and they stay out of performance calculations. Sketching out a Deliverable's work before you know who is doing what is a legitimate thing to do, and Net Net does not make you pretend otherwise.

Ready tasks are real. A task becomes real when it is fully defined: at least one complete allocation with an assignee, a service type, and an LOE, plus a due date.

Adding a task

Click + Add a task at the bottom of a Deliverable's table. The row turns into an inline editor with the name field focused, and the expansion underneath holds the description and the allocation rows.

You need a name and at least one complete allocation before it saves. If the Deliverable has no service types on it yet, the allocation picker tells you so rather than letting you build something the plan cannot hold. Service types get onto a Deliverable back in Plan Stepper: How to Build a Job Plan Step by Step.

Recurring tasks on Retainers

Retainer Jobs get one extra column: a Repeat control on the task row.

Turn it on and that task becomes a template for the Retainer. Each cycle materializes its own instance of it, with its own status, its own actuals, and its own life. The template holds the defaults. The instances hold the truth. Nothing accumulates across months.

More on how cycles work in Running Retainers: Monthly Cycles, Tasks, and Actuals.

Moving a task

The ⋮ menu on any Job Task row carries three actions: Edit details, which just expands the row, Move task, and Delete.

Move task opens a panel that sends the task to a different Deliverable in this Job, or to a different Job entirely. Everything logged against it comes along. See Moving a Task Without Losing Its Time or History.

Frequently Asked Questions

Can a task have more than one person on it?

Yes, and that is the intended way to use them on a Job. Each person gets their own allocation row with their own service type and their own LOE in hours. A kickoff meeting with three attendees is one task with three allocations, not three tasks.

How is a task's LOE calculated?

It is the sum of every assignee's allocation, and it is never stored separately. If two people are on a task at 4 hours and 2 hours, the task reads 6h. Change an allocation and the task total follows immediately, so the two can never disagree.

Can different people on the same task log different service types?

Yes. Service type is set per allocation, not per task. One person can be logging Design while another logs Strategy on the same task, and each person's hours land in the matching effort pool on the Deliverable.

Can a task have more than one due date?

No. One task, one due date, no matter how many people or service types are on it. Due dates do not exist at the assignee level. If two pieces of work genuinely need different deadlines, they are two tasks.

What is a Draft task?

A planning note that is not a commitment yet. Draft tasks accept no time, do not affect capacity, and stay out of performance. Once a task is fully defined with an assignee, a service type, an LOE, and a due date, it becomes real, and a Job Task cannot be turned back into a Draft afterwards.

Why can't I pick the service type I want on a task?

Because it is not on the Deliverable. An allocation can only use a service type that already has an effort pool on that Deliverable. Hours are never capped, but the categories of work are fixed by the plan, and adding a new one is what a Change Order is for.

What happens to a running timer when I complete a task?

Net Net stops it and asks you to confirm or discard the captured time before it saves. Nothing is written silently, and you can resume if you stopped by mistake. Time only becomes an entry when you confirm it.

Where do tasks that don't belong to a Deliverable go?

Into General Job Tasks, the grouping at the bottom of the Tasks tab. Coordination, status calls, and client communication all live there. They take assignees, LOE, due dates, chat, and time exactly like any other Job Task.

Related articles

Job Tasks only exist once a Job is switched on, so if the Tasks tab is still grayed out, Activating a Job: What Happens When the Plan Locks is the missing step. Once time starts landing on these rows, Reading the Job Performance Tab: Plan, Actual, Drift shows what it added up to. For the smaller stuff that starts as a note rather than a plan, Turning a List Item into a Task: Quick or Job Task covers the promotion path, and Chat on Completed, Archived, and Quick Task Work explains what happens to a task's conversation after the work is done.

Updated on: 08/04/2026