Follow-ups for a person to do
task is a follow-up whose channel says a human must do this. No drain ever sends a task row. It appears as "For a person to do" on the follow-ups screen and stays there until somebody completes it. It exists because much of what gets promised is not a message: a quotation to prepare, a recording to review, a colleague to ask.
What lands on it#
- Work that produces something. "Send the quotation" is not a message — the message is the easy half, and the quotation is the promise.
- Work that is internal. "Review the recording", "check with the warehouse", "ask whether we can do Thursday". The customer is not on the other end of any of these.
- Work that needs a judgement. Anything where the next step depends on what a person concludes, rather than on a reply being sent.
- Work that has no channel. A commitment made in a meeting, or one inherited from a conversation somewhere Connect does not reach.
On a call, follow_up_channel makes this split automatically: a call-back goes on phone, and a person's own work goes on task. You can also set it by hand on any row, which is the right move when a promise turns out to need a person rather than a message.
Why nothing sends it — and why that is the design#
The obvious alternative is to have no task channel and simply not record human work. That was the failure this channel exists to fix: a promise made on a call that produces no row is a promise that survives only in somebody's memory of the call. Recording it as a follow-up gives it a due time, a reason and a place in the same queue as everything else owed to that person.
The other alternative — letting a drain attempt it — is worse. A drain that tried to execute "send the quotation" would send a message about a quotation that does not exist. Refusing to act is the only correct behaviour for work that a machine cannot do, and making that refusal explicit in the channel name is better than discovering it at the moment the row comes due.
Where it appears#
| Where | How it reads | What you can do there |
|---|---|---|
| The follow-ups screen | Grouped as "For a person to do" | Complete it, edit it, snooze it or cancel it |
| The person's record | Counted in the open commitments to that person | See everything owed to one relationship in one place |
| Needs You | When it needs a decision rather than an action | Decide, and let the row close |
| A due or overdue view | Ranked with everything else that is late | Judge it against the rest of the day's work |
It is deliberately not a separate to-do application. Splitting human work off into its own list is how the two halves of a promise get separated: the call-back in one place, the quotation it depends on in another, and nobody looking at both.
Working the task rows#
Read them alongside the drained rows rather than separately.
Result You see that today's call-back to a customer depends on a document nobody has produced yet, while there is still time.
Complete the row when the work is done, not when you have decided to do it.
Result The queue keeps meaning what it says, and the person's open commitment count stays honest.
If the work turns into a message after all, change the channel rather than opening a second row.
Result One commitment stays one record, and the duplicate rule is not involved.
If the work belongs to somebody else, leave it in the shared queue with a reason that says who and why.
Result The queue is the hand-over, instead of a conversation that has to happen before anyone can act.
Questions#
Can I make Connect execute a task row anyway?
No. There is no mode, permission or setting that hands a task row to a drain. If what you want is a message sent, change the row's channel to the channel that should carry it.
Does a task row go overdue?
Yes, and it should. Overdue means the commitment is past its time and nothing has happened — which for a task row is exactly the state you want made visible, since nothing is going to happen without a person.
Is the twenty-four-hour lateness rule applied to task rows?
That rule is specific to the phone channel, where a very late call-back is worse than none. A task row is not closed for being late; it stays open, because the work still needs doing.