Email task management, without writing it down

Email task management is what you do about the fact that your work arrives as sentences in other people’s messages. The manual version is a copying job: read the message, decide it wants something from you, write it down somewhere else with a date on it. The automatic version removes the copying, which is the step that fails first.

• Most of what a small firm owes anybody arrived as a line in a paragraph, not as a ticket in a system.
• The copying is where it breaks. A flag records that something exists and says nothing about what or when.
• Finding the ask is a language problem with a measurable error rate, and where in the message it sits matters as much as what it says.
• The date is the load-bearing part. A task carrying a specific when behaves differently in your head than one that says soon.

What is email task management?

The name covers three things done in sequence: noticing that a message obliges you to something, giving that obligation a date, and being able to tell later that none of them were dropped. The messages themselves are not the point. A quote a client wants revised by Friday, a form an insurer needs back, a delivery slot a supplier wants confirmed: each of those is a piece of work sitting inside a paragraph, between a greeting and a signature, with nothing about it marked as work.

The people who build software to find these asks have to define one precisely, and their definition is a good working one for a human too. In Detecting Emails Containing Requests for Action, a 2010 paper for the North American chapter of the Association for Computational Linguistics, Andrew Lampert, Robert Dale and Cecile Paris define a request as an utterance that places an obligation on the recipient “to schedule an action; perform (or not perform) an action; or to respond with some speech act”. Three kinds of obligation, any one of which is now yours whether or not you noticed it going by.

Worth separating this from the pass that comes before it. Triage decides whether a message needs you at all. Task management starts once that answer is yes, and asks the two questions triage does not: what exactly does it want, and by when. How email triage works covers the first half, including the case for giving a deferred message a real date rather than a marker, so this page treats that as settled and takes up what happens next.

Five ways an email becomes a task

There are not many. Almost every system in use is one of these, or two of them stacked.

Only the last row takes the reading off you, and it is the only one where the volume of mail does not set the ceiling. The other four are variations on the same arrangement, in which a person is the mechanism that converts a message into a commitment, and the conversion rate falls as the day gets busier.

Why the inbox is a poor task list

The fullest study of this is twenty years old and has not dated, because the shape of the problem has not changed. In Quality Versus Quantity, published in Human-Computer Interaction in 2005, Victoria Bellotti, Nicolas Ducheneaut, Mark Howard, Ian Smith and Rebecca Grinter at PARC drew on more than forty interviews about how professionals keep track of work in email, then followed eleven people closely: filters capturing every message in and out for seven of them, video of all eleven working through their mail, interviews around both. Out of the interviews came six challenges of task management in email. The fourth is managing deadlines and reminders.

Listen to the public relations manager they quote under it. “I have so many follow-up reminders on due dates for things, and I do this manually for now,” she says, and then describes what happens when the manual part slips: “if I get thirty e-mails per day, in 3 days I have another 90 e-mails that I am going through and I have completely forgotten to follow-up on this, unless this (the folder) is visually up.” Her safeguard was a paper folder kept where she could see it.

A director in the same set of interviews had a tidier version of the same labour: “at the end of each day, I look at all the flagged messages and then drag them into my Outlook to-do list and set a deadline for each one.” That is a good system run by a disciplined person, and it is exactly the transcription this page is about removing. Notice its price. He reads every flagged message a second time, because the flag recorded that something mattered without recording what it asked. (Some quotes of this kind, the authors note, come from detailed interview notes rather than transcripts, so take the wording as close rather than exact.)

Filing is not the escape either. The same paper puts it plainly: moving to-do items into folders “makes it harder to remember many concurrent threads and their related actions (following the out-of-sight, out-of-mind principle)”. The eleven they followed were engaged with an average of 14.8 threads on a given weekday, and their video showed roughly a fifth of all email time going on organizing and searching rather than reading or writing, with 9.5% of it spent filing and 2% spent hunting for a message they knew was already there. That is eleven people in one American research lab on the clients of 2004, so read the percentages as a shape rather than a measure of your own week. The shape is what lasted.

The obvious repair, a dedicated task app fed by hand from the inbox, moves the copying instead of removing it and adds a question about which of the two surfaces is now authoritative. One surface instead of six apps makes that argument properly, and it is a different argument from this one.

How a machine finds the ask

Requests are not rare. Lampert’s team put 664 messages from the Enron archive in front of three annotators each; on 505 of them all three agreed, and 52% of those contained a request. What makes them hard is that a request usually does not look like one.

Their own example is the clearest. David will send you the latest version if there have been any updates. If David is copied in, that sentence is a request aimed at him, phrased as somebody else’s promise, and conditional on something that may never have happened. Any person reading it understands instantly. A rule written to catch it catches almost nothing else, which is why rules have never worked for this.

