A summary email is a short account of a longer exchange, so somebody can know what it holds without reading all of it. The phrase covers two jobs pointing opposite ways: the recap you send after a meeting, and the summary written for you about a thread you have not opened yet.
- The two jobs are one artefact aimed in different directions. What makes a recap worth sending is what makes a thread summary worth trusting.
- A conversation list shows you a sender, a subject and the opening words of the newest message. None of the three is an account of what the conversation contains.
- Four things decide whether a summary can be acted on: what it is about, what is being asked, who is asking, and where it has got to.
- A summary is a judgment rather than a fact. Two people reading the same document pick the same sentences less than a third of the time, which is why the test is not whether a summary is correct, but whether the thread stays one click behind it.
What is a summary email?
Two quite different things go by the name, and both are real.
The first is the one you write. A meeting ends, five people leave with four versions of what was agreed, and somebody types out what happened and sends it round. That is a summary email in the sense most people search for: a recap, a note of a call, a weekly update to a client. It is written for somebody else’s inbox, and its job is to turn a conversation into something a person who was not fully paying attention can still act on.
The second is the one you read. A thread you have never opened sits in your list, eleven messages long, and something has already told you what it is about and what it wants from you. That is a summary email in the sense that changes a working morning, and until recently nobody could offer it, because writing one for every conversation in a full inbox is more work than reading the inbox would have been.
The two are the same artefact facing opposite ways. In both cases somebody has read a conversation you did not read, and is handing you a short version so you can decide what to do. The difference is only who did the reading. Which means the standard is the same in both directions, and the recap is the easier place to see it, because you have written one and know exactly when it failed.
What goes into a summary email you send
Think about the recap you would actually want to receive.
Not minutes. Nobody reads minutes, and a transcript of who said what in which order is a record of a meeting rather than an account of it. What a good recap carries is short and roughly always the same four things: what was decided, who is doing what, by when, and what was left open. The fifth thing is a pointer, so anyone who wants the detail knows where the detail lives.
The last of those is the one people leave out, and it is the one that causes the follow-up email. A recap listing three decisions and silently omitting the two questions nobody answered reads as complete. Everyone files it. Three weeks later the unanswered question turns out to have been the expensive one, and there is no record that it was ever raised. What was not settled is part of the account, not an admission that the meeting went badly.
The test is worth stating plainly, because the rest of this guide runs on it. A summary works if somebody who was not there can act from it without asking you a question. Not if it is elegant, not if it is short, not if it covers everything. If the reader has to reply asking who is sending the schedule, the summary failed at the only thing it was for.
Send it the same day, in the words your reader uses rather than the words your profession uses, and keep it to something that fits on a phone screen. That is the whole craft of it.
Now turn it round. Those four things, and that test, are exactly what you want out of a thread you did not write and have not read. If you would expect a colleague to hand you the decisions, the owners, the dates and the open questions, you should expect the same of anything that offers to summarize your inbox. Most things that offer to do not.
Why a preview is not a summary
Open any mail app and look at what a single row in the list actually gives you. A name. A subject. A time. Then a fragment of text, usually the first few words of the most recent message. Four pieces of evidence, and you make the decision to open or not open on the strength of them, a hundred or so times a day.
Each one fails in its own specific way.
The sender tells you who is speaking, not what they said. It is genuinely useful, and it is the reason a list of names is the first thing anybody sets up. But your best client emails you about a signature, about a new company, and about their holiday, and the name is identical on all three.
The subject was written once, at the start, by whoever began the thread. It described a message that no longer exists in the form it was written about. By reply nine the conversation has moved, and the subject has not, because nobody edits a subject line mid-thread. Anyone who has answered “Re: Re: Fwd: March” knows the subject is a thread identifier, not a description.
There is a measurement of how little a subject line carries, from a slightly unexpected direction. In This Email Could Save Your Life, presented at the 2019 meeting of the Association for Computational Linguistics, Rui Zhang and Joel Tetreault built the first corpus for teaching a machine to write subject lines, 18,302 emails out of the Enron archive. What they found about the task is the interesting part for a reader rather than a researcher: subject line writing “favor[s] extremely abstractive summary”, which sets it apart from writing a news headline. A headline is largely made of the article’s own words. A subject line is largely not made of the email’s own words. So the traffic does not run backwards either. You cannot get the message out of the subject, because most of the message was never in it.
The snippet is the opening words of the newest message, which is the least informative message in the thread. Conversations end in acknowledgement. “Thanks, that works.” “Will do.” “Adding Priya.” Attach the sender’s signature block or a mobile footer and the preview is a phone number. The one place the software could have told you something, it spends on the sentence that carried the least.
The time tells you when, and nothing else. It is the axis the list is already sorted on, and the axis with the least to do with whether you should open the thing.
So the row is not a bad summary. It is not a summary at all. It is four facts about a message’s packaging, and none of them is an account of its content. A preview is a fragment of one message; a summary is an account of a conversation. The difference is a difference in kind, and no amount of showing more preview characters closes it.
What a summary has to carry
There is a decent public record of what people ask for when they commission summaries of email specifically, rather than of documents.
In EmailSum, presented at the 2021 meeting of the Association for Computational Linguistics, Shiyue Zhang, Asli Celikyilmaz, Jianfeng Gao and Mohit Bansal built a corpus of 2,549 email threads out of a real corporate archive, each thread three to ten messages long, and had every one of them summarized by hand twice: once short, under thirty words, and once long, under a hundred. The instruction to the annotators for the short version was to write “a concise and abstractive description of what the thread is mainly talking about”. For the long version, “a narrative of what happens”, coherent rather than a message-by-message list, focused on “the major concerns, decisions, and consensus”, and in their own words rather than lifted out of the mail.
Their averages are the useful part. A thread in that corpus runs 233.2 words across an average of 4.5 messages. The short summary of it runs 27.1 words. About one word in nine survives, which means eight in nine are being discarded by something that is not you, on a judgment you did not make and cannot see. That is the actual trade, and it is why what survives has to be the right eight per cent rather than merely a fluent eight per cent.
Four things have to be in there.
- What it is about, in a phrase, and in terms that mean something to your business rather than the sender’s own subject line. “Deadline change on the Henderson VAT registration” rather than “March”.
- What is being asked of you, if anything. This is the requirement that gets missed most, and the EmailSum authors measured the failure precisely: the models they tested tended to “overly focus on details” and lose the sender’s high-level intention, whether the message was starting a discussion, broadcasting a decision, or asking for something. A summary listing four accurate facts while omitting that somebody needs an answer by Thursday is worse than no summary, because it reads as complete.
- Who. The second frequent failure in the same study was misattribution, summaries putting information in the wrong person’s mouth, which the authors classify as a kind of unfaithfulness rather than a stylistic slip. In a six-person thread, “they want it by Friday” is not a summary of anything. The client wanting it, the junior promising it and the supplier refusing it are three different situations wearing one sentence.
- Where it has got to. Decided, waiting on someone, blocked, or gone quiet. This is the state of the conversation rather than its content, and it is most of what you actually need when the thread has been running for a fortnight and you last looked on Tuesday.
And one thing that is not content at all: the thread itself, one click behind the summary. Which is the subject of the next section, because the reason it has to be there is not convenience.
Whose summary is it?
Here is the awkward fact underneath all of this. There is no such thing as the correct summary of a conversation. There is only the summary somebody wrote, and people writing about the same thing do not write the same one.
The clearest recent measurement of that comes at the question sideways. Language Models Agree With Each Other, Not With Readers, a preprint posted on 31 July 2026 by Kazuki Nakayashiki and Keisuke Watanabe, was written to test whether AI models are converging on a single voice. Rather than commissioning judgments for the study, which they argue makes the human side an artefact of the instructions given, they used a reference nobody built for the purpose: 2,523 sets of highlights that real readers had made across 120 web documents, on a platform where you cannot see anybody else’s marks by default. People marking what mattered to them, for their own reasons, with no task and no audience.
On a median document of 70 sentences, each party named 14. Two readers shared 4.1 of them. Two models shared 8.7.
Take the readers’ number seriously before the models’. Two people reading the same piece, both marking what mattered, overlapped on under a third of their choices. Not because either was careless. Because what matters in a document is a function of who is reading it and what they have to do next, and those two things were different. The paper’s other finding cuts the same way: no model agreed with the readers detectably more than another reader did. It is a preprint, its material is web documents rather than email, and the readers were highlighting for themselves while the models were given a task, all of which the authors say themselves. The direction still holds, and anybody who has read two people’s notes from the same meeting already believed it.
The EmailSum team ran into the same wall from the other side. When they checked whether the standard automatic scores agreed with human opinion of their summaries, the best correlation they could find was between ROUGE-1 and overall human ranking of the short summaries, at 0.14 with a p-value of 0.16, which is to say no relationship worth the name. Their human raters, scoring on five-point scales, agreed with each other at between 0.09 and 0.23. Not only is there no single right summary, there is no reliable agreement on whether a given one is any good.
Two things follow, and they are the whole design.
The source has to stay one click behind. If a summary is a judgment made on your behalf, you need to be able to check it in the time it takes to be suspicious, on the thread, in place, without navigating anywhere or hunting for the message. A summary you cannot get behind is not a summary, it is a replacement, and replacing your mail with a paraphrase of it is a bad trade at any accuracy.
It has to be correctable, and the correction has to stick. Since the right summary depends on who is reading, a summary written to a general standard will be wrong for you in a consistent, boring, repeated way: too long, or missing the dates, or burying the ask in a narrative. That is not a defect in a particular summary. It is the gap between a general reader and you, and the only fix is for the thing to learn what you want and keep it. Making the same correction twice is a fault.
What a summary is not for
Four boundaries, and each of them is a job somebody expects the summary to do.
It does not tell you what matters. A summary says what a thread is about. Whether it needs you today, tomorrow or never is a separate measurement, taken on different evidence, and a beautifully accurate summary of a newsletter is still a newsletter. Sorting the inbox by what it costs to ignore is its own discipline, worked through in how email triage works, and the reason one score cannot carry it is in important versus urgent.
It does not become the task. A summary can say that the client needs the accounts by the fourteenth. Something with a date on it, sitting where you keep your commitments, is a different object with a different lifespan, and email task management covers how an ask inside a paragraph turns into one. A summary hands the task off; it is not a substitute for having one.
It is not a digest of your day. One thread, one account. A briefing across everything that arrived is a separate thing that answers a separate question, and the two get confused because both are short. If you find yourself wanting a weekly summary email of your own inbox, what you want is the briefing, not longer summaries.
It is not the record. Where the stakes are real, you read the thread. A summary tells you which threads those are, which is a different and more useful thing than pretending to save you from them. Nobody should be advising a client, signing anything, or quoting a figure back to a tax authority off a paraphrase, and any tool suggesting otherwise is selling you a risk you did not price.
How Point writes one for every thread
Point is a full email client rather than a button added to the one you have, so the reading happens before you arrive rather than after you click. Every conversation carries a plain summary written by Point, and the feed is built in three depths you move between with single clicks.
The first depth is the line in the feed. A few words, a marker for whether it needs you now, and a time. Point’s own description of it is the honest one: often that line is all you need to read, and the thread is finished without ever being opened.
The second is the summary card. One click, opening in place with nothing navigated away, condensing a four-paragraph message into a short account with the decisions in it. You can act from there, replying, setting it aside, or filing it. How much Point handles unprompted is a setting held separately for each kind of action, and it opens on review, so out of the box the work arrives prepared and stops there.
The third is the mail itself. One more click and you have the original, with real headers and the full formatted body, exactly as it arrived. Nothing is hidden behind the summary, and one click goes back. You are choosing the depth thread by thread rather than being given a fixed one, which is the part that makes the summary safe to trust: it is never the only copy of anything.
Where a thread has grown attachments, a meeting and a task around it, those are drawn into the same expandable idea rather than scattered, so the summary you open is of the whole situation and not just the last mail in it. And when Point’s idea of a summary is not yours, you say so in a sentence and Point keeps it as a preference from then on, applied fresh to the next thing that sender sends.
What an AI email client is covers why the summarizing has to live in the client rather than beside it, and the benefits page lists what else comes with reading the mail before you do.
Common questions
What should a meeting summary email include?
What was decided, who owns each piece, by when, and what was raised and left unsettled, plus a pointer to where the detail lives. Then check it against one test: could somebody who was not in the room act on it without replying to ask you a question. The open items are the part most people cut, and the part that costs the most when it is missing.
Can I trust an AI summary of an email?
Trust it for the decision it is built to support, which is whether to open the thread, and treat it as a paraphrase for everything else. It is a judgment rather than a fact, and the measured disagreement between two human readers about what matters in the same document is large enough that “correct” is not really the standard on offer. What makes it safe is not accuracy alone but that the original stays one click away, so checking costs a second.
How long should an email summary be?
Short enough to read without deciding to read it. The hand-written corpus above compresses a 233-word thread into about 27 words, roughly one word in nine, and that ratio is a reasonable expectation for the version you scan. Longer summaries have their place once you have decided a thread matters, but a summary you have to commit to is doing the job of the email.
What is the difference between a summary and a preview?
A preview is the opening characters of the most recent message. A summary is an account of the whole conversation. The preview is drawn from the least informative message in the thread, since replies end in acknowledgements, and it cannot mention anything decided four messages ago. Showing more preview text does not turn one into the other.
Do I still need a weekly summary email?
If it is a report you send a client, yes, and it is one of the things worth writing by hand. If you mean a weekly digest of your own inbox, that is a briefing across many threads rather than a summary of one, and the two solve different problems. Per-thread summaries are for deciding what to open; a briefing is for knowing what the day contains.
Does this mean I stop reading my email?
No. It means you stop opening threads in order to find out what they are, which is most of what opening currently buys you. Reading becomes something you choose to do because the summary told you the thread deserves it, rather than the only way to learn anything at all.
The short version
A summary email is an account of a conversation written for somebody who did not read it, and it works when its reader can act without asking a question back. Your inbox has never offered you one. It offers a sender, a subject written before the conversation happened, and the first few words of the least informative message in the thread, and asks you to decide from that a hundred times a day.
What a real summary has to carry is short: the subject in a phrase, the ask, who is asking, and where it has got to. What it has to admit is that it is one reading among several, which is why the thread stays one click behind it and why a correction has to stick. Get those right and the summary is not a shortcut past your mail. It is the thing that tells you which mail is worth your full attention, and lets you spend it there.
How much that is worth depends on the mail. A twenty-message thread means one thing to a tax practice in February and something else to a coaching business in any month, and the morning is written out eight ways if yours is neither.