Build it with AI
Create a task system that matches the way work moves through your team.
Build task types, owners, priorities, due dates, dependencies, and workflow states around your actual process.
Introduction
What a task management system has to hold.
Most teams end up with a task management system the same way: tasks split across a project tool, several inboxes, and a personal list per person. A generic list works while there is one kind of work. It stops working when the team handles three kinds with genuinely different lifecycles, and every task is forced into fields that fit one of them and mislead about the others.
Work exists in as many lists as there are people, so the shared view is always a partial one. There is no distinction between types of work with different lifecycles, no dependency that blocks the wrong thing from starting, and no signal that priority has become meaningless because everything is high.
What follows covers building a task management system: the records it holds (tasks, owners, due dates, dependencies, and what completion means for each), the systems it reads (Slack and Google Calendar), and what it does not fix.
The problem
A general task tool that fits no team in particular.
General task tools optimise for adaptability, which means they model nothing in particular. The customisation that makes one fit is a project in itself, and the result is a configuration nobody but its author understands.
The records are tasks, owners, due dates, dependencies, and what completion means for each, and the authoritative copy of most of them already lives in Slack or Google Calendar. The board says fourteen tasks in progress, the team says they are working on three, and both are accurate descriptions of different things.
The cost is not the inconvenience: capacity is planned against a list that is missing half the work.
You're likely here because
- Everything is marked high priority, so priority carries no information
- Work exists in as many lists as there are people, so the shared view is always a partial one.
- When it is wrong, capacity is planned against a list that is missing half the work
What gets built
Launch builds it, Grow operates it.
Built in Launch
- • Task board
- • Owner queues
- • Priority views
Operated through Grow
- • Reminders
- • Follow-up
- • Scheduling
Systems it reads
- • Slack
- • Google Calendar
- • Google Drive
The record model
What a task record has to carry.
- Work type
- Because two kinds of work with genuinely different lifecycles forced into one model produce fields that are always empty for one and required for the other.
- Owner, required at creation
- An unowned task is the single most reliable predictor of a task that will not be done, and it is trivially preventable.
- Priority against a capped distribution
- A cap on how many items may be top priority is what makes the field mean anything. Uncapped priority converges to uniform urgency within a quarter.
- Blocking dependency
- Modelled where a real blockage has occurred, and enforced rather than annotated, so a task that cannot start is visibly not startable.
- Work-in-progress state
- Separate from assigned, so a board describes what is being worked on rather than what somebody intends to work on eventually.
- Cycle time per type
- Because a mixed cycle time across genuinely different work is an average of two distributions and describes neither.
- Archive date
- Without an archival policy the system becomes a place where work goes to be forgotten with a timestamp, and every view gets noisier.
How it runs
From a generic list to work your team recognises.
Step 01
Describe what a task management system has to do
Identify the distinct kinds of work the team does and how each actually moves. A task type with its own lifecycle deserves its own model rather than a label on a shared one.
Step 02
Connect the systems of record
Chat is where work is requested, the calendar bounds capacity, and the systems the work acts on supply context. Reading them keeps task state attached to reality rather than to a ritual update.
Step 03
Build the operating surface
Task types with their own fields and states, dependency modelling, owner queues, and a priority scheme with an enforced distribution.
Step 04
Start narrow
The work type that causes the most confusion, modelled properly, while everything else stays where it is. A partial model that fits is better than a complete one that does not.
Step 05
Route the exceptions
A task blocked by an unfinished dependency surfaces to the owner of the dependency rather than to the person who is stuck.
Step 06
Measure work items visible in the shared view as a share of work actually in progress
Measure cycle time per work type and the share of tasks completed in the period they were planned for. Both are objective and both respond to modelling the types separately.
Implementation path
Building task management without a taxonomy project.
- 01
List the kinds of work and how each moves. Where two share a lifecycle, keep them together; where they do not, separating them is the whole improvement.
- 02
Baseline cycle time per work type and the current priority distribution. If most items are top priority, the scheme is decorative and that is worth stating plainly.
- 03
Enforce a priority distribution rather than a priority field. A cap on how many items may be top priority is what makes the field mean anything.
- 04
Model dependencies only where a real blockage has occurred. Speculative dependency modelling is maintained briefly and abandoned quietly.
- 05
Build the narrowest useful version first: one team's work in one place, with completion defined rather than assumed.
- 06
Listing the kinds of work and how each moves is a session, and where two share a lifecycle they should stay together. Modelling the type that causes the most confusion is a week. The priority cap is a policy decision rather than a build, and it is the change that produces the most immediate effect.
- 07
After the priority cap and one modelled type, add work-in-progress limits per person so the board describes reality. Cycle time per type follows and is the first number worth reporting.
Controls
Controls that matter.
Control 01
A capped priority distribution, since an uncapped priority field converges to everything being urgent within a quarter
Control 02
Dependencies that block rather than annotate, so a task that cannot start is visibly not startable
Control 03
Ownership required at creation, because an unowned task is the most reliable predictor of a task that will not be done
Examples
Three things that stop being tolerated.
The fourteen tasks in progress
A work-in-progress limit per person turns a board that describes intent into one that describes what is actually being worked on, which is the only version that supports a planning conversation.
Everything is urgent
A capped priority distribution forces the trade-off to be made explicitly at the moment of prioritisation rather than implicitly at the moment of execution.
Two kinds of work on one board
Separating types with genuinely different lifecycles removes the fields that were always empty for one type and always required for the other, which is most of what makes a generic tool feel wrong.
How it goes wrong
Three ways task systems decay.
Priority is a free field, and within a quarter three quarters of open items are marked high.
Cap the distribution and require something to leave before another enters. Priority as an unlimited attribute always converges to uniform urgency, in every team that tries it.
Work types are modelled finely, the taxonomy is unnavigable, and people pick the first plausible option.
Split only where lifecycles genuinely differ. Over-modelling produces mis-typed data that is harder to detect than the coarse model it replaced.
Tasks are created automatically from ambiguous triggers, and the queue fills with items nobody chose.
Automate creation only where the trigger is unambiguous. A queue of unchosen items is the fastest way to make people stop reading their queue at all.
Limitations and considerations
What a better task tool cannot deliver.
- A task system does not create capacity. It makes overcommitment visible earlier, which is useful and is frequently received as the tool being pessimistic.
- Task tools accumulate abandoned items that make every view noisier. Without an archival policy the system degrades into a place where work goes to be forgotten with a timestamp.
- Modelling work types too finely produces a taxonomy nobody can navigate, and people then pick the first plausible type. That failure is harder to detect than the one it was meant to fix.
- If all the work has one lifecycle, a general task tool is right and building is overhead. If the problem is overcommitment, a task system makes it visible sooner and is frequently received as the tool being pessimistic.
- Connector coverage varies: Slack, Google Calendar, Google Drive are representative rather than guaranteed, and the fields exposed depend on your workspace permissions.
FAQ
Build a task management system with AI: common questions.
Why not just use a general task tool?
Use one if your work has a single lifecycle. The case for building starts when two kinds of work genuinely move differently, because a general tool forces both into one model and the configuration that fixes it becomes its own maintenance burden.
How do we make priority mean something?
Cap the distribution. Allow a fixed number of top-priority items and require something to leave before another enters. Priority as an unlimited attribute converges to uniform urgency in every team that tries it.
Should tasks be created automatically?
Where the trigger is unambiguous, yes. Where it is not, automatic creation produces a queue of items nobody chose, which is the fastest way to make people stop reading their queue.
How much structure is too much?
Any required field that cannot be answered at creation is too much. It produces either abandonment or a placeholder value, and the placeholder is worse because it looks like data.
What should the first version contain?
One team's work in one place, with completion defined rather than assumed. Everything else waits until that one is genuinely used.
How will we know whether it worked?
Measure work items visible in the shared view as a share of work actually in progress against the baseline taken before anything changed.
Related pages
Keep exploring
Start with ARIA
Ask ARIA to build it.
Describe the website, application, workflow, or operating surface you need. ARIA plans, connects, builds, tests, and keeps refining it — inside the permissions you set.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Build a task management system around the process you actually run.
Model the work types that genuinely differ, cap the priority distribution, and require an owner at creation.