Then there is where in the message the sentence sits. A message is not one block of text. It has the part the sender actually wrote, a greeting, a signoff, the quoted reply underneath, a forwarded chain under that, a signature, a legal disclaimer. A request in the quoted section was somebody else’s last week. Lampert’s team measured what that confusion costs: reading whole messages, their classifier was right about whether a message contained a request 72.28% of the time, and reading only the author’s own text plus the greeting and signoff it was right 83.76% of the time, cutting the errors by more than 41%.

The errors left over say something useful about the limits. Around 5% of them were pleasantries mistaken for asks, and the phrase they name is one you have written this week: let me know if you have any questions. Sometimes that sentence is an obligation and sometimes it is punctuation, and the only way to tell is the rest of the message.

A decade later the job looks much the same with better tools. In Smart To-Do, a 2020 paper for the Association for Computational Linguistics, Sudipto Mukherjee, Subhabrata Mukherjee, Marcello Hasegawa, Ahmed Hassan Awadallah and Ryen White reported a classifier picking out the sentences in which a sender had promised to do something, at 86% precision and 84% recall on the Avocado corpus, an anonymized archive of 938,035 messages from 279 employees. Accurate enough to be worth having. Not accurate enough to run unwatched.

Which gives the honest description of automatic capture. Not that the software understands your mail, but that it forms a view on every message that arrives, gets most of them right, and puts that view somewhere you can see it and correct it. Whether you should trust that view is a fair thing to ask, and it has a testable answer: AI email triage sets out how to put a model’s judgment to the test on your own inbox.

Where the date comes from

Three places, and only the first is easy.

Written in the message. Often it is not a date at all: by Friday, end of next week, before the board meeting, first thing Monday. Turning those into a day on a calendar needs to know when the message was sent and what day it is now, which is the one piece of context software always has.

Implied by the work, not the message. This is the case people underestimate. In Characterizing and Predicting Email Deferral Behavior, a 2019 study for the ACM conference on web search and data mining, Bahareh Sarrafzadeh and colleagues at Microsoft interviewed enterprise email users about how they judged whether something was urgent, and found them weighing two separate things: “(a) whether a deadline is specified in the email, and (b) if there is a deadline for the task / project with which this email is affiliated”. One of those two was never in the message at all.

Chosen by you. Plenty of asks carry no deadline anywhere, which does not make them undated. It makes the date a decision, and the useful software behaviour is to ask for it once, at the moment you are already looking at the thing, rather than leaving it blank and hoping.

It is worth being firm about why a real when matters more than it sounds. In Consider It Done, a 2011 paper in the Journal of Personality and Social Psychology, E. J. Masicampo and Roy Baumeister split 73 undergraduates into three groups. One wrote about two important things they still had to do. A second did the same and then set out in detail how, when and where they would do each one. A third wrote about tasks they had recently finished. All of them then read the opening of a novel, interrupted four times to say whether their attention had been on the story. Among those who had only named their unfinished tasks, 65.2% had drifted off at least once. Among those who had made a plan, 33.3% had. The planners also reported fewer intrusive thoughts about the tasks and answered more of the comprehension questions correctly.

The detail that matters here is what planning did not change. It made nobody more confident of finishing. The authors put the active ingredient as “preparation rather than expectation”: naming the when is not motivation, it is permission to stop carrying the thing around. That was nineteen-year-olds with a novel in a psychology lab rather than an owner with forty live matters, and four of the seventy-three were dropped for guessing the design, so take the direction and not the figure. The direction is the one every working manual system already assumes.

A date is still not a priority, though, and treating them as one measurement is the usual reason a quiet obligation loses to a noisy one. Important versus urgent separates the two.

What you still decide

Capture is not disposal. A task appearing on a list is the end of what the software did and the beginning of what you do, and three of the judgments stay exactly where they were.

Whether it is yours at all. Lifting an obligation out of a message establishes that somebody owes it; nothing in the message says which of you, and in a small firm that ambiguity is where work quietly dies. There is a guide for exactly that gap: when work falls between you.

Whether it survives what you know. The client cancelled on the phone this morning. The deadline moved in a meeting nobody minuted. Software reading your mailbox has no access to any of that, and it should not pretend otherwise.

What it is worth against everything else you owe. A dated list is an input to that decision and never a substitute for it.

