Three weeks into a project, someone asks: 'Didn't we agree to drop the second landing page?' Everyone half-remembers the conversation. Nobody can find it. One person searches their inbox and turns up two threads with different subject lines and different conclusions. The developer who joined last week was never copied in at all.

Most project managers have lived some version of this. The decision was made. It just didn't stick, because it lived in the wrong place. This article looks at why email is a poor home for project decisions and offers a workable alternative: keep the conversation, and the decision, on the task it affects.

Why decisions made over email don't stick

Email isn't the villain. It is very good at what it was built for, which is sending a message from one person to another. It gets into trouble when it is used as the record of a team's decisions. A few patterns cause most of the damage.

  • Each inbox holds a different version. Whoever was copied in has the thread. Whoever wasn't, doesn't. There is no single place that everyone can treat as the source of truth.
  • Threads branch. Someone replies to an earlier message, someone else replies-all to a forward, and the conversation splits. The decision ends up in one branch while half the team keeps reading the other.
  • Subject lines drift. A thread titled 'Homepage feedback' ends up deciding the launch date. Six weeks later, nobody thinks to search for 'homepage' when they want to know about the launch.
  • The decision is separated from the work. The person doing the task looks at the task. The reasoning behind it sits somewhere else, in someone else's mailbox.
  • New people start from zero. When someone joins mid-project, you can't hand them an inbox. You end up retelling the history from memory, and memory is selective.

None of this is about discipline. A careful team using email will still run into these problems, because the tool has no notion of 'the thing this decision belongs to'.

Put the conversation where the work lives

The fix is simple to describe: discuss work on the task it concerns. If the question is whether the second landing page stays in scope, the conversation belongs on the landing page task, not in a separate channel that points at it.

In Tilvin, every task and sub-task has its own discussion: threaded comments that sit directly beneath the task details. A few properties make this a better home for decisions than an inbox:

  • Everyone on the project sees the same thread. There is one conversation, not one copy per recipient.
  • You can bring people in deliberately. Using @notify on a team-mate pulls them into the discussion without having to remember who was on the original email.
  • Supporting material stays with the conversation. Attachments on comments mean the mock-up, the client's marked-up PDF or the spreadsheet sits next to the decision it informed.
  • There is a trail. Comments keep an edit and audit history, so if wording changes after the fact, you can see that it changed.

Because the discussion is attached to the task, anyone who opens the task later sees the work and the reasoning together. That includes the new developer. It also includes you, three weeks from now, when you've forgotten why you agreed to something.

One useful rule: one decision, one task. If a discussion starts covering a second topic, open or find the task that topic belongs to and continue there. That stops a task thread turning into the same sprawling mess as an email chain.

Make the decision visible, not just present

Moving the conversation is only half the job. A long discussion can still bury its conclusion. The decision needs to be easy to spot by someone skimming.

A lightweight habit that works well is to close any decision with a short comment in a fixed shape:

  1. Decision: what was agreed, in one sentence.
  2. Why: the reason, briefly. This is the part people forget, and the part that stops the question being reopened.
  3. Who agreed: the people whose sign-off mattered.
  4. What changes: any follow-up, such as new sub-tasks, a changed end date or a different assignee.

Then make the task itself reflect it. If scope changed, update the task. If new work appeared, break it into sub-tasks with their own assignees. The comment explains the decision; the task fields carry it out.

For longer threads, Tilvin's AI summaries can help. A task's discussion can be summarised into a short summary, a list of items and a set of open questions. The open questions are particularly useful: they show you what the thread hasn't settled yet, which is often the thing that resurfaces later. Treat the summary as a starting point to check, not a replacement for the decision comment you write yourself.

What to do with the email that still arrives

You won't get rid of email, and you shouldn't try. Clients will keep sending it, and some conversations start there naturally. The goal is to make sure decisions don't end there.

When an email contains something that affects the work, move it onto the relevant task. Paste the key part into a comment, or attach the message, and continue the conversation there. Reply to the sender with the outcome once it is settled, but keep the reasoning on the task.

When an email contains several requests at once, such as a client's notes after a review call, Tilvin's AI task generation can take the pasted text and propose tasks and sub-tasks for you to review before anything is created. Each resulting task then has its own discussion for the follow-up. There is a step-by-step approach to this in How to Turn a Messy Meeting-Notes Email into Clean Tasks.

Not everything belongs on a task

Task discussions are for decisions about specific work. Two other kinds of communication fit better elsewhere:

  • Announcements and broad conversations, such as 'the office is closed Friday' or a debate about how the team handles reviews, suit the project's Messages board, which supports replies, likes and read receipts.
  • Decisions that become lasting reference, such as a brand guideline or an agreed technical approach, are worth writing up in a project notebook once settled. The task discussion records how you got there; the notebook records where you landed. Where Project Docs Go to Die covers how to keep that documentation useful.

Habits that keep it working

The approach only holds if the team actually uses it. A few small habits help:

  • Redirect gently. When someone asks a task question by email or chat, reply with 'Can you add that to the task so it stays with the work?' It takes a few weeks before this becomes automatic.
  • Lead by example. If you, as project manager, keep making decisions in your inbox, nobody else will move. Post your own decisions on tasks first.
  • Check the activity feed. The project Timeline shows what has happened across tasks, so you can spot discussions that need a decision comment without opening every task.
  • Keep it reachable. Tilvin's Android and iOS apps include task discussions, so people can respond on the move instead of falling back to a quick email.
  • Don't over-format. The decision comment shape is a guide. A clear sentence beats a perfectly filled template that nobody writes.

Next steps

You don't need to change everything at once. Try this on your current project:

  1. Pick one decision currently sitting in an email thread and move it to the task it affects, with a short decision comment.
  2. Agree a single team rule: questions about a task go on that task.
  3. Add the four-part decision comment to your next decision and see whether people find it useful.
  4. For any thread longer than a dozen comments, run an AI summary and check the open questions.
  5. At the end of the week, scan the Timeline for discussions that ended without a clear outcome.

A decision that sticks is one people can find, understand and trust weeks later. Keeping it next to the work is the simplest way to get there.