KoltrixHow to write a prompt that summarizes a long email thread
Build a reliable prompt for summarizing long email threads: purpose, audience, a fixed output format, exact numbers and flagged uncertainty, plus an example.
On this page(8 sections)
- Why the default prompt falls short
- The five elements of a good summary prompt
- 1. Purpose
- 2. Audience
- 3. A fixed output format
- 4. Exact numbers and dates
- 5. Flagged uncertainty
- The prompt
- A worked example
- The bare prompt's output
- The structured prompt's output
- Variations for other situations
- Saving the prompt so the team uses it
- Checking the summary
- Key takeaways
"Summarize this thread" works, sort of. You get a tidy paragraph that sounds right, leaves out the one number you needed, and doesn't mention that two people disagreed. A better prompt takes a minute to write once and fixes all of that.
This guide builds a thread-summary prompt step by step, then runs it on a sample thread so you can see the difference.
Why the default prompt falls short
A bare "summarize this" leaves the model to guess three things:
- Purpose. Are you catching up, making a decision, or handing the thread to someone else?
- Audience. You, who know the background, or a new teammate who knows nothing?
- Format. A paragraph? Bullets? What sections?
When the model guesses, it tends toward a generic narrative summary: who wrote what, in order. That's rarely what you need. You usually want the current state: what's decided, what's open, and who owes what.
The five elements of a good summary prompt
1. Purpose
Say why you want the summary. "I'm taking over this customer from a colleague and need to reply today" produces a very different result from "I want a record of what we agreed".
2. Audience
Tell the model who will read it. "For a teammate who has never seen this thread" makes it explain names and background. "For me; I know the customer" lets it be terse.
3. A fixed output format
This is the biggest improvement. Give explicit sections:
- Status: one or two sentences on where things stand now.
- Decisions: what has been agreed, by whom.
- Open questions: what's unresolved.
- Action items: who owes what, by when.
- Key details: numbers, dates, names, links.
Fixed sections force the model to look for each kind of information, and make summaries comparable across threads.
4. Exact numbers and dates
Models sometimes round or paraphrase figures. Tell it explicitly to copy numbers, prices, dates and deadlines exactly as written, and to say which message they came from when there are conflicting versions.
5. Flagged uncertainty
Ask the model to mark anything ambiguous instead of resolving it silently. "If people disagree or a point is unclear, say so" prevents a summary from presenting one side of a disagreement as the conclusion.
The prompt
Here's a version that combines all five. Adjust the purpose and audience lines each time.
Summarize the email thread below.
Purpose: I'm taking over this conversation and need to reply today.
Audience: a teammate who hasn't seen this thread.
Use exactly these sections:
1. Status - one or two sentences on where things stand now.
2. Decisions - what has been agreed, and who agreed to it.
3. Open questions - anything unresolved or disputed.
4. Action items - who owes what, with dates if given.
5. Key details - copy every number, price, date and deadline exactly
as written. If versions conflict, list each with who said it.
Rules:
- Base everything on the thread only. Don't infer facts that aren't stated.
- If something is ambiguous or people disagree, say so explicitly.
- The latest messages override earlier ones; note when something changed.
- Keep it under 200 words.
Thread:
[paste thread here]
A worked example
Here's a condensed sample thread between a SaaS company and a customer (fictional).
1. Customer (Mar 3): We'd like to move from monthly to annual billing for
our 12 seats. Can you confirm the annual price?
2. Account manager (Mar 3): Annual is $1,440 for 12 seats. I can apply
it from your next renewal on Mar 15.
3. Customer (Mar 5): Our finance team asked if we can add 3 more seats
before switching. Would that change the price?
4. Account manager (Mar 6): Yes, 15 seats annual would be $1,800.
5. Customer CFO (Mar 8): We'd prefer to start annual on Apr 1 to align
with our quarter. Is that possible?
6. Customer (Mar 9): Also, can the invoice show our new company address?
I'll send it separately.
The bare prompt's output
The customer wants to switch to annual billing and asked about pricing. The account manager confirmed annual pricing and offered to apply it at renewal. The customer later asked about adding seats and changing the start date, and mentioned updating their company address on the invoice.
Readable, but useless for replying: no numbers, no decisions, no indication of what's still open.
The structured prompt's output
1. Status: Customer wants annual billing for 15 seats; start date and invoice address are still open.
2. Decisions: Annual billing agreed in principle. Seat count increased from 12 to 15 (customer request, Mar 5; priced Mar 6).
3. Open questions:
- Start date: account manager proposed Mar 15 (renewal); customer CFO asked for Apr 1 on Mar 8. Not yet answered.
- New company address: customer said they would send it separately; not received in this thread.
4. Action items:
- Account manager: confirm whether Apr 1 start is possible.
- Customer: send the new company address.
5. Key details:
- 12 seats annual: $1,440 (Mar 3), superseded.
- 15 seats annual: $1,800 (Mar 6), current.
- Proposed start dates: Mar 15 (account manager) vs Apr 1 (customer CFO).
That's a summary you can reply from. It shows the price changed, the start date is disputed, and something is still missing.
Variations for other situations
Swap the purpose and sections for different jobs:
| Situation | Change to the prompt |
|---|---|
| Quick catch-up for yourself | Audience: "me, I know the background". Sections: Status and Action items only. |
| Escalating to a manager | Add a section: "Risks - anything that could cost money or the relationship". |
| Handoff to engineering | Sections: Problem, Steps to reproduce, Customer impact, What's been tried. |
| Record for the account file | Add: "Commitments we made, with dates" and drop the word limit. |
Saving the prompt so the team uses it
A prompt that lives in one person's head helps one person. Put the final version somewhere everyone can copy it: a shared doc, a snippet in your support tool, or a saved instruction in the AI assistant your team uses. Give each variation a short name ("handoff summary", "account record") so people ask for it by name. When someone finds a case where the summary missed something important, add a line to the prompt and note the date. After a month you'll have a prompt shaped by your own threads rather than a generic one, and summaries across the team will follow the same format, which makes them much faster to read.
Checking the summary
Even a good prompt doesn't make the summary authoritative. Before you act on it:
- Spot-check numbers against the original messages.
- Read the last two messages yourself. That's where the current state usually lives.
- Be wary of anything the summary states confidently that you didn't expect. Open the source message.
- Remember quoted text and signatures can confuse the model about who said what in long threads.
A summary is a map, not the territory. Use it to decide where to look, not to replace looking when the stakes are high.
Key takeaways
- Tell the model the purpose and the audience; it changes what a good summary contains.
- Use fixed sections: status, decisions, open questions, action items, key details.
- Require exact numbers and dates, with conflicting versions listed.
- Ask the model to flag ambiguity instead of resolving it.
- Verify numbers and read the latest messages before acting on any summary.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
