Pass work on without losing what already happened
Reassigning a task changes a name. A handover changes the owner and records the state of the work at the moment it moved — completed, pending, notes, progress, both people and the time.
The whole handover trail is available during the 30-day trial.
The problem
The handover is where context goes missing
Handovers are rarely planned. They happen because someone is on leave, has changed role, is overloaded or has hit something they cannot resolve — which means they happen in a hurry, which is exactly when an informal process produces nothing usable.
- The transfer is verbal, so the record is whatever two people happened to remember in five minutes.
- A new task is raised for the remainder and the old one is closed, splitting the history across two records that nothing joins.
- Completed work is not stated, so the next person redoes part of it — or assumes it is done when it is not.
- Pending work is described as a topic ("still need to sort the invoices") rather than as next actions.
- The outgoing person has already gone, and the only remaining source of context is a task that says nothing.
How TaskIt handles it
A handover is a recorded event, not a field edit
TaskIt treats the transfer itself as something worth storing. The task never moves; ownership does, and the move leaves a row behind.
- The same task ID and code for the whole lifecycle, however many times it changes hands.
- Each handover records the previous assignee, the next assignee, work completed, work still pending, notes, the progress figure at that moment, and a timestamp.
- Completed work is a required field — it is the one people would otherwise skip, and the one the next person most needs.
- An optional free-text estimate of what is left ("3h", "2 days") for the incoming person.
- Activity history, audit entries and performance timestamps all stay attached to the single record rather than scattering across copies.
What you get
The next person can start immediately
They open the task and read what was finished, what is outstanding and why. There is no catch-up call, and no waiting for someone who is already on leave to reply.
Nobody inherits the blame for someone else’s week
Because the progress figure is recorded at the point of transfer, a jump or a drop afterwards is attributable to whoever caused it rather than to whoever happens to hold the task at the end.
You can see how often work changes hands
A task that has moved four times is usually the more interesting fact. The Handover History report makes that visible across the whole workspace rather than one task at a time.
Leave, shifts and turnover stop being events
The information that used to live in one person’s head is a field on the task. Somebody leaving is a reassignment, not an excavation.
How it works
In the order a person using it meets them.
- 1
Open the task and choose Handover
Available to whoever currently holds the task. The form is the handover itself — there is no separate "change assignee" path that would skip it.
- 2
State what is done and what is left
Completed work is required. Pending work, notes and an optional estimate of remaining effort are where the actual knowledge transfer happens.
- 3
Set the progress figure and pick the next owner
The progress you record is stamped against this handover, so the timeline shows where the work stood as it moved.
- 4
The incoming person is notified and accepts
They get an in-app notification and, if the workspace uses it, a WhatsApp message naming the previous owner, what was completed and what is pending. Accepting puts the task back In progress.
A handover that actually works
The same transfer, written the way the form asks for it.
- 1
Completed
"Layout reworked and checked against the three sample invoices. Client sign-off received by email on the 14th."
- 2
Pending
"QA on invoices over 50 line items — the pagination breaks at 52. Then re-export the PDF template."
- 3
Notes
"Do not change the font size to fix the pagination; that was tried and it breaks the header alignment."
- 4
Progress
60% at the moment of transfer, so the jump to 100% two days later belongs to the incoming person.
- 5
Recorded automatically
Previous assignee, next assignee, the timestamp, an activity entry on the task and an entry in the audit log.
The result
The incoming person knows the constraint that was already discovered, which is the part a verbal handover always loses.
Handover history, in order, on the task
The task detail view shows every handover as a row in the sequence it happened. Read top to bottom it answers the question a reassignment cannot: who had it, what did each of them finish, and what did they leave?
One task ID, whatever happens to it
The task keeps its ID and its KM- code through handovers, reviews, rejections, reopens and blocks. Nothing about the transfer creates a second record, so there is never a pair of half-tasks to reconcile.
- Comments, attachments and activity stay on the one record
- Performance timestamps still measure the whole job, not one leg of it
- The audit log entry for the handover names both people and the time
Handovers and department work
A department task behaves the same way once someone owns it. In Collaborative mode, a member who cannot continue leaves the task instead of handing it over — their contribution row is preserved, and if the owner leaves, the longest-serving remaining collaborator is promoted. If the last one leaves, the task returns to the department queue unclaimed with every contribution row intact.
Reviewing handovers over time
The Handover History report lists transfers across the workspace and exports to CSV, Excel or PDF. Repeated handovers on the same kind of work usually point at something structural — an unclear owner, a missing skill, or a step that belongs to a different department.
Frequently asked questions
A reassignment changes who is responsible. A handover changes who is responsible and records the state of the work at the moment it moved — completed work, pending work, notes, progress, both names and the time. Reassignment is fine for work that has not started; once work is in flight it throws away the only record of what was done.
No. The task keeps the same ID and code for its entire life. The handover is stored as a separate history row against that task, which is what keeps activity, audit and performance data attached to one record.
Yes, as many times as the work needs. Each transfer adds a row, and the task detail view shows them in order, so a task that has moved four times reads as a chain rather than as four disconnected records.
The person who currently holds it. On a collaborative department task, a member who cannot continue leaves the task instead — blocking and handing over speak for the whole task, and one stuck collaborator should not halt everyone else.
Where to go next
The capabilities either side of this one, and the problems it is bought to solve.
Hand over one real task
The trial is long enough to cover a leave day, a shift change and the handover that comes with them.