Managing tasks out of email means holding three things together: the conversation the work came from, the file the work runs on, and the task itself. Most arrangements keep only the third and put it in a list somewhere else. What works better is one account covering all three, so that looking at the task shows you the situation rather than a title.
- A task made from a message is usually named after the subject line and described by a preview. Both describe the packaging rather than the work.
- The file is the half nobody counts. The task says send back the signed letter; the letter is an attachment in message four, and the task carries no route to it.
- Lifting something out of email costs you the cue you would have found it by, which is normally who sent it and what it was about.
- What fixes this is not a better list. It is one account spanning the thread, its files and the tasks it produced, with each of them a move away from the others.
What managing tasks from email involves
Work arrives as sentences in other people’s messages. That much is obvious to anybody who runs a small practice, and it is the reason “tasks email” is a phrase people type into a search box at all.
What is less obvious is that the sentence is rarely the whole job. A request refers to a document. It depends on something agreed four replies earlier. It carries a date that came from the client’s second message rather than the first. So there are three objects in play, not one: the conversation, the material it carried, and the commitment you now owe.
Take an ordinary one. The client writes on Tuesday attaching an engagement letter. On Wednesday they send a corrected version, apologising for the first. On Thursday somebody in your office asks whether it has gone back yet. The task is a single line, “return the signed engagement letter”, and it is useless on its own. Doing it requires knowing there are two attachments and which of them is live, and that is knowledge held in the conversation rather than in the task.
Almost every system in ordinary use breaks the three apart. The task goes to a list. The file goes to a folder, or stays where it landed. The conversation stays in the mailbox, and after a fortnight it is the only one of the three that still knows what was going on.
This guide is about the account that holds them together, which means one thing it is not about. Where the date comes from, and how an obligation buried in a paragraph gets written down at all, is a different question with a good answer of its own in email task management. Assume that has happened. The question here is what you should be able to see when you look at what came out of it.
What a task made from an email carries
Both large mail providers already do a version of this, and their own descriptions of it are the most useful evidence available, because they are careful and they are not selling anything against themselves.
Microsoft’s support page for the flagged email list in To Do, checked 19 August 2026, sets out what arrives: “The task’s name will be the subject of the flagged message and will include a preview of the email’s text in its detail view.” From the task, the detail view offers a route back into Outlook.
Google’s own page for Tasks, checked the same day, describes the same arrangement in the same spirit: “Turn an email into a to-do so it doesn’t slip through the cracks. After you create a task from an email, you can easily click back to the original message to remind yourself about the context.”
Read those two descriptions closely, because they are honest about something that is easy to miss. In both cases what the task carries is a name and a fragment, and in both cases the reason given for going back to the message is to recover the context. The context did not travel. The pointer did.
A subject line and a preview are weak descriptions of a conversation for reasons worked through in a plain summary of every email: the subject was written before most of the conversation happened, and the preview is the opening of the newest message, which is usually somebody saying thanks. The narrower point here is what happens when those two fields become a task. A message in your inbox is read within the day, while the memory of it is fresh. A task is read three weeks later, by a version of you who remembers nothing, and it is carrying a worse description than the message had.
Then there is the return trip. Going back to the thread to work out what you actually promised is a re-read of the conversation, which is the labour the task existed to save. Once or twice a day that is nothing. Across forty open commitments it is most of a morning, and it is the reason people quietly stop keeping the list.
The file the task runs on
Ask what your tasks are actually about. In a professional practice, most of them are about a document: a return to be filed, a letter to be signed, a statement to be reconciled, a draft to be marked up. The verb belongs to you and the noun arrived as an attachment.
There is a good account of why that material resists being tidied away. Email in personal information management, published in Communications of the ACM in January 2006 by Steve Whittaker, Victoria Bellotti and Jacek Gwizdka, is a survey of what two decades of research had found about the inbox doing three jobs at once: task management, personal archiving and contact management. Their explanation for why people leave things in their mail rather than filing them properly is one sentence and it is the whole of this section: “the most salient retrieval cue for an email attachment may be the sender, and this cue is lost if the attachment is only stored in the user’s file system”.
You know the document by who sent it and what you were arguing about at the time. You do not know it by its filename, which is Scan_20260814.pdf. Move it into a folder and you have kept the file and thrown away the handle you would have found it by.
So people keep it in both places, which the same authors describe as its own trap: “documents may be stored both in email and the file system”, which makes it “hard for users to collate information”. Two copies, one of them stale, and no way to tell from the outside which.
The article closes with a list of things the authors expected would not change, however much email software improved, and attachments are on it, for a reason worth quoting: “messages often concern discussion of and work around other content”. That is the correct order. The attachment is not cargo bolted onto a conversation. The conversation exists because of the attachment, and a task extracted from that conversation without a route to the document has dropped the subject of the sentence.
Why a thread is not the unit either
The obvious repair is to staple the whole conversation to the task, and it is a real improvement over a subject line. It is not enough, and the same 2006 survey says why: “threads are known to be a weak indicator of tasks due to topic drift and email responding practices”.
Anybody with a mailbox recognises that. One thread that began about a VAT registration now also contains a question about next year’s fees and a request for a meeting. Those are three separate obligations wearing one subject line, and two of them will finish weeks apart from the third. The reverse happens just as often: one obligation that lives across a thread, a forward from a colleague, and a calendar invitation, none of which knows about the others.
The answer people arrived at is older than it looks. The same authors point to Taking email to task, presented at the 2003 conference on human factors in computing systems by Victoria Bellotti, Nicolas Ducheneaut, Mark Howard and Ian Smith, which built a mail client around what they called thrasks: “user-customizable collections based on threads”, where items could be added or taken away “so that a thrask represents a task collection more than just a series of messages”.
That is the right object, and it was described more than twenty years ago. What kept it out of ordinary use was the labour. Somebody had to curate every collection by hand, on top of reading the mail, and curation of that kind is the first thing to go in a busy week. What has changed since is not the idea. It is that the assembling can be done before you arrive, which turns a maintenance job into a judgment you check.
Being clear about that word matters. Deciding that this attachment, this thread and this obligation are one situation is an inference, not a fact recovered from the mail. It will sometimes be wrong. Which is a reason to keep the pieces individually reachable, not a reason to leave them scattered.
What one account has to carry
Four of the requirements are the ones any thread summary owes you, and a plain summary of every email sets them out properly: what it is about, what is being asked, who is asking, and where it has got to. An account that spans a whole situation adds two more.
The material, named and current. Which documents this conversation carried, which one is live, and one move to open it. The version question is the one that matters, because the second attachment is usually the one that counts and the first is usually the one you find.
The state of what it produced. Whether an obligation came out of this, what it commits you to, when it falls due, and whether it looks done. This is where the account stops describing a conversation and starts describing your position in it.
The 2006 survey names why both axes are needed, in a line about what makes mail harder to process than the rest of your filing: “Users therefore have to track both obligations and message status for email information”. Two different things, moving at different speeds. What you owe changes when you act. What the conversation is doing changes when somebody else does.
And one rule underneath all six. Every lifted fact keeps a route back to what produced it, one move away and one move back: the summary to the thread, the named file to the file itself, the task to the sentence that created it. A description that cannot be checked in a second is a description you end up not trusting, and an untrusted summary costs more than no summary, because you read it and then open the thread anyway.
What changes in the working day
The first thing you notice is what the morning pass turns into. Going down a feed where each conversation carries an account of itself is a reading job rather than an opening job, which is the subject of how to skim a full inbox in minutes. What changes when the account spans the files and the tasks too is the quality of the decision at each line. “Henderson, waiting on you, signed letter attached, due Friday” is a thing you can act on or defer honestly. “Re: Re: March” is a thing you can only open.
The second is the question every practice gets weekly, in some form: has that gone back yet. Answering it currently means checking two or three places and then reading a thread to be sure. One account of the situation makes it one look.
The third is picking work up after two days away from it. Everything you would otherwise rebuild from memory, which document, which version, what the client last said, is sitting in the account rather than in your head. That is worth more on the twentieth open matter than on the second, which is why it is small firms that feel it most.
The fourth only applies if there are two of you. Handing over a job means handing over the situation rather than forwarding four emails and hoping, and what that does to work falling between people is covered in when an email falls through the cracks.
What this does not do
It does not decide what matters. An account of a situation says what it is, not whether it should reach you before the other forty. Ranking is a separate measurement on different evidence, and how email triage works is where it lives.
It does not choose the date. Where a deadline comes from, and what happens when the message contains none, belongs to email task management. Here the date is something the account displays, not something it decides.
It is not a briefing. The unit here is one situation, described down to the file it turns on. What the whole morning holds is a separate read with a separate purpose, and wanting that one is not a sign this one should be longer.
It cannot see what never came through the mailbox. The document a client handed you in person, the deadline agreed on a call. A system reading your mail is covering one channel thoroughly, and should say so rather than imply it has the whole picture.
It is not the document. The account tells you which file and where it is. For anything you will be held to, you open the file and read it, exactly as you would have.
That last boundary is the general one, and the 2006 authors put it well while predicting the software we now have. Systems that detect obligations and propose actions were on their list of what was coming, along with a warning about “introducing automated processes into such a critical application, where the cost of algorithmic error without human oversight is high”. The oversight is the part that makes it safe, and it is cheap to run. For a fortnight, on the tasks that matter, check that the file the account names is the file you would have picked. The error to watch for is not an invented fact. It is the second attachment being missed, and it shows up quickly if you look.
How Point draws the three together
Point is a full email client running on top of the Gmail or Microsoft 365 account you already have, so the reading and the assembling happen before you open it rather than when you ask. Every conversation carries a plain summary written by Point, and the summary is of the situation rather than the mail alone: a thread, its attachment, the meeting and the task it produced are drawn into one idea you open in place, without navigating away from the feed.
The task half is not something you type. Where a message puts an obligation on you, it becomes a task carrying its due date and the conversation it was found in, and task and conversation stay attached, so a line you cannot quite place is one tap from the words the sender used. Tasks from every conversation, and from any other business you run, gather in a single list.
The file half works the same way round. Attachments stop disappearing into threads and gather in one list, each still tied to the conversation it arrived in, so the sender and the subject you actually remember the document by are still attached to it. Searching for it works on what you remember rather than the exact words, which is the right shape for a file nobody named carefully. And where a conversation jumps channel, an email answered by a message stays one conversation rather than splitting in two.
How far Point acts on any of this is a level you set for each kind of action, from suggest-only through review to fully handled, and every kind starts on review, so work arrives prepared and stops there until you look. What Point did is written down in order in plain sentences, and reversing something starts from the entry that recorded it. When its idea of a summary is not yours, saying so once in a sentence keeps it as a preference rather than a one-off edit. The benefits page lists the rest of what happens before you sit down.
Common questions
Is the built-in task list in Gmail or Outlook enough?
For a handful of commitments a week, it does the job, and the round trip back to the message costs you nothing at that volume. What it does not do is describe the work. By their makers’ own descriptions, checked 19 August 2026, the task is named after the message’s subject and detailed with a preview of its text, and you return to the original message to recover the context. At forty open items that return trip is the whole cost, and it falls on you every time you read the list.
Does a task made from an email keep the attachment?
Not usually. It keeps a link to the message, which keeps the attachment, which is not the same thing: it means the document is two moves and a re-read away rather than named on the task. Worth testing on the case that actually bites, which is a thread where a corrected version arrived after the original. If the task cannot tell you which of the two is live, it will not tell you in three weeks either.
What is the difference between a summary and a task?
A summary is an account of what is going on. A task is one commitment with a date on it. One thread often produces two or three tasks, and one task sometimes spans two threads, so they are not two names for the same object. The useful arrangement is that each carries a route to the other, so the task can be read for what you owe and the summary for why.
What if one thread contains three different jobs?
Then three tasks come out of it and the account of the thread should say so. This is the common case rather than the awkward one, because conversations drift and nobody starts a new thread for a new subject. It is also the case that shows whether a system is describing the conversation or the work, since a tool that assumes one thread means one task will merge three obligations into whichever it noticed first.
Is this the same as a morning briefing?
No, and the difference is the unit. A briefing gathers many threads into one read, so you know the shape of the day before it starts. What this page describes is one situation in full, files and commitments included, which is what you want once you have reached it. Most people end up wanting both, at different moments of the morning.
How do I know it has the right files?
Check it where it costs least. For two weeks, on the matters that matter, open the account and ask whether the document it names is the one you would have gone looking for. Errors of omission are the ones to hunt, because an account listing three accurate things and missing the corrected attachment reads as complete. If a correction has to be made twice, that is the finding rather than the individual mistake.
The short version
Managing tasks out of email is usually described as a capture problem, and capture is the easy half. The hard half is that the three things the work is made of, the conversation, the document and the commitment, end up in three places, and only one of them still makes sense a fortnight later. A task named after a subject line and described by a preview is a pointer to a re-read.
What you want instead is one account of the situation: what it is about, what is being asked and by whom, where it has got to, which file it runs on and which version is live, and what you now owe and when. Each of those a single move from the thing that produced it, so checking is cheap enough to do whenever you are unsure. That is not a shortcut past your mail. It is what makes a list of forty commitments something you can read on a Monday without opening any of them.
What the three pieces are made of depends on the trade. A tax practice in February is holding different documents from an architecture practice mid-project, and there are eight mornings written out if neither is yours.