Assign every task to one owner who accepted it
A task in TaskIt is a record, not a message. It has an owner, a status, a priority, a due date and a history that starts when it is raised and ends when someone approves it.
No card required. Every feature is unlocked for 30 days.
The problem
Work that lives in messages cannot be managed
Most small and mid-sized teams do not lose work because people are careless. They lose it because the instruction and the record of the instruction are the same message, and messages scroll.
- Nobody can say who owns a job without asking, because "can someone look at this" was never assigned to anyone.
- A task that has been half-done for a week looks identical to one nobody has started — neither has a status.
- Deadlines exist only in the sentence that mentioned them, so nothing surfaces as overdue.
- The person who did the work is the only record that it happened, and they are on leave.
- Every status update costs a meeting, because the only way to find out is to ask.
How TaskIt handles it
A task record that answers those questions without asking anyone
Every task carries the same fields, so the state of the work is readable at a glance rather than reconstructed from a conversation.
- A persistent task ID and code, issued at creation and kept for the whole lifecycle — through handovers, reviews and reopens.
- One current assignee at all times, so ownership is a fact rather than an assumption.
- Twelve lifecycle statuses, from New through Assigned, In progress, Handover, In review and Approved to Completed — plus Rejected, Reopened, Blocked and Cancelled.
- Four priorities — Low, Medium, High and Urgent — and a due date on every create form, with a guard against setting one in the past.
- A progress figure and an activity timeline that records every accept, update, handover, comment, review and status change.
What you get
A status meeting you no longer need
The dashboard, the board and the task table already show what is open, what is overdue, what is blocked and what is waiting on review. Nobody has to be asked for an update to produce that.
Nothing is finished by assertion
Submitted work goes to In review and is approved or rejected by the task creator or someone holding the review permission. A person cannot review their own submission.
History that survives the people
Because the task ID never changes, the activity trail, the handover history and the performance timestamps all stay attached to one record — readable long after the person who did the work has moved on.
One view per question
A board when you want to see where work is stacking up, a table when you want to filter and act in bulk, a grid when you want to scan. Each person keeps their own choice.
How it works
In the order a person using it meets them.
- 1
Raise the task
Fill in the create form — your own fields if you have built a task form, plus the built-in due-date picker. Choose a priority and either a named assignee or a whole department.
- 2
The assignee accepts
Accepting starts the task in one step: it moves from Assigned to In progress and stamps the start time. There is no separate "start" action to forget.
- 3
Progress is logged as it happens
The assignee updates progress, adds comments and attaches files. Each of those writes an activity entry with a timestamp, so the trail builds itself.
- 4
Work is submitted, then reviewed
The task moves to In review. The creator, or anyone with the review permission, approves it — or rejects it, which sends it back as Reopened with the reason attached.
A single task, start to finish
A customer complaint arrives on a Monday morning at a 20-person business. Here is what the record looks like by Thursday.
- 1
Monday 09:14 — raised
The office manager creates "Refund dispute — order 4471", priority High, due Thursday, assigned to the accounts department rather than a named person.
- 2
Monday 09:31 — claimed
Two accounts staff were notified. The first to press Accept & Start locks the task; the second sees that it is already taken and keeps read access.
- 3
Tuesday 16:02 — handed over
The owner is going on leave. She hands over: 60% complete, the refund is approved, the paperwork is still to be filed. The task keeps its ID and moves to the next person with all of that recorded.
- 4
Wednesday 11:40 — blocked, then unblocked
The bank portal is down. The new assignee marks it Unable to Complete with "waiting for external system". A manager sees it on the attention queue and resumes it that afternoon.
- 5
Thursday 10:05 — reviewed
Work is submitted. The manager who raised it approves. The task reaches Completed with a complete trail of who held it, what each person finished, and where the two days went.
The result
Nobody wrote a status report and nobody attended a stand-up. The trail is a by-product of doing the work.
Board, table and grid — the same tasks, three ways
The table is the default and is where filtering and bulk action live. The board groups tasks into status columns and paginates each column separately, so one busy column cannot bury the rest. The grid is a scan view. The view choice is per person, not per workspace.
- Filter by status, priority, department, assignment type and team member
- A page-size selector, so a long list is not forced into someone else’s idea of a page
- Dashboard figures link through to the task list already filtered to whatever you clicked
Review and approval, one task or two hundred
Select the tasks awaiting review in the table and apply one decision to up to 200 of them in a single request. Each task comes back individually as reviewed, skipped or failed — one failure never aborts the rest, and a task another reviewer has already decided comes back skipped rather than overwritten.
When someone cannot finish
The assignee marks the task Unable to Complete with a reason — one of twelve predefined reasons or their own wording, which is remembered for reuse. The task becomes Blocked, the reason is written to the activity history and the audit log, and it waits for a manager to reassign, resume, reopen or cancel it. A blocked task says so instead of sitting silently overdue.
Correcting a title without losing the record
A task title can be corrected after creation by its creator or a manager with the right permission. The rename writes an audit entry and a timeline entry with the old and new wording, and touches nothing else — the ID, status, assignee, progress, due date and handover chain are all untouched. Completed and cancelled tasks are locked.
Frequently asked questions
A task has exactly one current assignee. On a department task in Collaborative mode several people can join and each logs their own progress, but one of them is still the owner — the overall progress figure is the mean of every active collaborator’s own progress.
It moves to Rejected and then Reopened, and goes back to the assignee with the reviewer’s reason recorded on the task. The task ID does not change, so the second attempt sits in the same history as the first.
No, but a task created without one inherits its assignee’s department. That is deliberate: it keeps department reports and department health figures accurate without anyone having to remember to set a field.
Only if your role holds the permission for it. Access comes from the permission list stored on your role — an Admin base role grants nothing by itself. Employees see their own work and their department’s unclaimed queue.
Where to go next
The capabilities either side of this one, and the problems it is bought to solve.
Put one week of real work through it
Create a workspace, raise the tasks you would otherwise have sent as messages, and see what the trail looks like on Friday.