The work colleagues hand you in the corridor is recorded nowhere

"Can you also send me the invoice paperwork?" You say yes, because it is not much work. Three days later the colleague asks where it is. You remember promising it — and that you wrote it down nowhere.

This is not a problem of badly managed tasks. Your tasks are fine: your manager assigns what needs doing, or you create it yourself. The problem is the work that arrives on the side — in chat, in a corridor, at the end of a meeting. It is recorded nowhere until you rewrite it as a task yourself, and a share of it simply gets lost.

Why it does not become a task straight away

The first instinct is to let the colleague create the task directly. That does not work, and not because they are lazy.

To create a task for you, somebody has to know which project it belongs to, which column to put it in, what priority it deserves and by when you can realistically finish it. Those are all judgements only the person doing the work can make. Ask the sender to fill them in and they will either give up or dump something into your project that does not belong there and has to be redone.

So a request in CTM is deliberately not a task. The sender picks no project, no column and no binding deadline. They write what they need, by when they would need it, and whether it is a task, a question, an approval or just information. Where it belongs, and whether you take it at all, is your call.

The deadline is a proposal, not a commitment

The date the colleague writes down is a suggestion. When you turn the request into a task, you confirm the deadline or rewrite it — and that is where the agreement is actually settled. Until now this negotiation happened in chat and was recorded nowhere, so a week later everybody remembered a different date.

Converting takes one click: the task arrives with the title, description, priority and suggested deadline prefilled, and you add the project. You become the assignee, and the request stays linked to the task.

You can say no, but with a reason

A request is not an order. You can reject it — but not without a reason; the button simply will not submit.

That is deliberate rather than pedantic. A request that disappears without explanation teaches the sender exactly one thing: that sending it was not worth the effort. Within a month everything is back in chat and the feature is dead. A single sentence — "I cannot make tomorrow, I can do it by the end of the month" — keeps the whole mechanism alive.

When it is not yours

Some requests reach the wrong person. Rejecting them would be formally correct and practically useless, so they can be forwarded instead.

Forwarding does not start a new thread. The recipient changes, it stays visible who passed it on, and the original sender is notified — so they are not following two halves of the same thing in two places.

The sender never has to chase you

This is the part we consider most important. When the task created from a request moves to Done, the request closes itself and the sender gets a notification.

Nobody has to write "so, did you do it?" and nobody has to answer "yes, last week". The status is visible throughout — waiting, accepted, done, rejected, withdrawn.

What it is not

It is not a help desk and not a second Kanban board. A request has no columns of its own, no custom statuses and no SLA policies, and it is not meant to live for weeks. It should live for hours or days: it arrived, you decided, it became a task or it died with a reason. The moment it needs a workflow of its own, it should have become a task long ago.

Where to find it

The sidebar has a new Requests item showing how many are waiting for your decision. It has three tabs: Received, Sent and Closed.

Requests are available on every plan, Free included — this is a basic piece of working together, not a premium feature. And because the desktop app for Windows and macOS is a wrapper around the same application, they appear there on their own, with nothing to download.