Your work arrives as sentences inside other people’s messages. Email task management is what you do about that. The manual version is a copying job: read the message, work out what it wants, write it down somewhere else with a date on it. The automatic version takes the copying off you. That’s the step that fails first.
- Most of what a small firm owes anybody arrived as a line in somebody’s paragraph, not as a ticket in a system.
- The copying is where it breaks. A flag records that something mattered and stops there.
- Finding the ask is a language problem with a measurable error rate. Where the ask sits in the message matters as much as what it says.
- The date is the load-bearing part. A task with a real day on it sits differently in your head than one that says soon.
What is email task management?
The name covers three jobs, done in that order. You notice that a message puts an obligation on you. You give that obligation a date. Later, you can tell that all of them got picked up. The work is the point, and it sits inside ordinary messages. A quote a client wants revised by Friday. A form an insurer needs back. A delivery slot a supplier wants confirmed. Each one is a piece of work sitting in a paragraph, between a greeting and a signature, dressed as ordinary prose.
People who build software to find these asks have to define one precisely, and their definition works just as well for a human. Detecting Emails Containing Requests for Action is a 2010 paper for the North American chapter of the Association for Computational Linguistics. In it, 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 them becomes yours the moment it lands, caught or not.
There’s a pass that comes before this one. Triage decides whether a message needs you at all. Task management starts once that answer is yes, and asks the two questions triage leaves open: what exactly does this want, and by when. How email triage works covers the first half. It makes the case for giving a deferred message a real date rather than a marker. This page takes that as settled and picks up what happens next.
Five ways an email becomes a task
There are five. Almost every system in use is one of these, or two of them stacked.
| The method | Who reads the message | Where the date comes from | What it costs you |
|---|---|---|---|
| Leave it sitting in the inbox | You, every time you scroll past it | Nowhere | The pile grows on top of it |
| Flag, star or mark it unread | You, once now and again later | Nowhere | You reread it to find out what it wanted |
| Retype it into a to-do app | You, twice over | You, from what you remember of the message | A second pass on every message that asks anything |
| Forward it to a task tool’s intake address | You, to judge that it qualifies | Whatever you typed in the subject line | The task arrives without the thread behind it |
| The mail client reads the message itself | The software, on everything that arrives | The message, the thread, or you | A judgment you have to be able to check |
Only the last row takes the reading off you. It’s also the only one that holds up as the mail gets heavier. In the other four, a person is the mechanism that turns a message into a commitment, and that 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 still reads as current. The shape of the problem has held. Quality Versus Quantity ran 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 they followed eleven people closely. Filters captured every message in and out for seven of them. Video caught all eleven working through their mail, and interviews ran 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. Then she describes the slip: “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 labor: “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’s a good system, run by a disciplined person. It’s also exactly the transcription this page is about removing. Notice the price. He reads every flagged message a second time, because the flag recorded that something mattered and stopped there. (Quotes of this kind come from detailed interview notes rather than transcripts, the authors say, so take the wording as close rather than exact.)
Filing costs you something too. 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. Their video showed roughly a fifth of all email time going on organizing and searching rather than reading or writing. Of that, 9.5% went on filing and 2% on hunting for a message they knew was already there. That’s eleven people in one American research lab, on the clients of 2004. Read the percentages as a shape rather than a measure of your own week. The shape is what lasted.
The obvious repair is a dedicated task app, fed by hand from the inbox. That moves the copying and adds a question: which of the two surfaces is now the true one. One surface instead of six apps makes that argument properly, and it’s a separate argument from this one.
How a machine finds the ask
Requests are common. Lampert’s team put 664 messages from the Enron archive in front of three annotators each. All three agreed on 505 of them, and 52% of those contained a request. What makes them hard is that a request rarely announces itself.
Their own example is the clearest. David will send you the latest version if there have been any updates. If David’s copied in, that sentence is a request aimed at him. It’s phrased as somebody else’s promise, and it hangs on something that may never have happened. Any person reading it understands instantly. A rule written to catch that sentence catches almost nothing else. That’s why rules have never worked for this.
Then there’s where the sentence sits. A message comes in parts. There’s 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 judged correctly whether a message contained a request 72.28% of the time. Reading only the author’s own text plus the greeting and signoff, it was right 83.76% of the time. That cut 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. The phrase they name is one you’ve written this week: let me know if you have any questions. Sometimes that sentence is an obligation. Sometimes it’s punctuation. The rest of the message is what tells you which.
A decade later the job looks much the same, with better tools. Smart To-Do is a 2020 paper for the Association for Computational Linguistics. Sudipto Mukherjee, Subhabrata Mukherjee, Marcello Hasegawa, Ahmed Hassan Awadallah and Ryen White reported a classifier that picks out the sentences where a sender has promised to do something. It ran 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, and worth a look before you lean on it.
That gives you the honest description of automatic capture. The software forms a view on every message that arrives. It gets most of them right. Then it puts that view somewhere you can see it and change it. Whether to 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 arrives as a phrase rather than a date: by Friday, end of next week, before the board meeting, first thing Monday. Turning those into a day on the calendar takes two things: when the message was sent, and what day it is now. That’s the one piece of context software always has.
Implied by the work behind the message. This is the case people underestimate. Characterizing and Predicting Email Deferral Behavior is 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. They 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 lives entirely outside the message.
Chosen by you. Plenty of asks arrive with no deadline anywhere. That makes the date a decision. Good software asks you for it once, while you’re already looking at the thing, rather than leaving the field blank and hoping.
A real when matters more than it sounds like it should. Consider It Done is 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, then set out in detail how, when and where they’d do each one. A third wrote about tasks they’d recently finished. Then all of them read the opening of a novel. Four times they were interrupted and asked whether their attention had been on the story. Among those who’d only named their unfinished tasks, 65.2% had drifted off at least once. Among those who’d made a plan, 33.3% had. The planners also reported fewer intrusive thoughts about the tasks and answered more of the comprehension questions correctly.
Here’s the detail that matters. Planning left their confidence of finishing exactly where it was. The authors put the active ingredient as “preparation rather than expectation”. Naming the when 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. Four of the seventy-three were dropped for guessing the design. Take the direction and hold the figure loosely. The direction is the one every working manual system already assumes.
One thing to hold onto here: a date is not a priority. Treat the two as one measurement and a quiet obligation loses to a noisy one, which is the usual way it happens. Important versus urgent separates them.
What you still decide
A task appearing on a list is where the software’s work ends and yours begins. Three judgments stay exactly where they were.
Whether it’s yours at all. Lifting an obligation out of a message establishes that somebody owes it. Which of you is the question the message leaves open, and in a small firm that gap is where work quietly dies. There’s a guide for exactly that gap: when work falls between you.
Whether it survives what you know. The client canceled on the phone this morning. The deadline moved in a meeting nobody minuted. Software reading your mailbox sees none of that, and it should say so plainly.
What it’s worth against everything else you owe. A dated list feeds that decision. You still make it.
One more stays with you, quieter than the other three, and the Smart To-Do team measured it by accident. 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. 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. That leaves four in ten where at least one of them disagreed. 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 load-bearing. Any task lifted out of a thread is a summary, and summaries lose things whoever writes them. The task keeps the thread attached, so an ambiguous phrase is one tap from the words that caused it.
The same goes for how far the software runs on its own. That’s a level you set, rather than a policy the product hands you. And it works better as one level per sort of action. Creating a task from a message and answering a client carry different risk, and a single switch prices them the same.
What automatic capture cannot do
The same amount still gets asked of you. The same obligations arrive. What changes is that catching them stops depending on you noticing at the moment they land.
It sees what came through the mailbox. The promise made on a call, the favor agreed in a corridor, the thing your partner took on and kept to themselves. Those still get written down by hand. A system that captures email should be straight that it covers one channel well, and that there are other channels.
Planning your week stays yours. A complete list of dated obligations is raw material for a schedule. The relief of putting them down is real, and deciding what to do first is a separate act.
It will get some wrong. The two mistakes cost different amounts. A task you didn’t need is gone in a moment. An ask that stayed buried is the one your client eventually asks you about. So the thing to judge is how cheap a correction is, more than how rarely it errs.
How Point does this
Point is a full email client, so the reading happens where your mail already is. Overnight mail is sorted into now, later and other before you open it. When a message puts work on you, Point lifts it out as a task. The task carries its due date, its priority and the thread it came from. Nothing is typed in. One tap goes from the task to the sender’s own words. The two stay joined, so the original is always there behind the summary.
Every task Point finds lands in one list, next to the ones you added yourself and the ones from any other business you run. Point notices when something’s done. Answer the email the ordinary way, and leave the task alone. Point marks it as looking finished, shows you why in plain words, and waits for you to agree or keep it open. The rest of what Point handles in your mail sits on the benefits page.
Point runs at a level you set, and each sort of action has its own. Point can suggest only, 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. Point prepares the work and waits for your review. Raising one is a deliberate move you make. Point’s 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 Point keeps that as a standing preference and applies it next time.
Common questions
Is email task management the same as email triage?
They’re two passes, and they run in that order. Triage ranks the arriving pile: this one now, this one later, this one never. Task management takes whatever survives and asks the next question. What does this message oblige 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. A separate tool earns its place for work that lives outside 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?
One action dismisses it, and you lose nothing you’d miss. That’s a fair thing to check in a trial. It happens in the first week, and how it feels then decides whether you keep the software. Watch whether a correction holds, too, or whether you make the same one 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. Often the deadline belongs to the project and was agreed somewhere else, and then the answer is no. The workable arrangement is simple. The software proposes a date when it has grounds for one, and asks you when it has none, rather than leaving the field empty.
Does this work for a two-person firm?
It suits one. A small practice runs without an intake process or a queue: work arrives addressed to whichever of you the client happens to know. Two things matter. Tasks stay personal rather than pooled, so each of you sees your own obligations. And a task carries its thread, so handing one over takes a single move instead of forwarding four emails as context.
The short version
Email task management is the arrangement you already have, designed or not. Mostly it’s a person rereading flagged messages at the end of the day and retyping them with dates. That works exactly as long as the day allows. The automatic version takes the retyping off you. The ask is found where it sits. The date comes from the message, the thread, or from you. The task keeps a link back to the sentence that caused it. The deciding stays yours, and that 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 very different from the ones in an architecture practice, and six other trades have their versions written out.