One more thing stays with you, quieter than the other three, and the Smart To-Do team measured it without meaning to. They had a judge rate a hundred of their human-written to-do items for fluency and completeness on a four-point scale. Fluency averaged 3.1. Completeness averaged 2.9, and the failure they print is the whole problem in seven words: a to-do reading “Update our quarterly sales in the database”, where the original email had said which database. Both their annotators judged the subject line helpful in writing the item for 60.42% of the emails, which leaves four in ten where at least one of them did not. People summarizing an email with the email open in front of them still lose the detail that makes the task doable.

So the link back to the message is not a convenience. Any task lifted out of a thread is a summary, and summaries are lossy whoever writes them. The task has to keep the conversation attached, so an ambiguous phrase is one tap from the sentence that produced it.

The same goes for how far the software is allowed to run on its own. That should be a level you set rather than a policy the product has, and it should not be one level for everything: creating a task from a message and answering a client are not the same risk, and a single switch prices them the same.

What automatic capture cannot do

It does not reduce what people ask of you. The same obligations arrive. What changes is that none of them depends on you noticing at the moment it lands.

It cannot see what never came through the mailbox. The promise made on a call, the favour agreed in a corridor, the thing your partner took on and did not mention. Those still need writing down by hand, and a system that only captures email should be honest that it is covering one channel well rather than all of them.

It cannot plan your week. A complete list of dated obligations is not a schedule, and the relief of not holding them in your head is not the same as having decided what to do first.

It will get some wrong. The two mistakes are not priced the same. A task you did not need is gone in a moment. An ask that was never lifted out is the one your client eventually asks you about. That imbalance is why the thing to judge is how cheap a correction is, not how rarely it errs.

How Point does this

Point is a full email client, so the reading happens where the mail already is. Overnight mail is sorted into now, later and other before you open it. Where a message puts an obligation on you, that obligation is lifted out as a task carrying its due date, its priority and the conversation it was found in. Nothing is typed in. One tap goes from the task to the sender’s own words, and the two stay joined, so the summary is never the only copy.

Every task Point finds lands in one list, next to the ones you added yourself and the ones from any other business you run. Completion is noticed rather than only recorded: answer the email the ordinary way, without touching the task, and Point marks it as looking finished with its reason in plain sight and waits for you to agree or keep it open. Everything else it does with your mail is listed on the benefits page.

How far it goes on its own is a separate level for each sort of action. Point can suggest only, or prepare something and hold it for you, or get on with it. Out of the box every sort of action sits on the middle setting, preparing and waiting for your review, so raising one is a deliberate move you make. Its work is logged in order in ordinary sentences, and reversing something Point did starts from the entry that recorded it. Say once, in passing, how you want something handled and it keeps that as a standing preference rather than a one-off edit.

Common questions

Is email task management the same as email triage?

No, and the two run in that order. Triage ranks the arriving pile: this one now, this one later, this one never. Task management takes whatever survived that and asks the next question, which is what the message obliges you to do and by when. A firm can triage well and still lose work, if every ranked message goes back into the same undated pile.

Do I still need a separate to-do app?

For work that arrives by email, a second app mostly adds a copying step and a question about which list is true. Where a separate tool still earns its place is work that never touches your inbox: a project plan, a recurring checklist, anything a team maintains together. The test is whether you find yourself keeping the same item in two places.

What happens when it creates a task I did not want?

It should take one action to dismiss, and dismissing it should not cost you anything you would miss. That is a fair thing to check in a trial, because it happens in the first week and how it feels then decides whether you keep using the software. Watch also whether a correction holds, or whether the same one has to be made again a week later.

Can it find a deadline nobody wrote down?

Sometimes, from the thread rather than the sentence: a reply about a meeting on Thursday, a renewal date mentioned earlier in the conversation. Often not, because the deadline belongs to the project and was agreed elsewhere. The workable arrangement is that the software proposes a date when it has grounds for one and asks you when it does not, rather than leaving the field empty.

Does this work for a two-person firm?

It suits one, because a small practice has no intake process and no queue: work arrives addressed to whichever of you the client happens to know. What matters is that tasks stay personal rather than pooled, so each of you sees your own obligations, and that a task carries its thread, so handing one over does not mean forwarding four emails as context.

The short version

Email task management is the arrangement you already have, whether you designed it or not. Mostly it is a person rereading flagged messages at the end of the day and retyping them with dates, which works exactly as long as the day allows. The automatic version removes the retyping: the ask is found where it sits, the date comes from the message or the thread or from you, and the task keeps a link back to the sentence that caused it. What does not change is the deciding, which was always the part worth your time.

What ends up on the list depends on the trade. The obligations that pile up in a tax and accounting practice look nothing like the ones in an architecture practice, and six other trades have their versions written out.