A business message designed for the inbox scan - subject line doubles as summary, body leads with action, and the reader never needs to re-read to know what is being asked.
Business email is not a letter. Letters open with pleasantries and build toward the point. Email readers scan - they do not read start to finish, and they especially do not read the part before the point. An effective business email leads with the subject line as a compressed summary and opens the body with the purpose and required action, not with a greeting that delays both. The test is simple: can the reader act on this email without re-reading it?
The subject line carries more weight than most writers give it. It is the only text many recipients will read before deciding whether to open the message. A strong subject line is specific enough to act on: “Review and approve Q2 budget draft - needed by Friday” outperforms “Q2 Budget” in every measurable way. The subject line is the summary; the body is the detail.
Email is durable. Unlike a Slack message, email creates a record and travels beyond the immediate team. This means the action requested must be explicit (who does what by when), the context must be self-contained (assume no conversational history), and the tone must be appropriate to the relationship, not just the channel. An email that requires a follow-up question to understand has failed at its job.
Canonical template
Section titled “Canonical template”Subject: [Specific topic - action needed, decision required, or FYI - date or deadline if relevant]
[One sentence: what this email is about and what action, if any, is needed from the reader]
[2-4 sentences of context or supporting detail - only what the reader needs to act]
[Explicit next step: what, who, by when][Optional: secondary next step or offer to discuss]When to use
Section titled “When to use”Email is the right format when you need a durable record, when you are reaching external parties or stakeholders outside the immediate team, or when a request has a specific owner, deadline, or approval gate. It is also appropriate for formal announcements to a broad or mixed audience where structure and tone reflect organizational relationships.
When not to use
Section titled “When not to use”Email is the wrong format for quick back-and-forth that belongs in a chat channel, for real-time coordination during incidents, or for topics so sensitive they require a conversation before anything is put in writing. If the message will be read inside a high-noise thread rather than a personal inbox, the format advantage is lost.
Pairs well with
Section titled “Pairs well with”direct-communicator, executive, candid, matter-of-fact, warm
Often confused with
Section titled “Often confused with”slack-message: Slack messages are designed for team channels, are ephemeral, and tolerate a conversational opening. Email creates a record, travels outside the team, and must be self-contained - the subject line and body structure carry obligations that a Slack message does not.
Instruction
Section titled “Instruction”Write as a business email. The subject line should be specific enough to act on - it doublesas the summary of the message. Open the body with the purpose and required action immediately,not with pleasantries. Include only the context the reader needs to take the next step. Statethe next step explicitly: who does what, by when. The reader should be able to act on thisemail without re-reading it. Match tone to the relationship - direct but not cold for colleagues,slightly more formal for external or senior recipients.Template
Section titled “Template”See the Email template.
Related
Section titled “Related”Pairs well with
Section titled “Pairs well with”Direct Communicator, Executive, Candid, Matter of Fact, Warm
Avoid with
Section titled “Avoid with”Pastoral, Reverent, Devotional Reflection
Often confused with
Section titled “Often confused with”Examples
Section titled “Examples”From: Maya Chen <maya.chen@company.com> To: eng-platform@company.com Cc: Priya Raman <priya.raman@company.com> Subject: Starting Monday: 30-day async standup trial - post by 10am local, no more 9am Pacific call
Team,
Starting Monday May 19, we are running a 30-day trial of an async-first standup. The 9am Pacific sync call is paused for the trial. Here is what you need to do and why.
What changes
- Post a daily update in #team-standup by 10am your local time. Three fields, pinned template at the top of the channel:
- Shipped (last 24h)
- In progress
- Blocked / at risk - @mention the person who can unblock
- The Thursday 9am Pacific slot becomes a 60-minute working session, not a status meeting. Agenda posted Wednesday EOD.
- On-call engineer reads #team-standup by 9am Pacific each day and responds to blockers within 30 minutes during business hours.
Why now
Q1 attendance was 4.6/5 for US, 3.2/5 for India - because 9am Pacific is 9:30pm IST. We average 14 minutes per standup with about 4 minutes that actually changes someone’s behavior. And the verbal status doesn’t persist - we hit three duplicate-work incidents last quarter that a searchable channel would have caught.
What I need from you
- Post your first async update Monday May 19 by 10am local.
- If the template doesn’t fit your work that day, post anyway and say so. Consistency matters more than format for the trial.
- Bring friction to the Thursday session or DM me directly. We will review at day 15 and day 30.
If you have concerns before Monday, reply to this thread or grab time on my calendar.
Thanks, Maya
Maya Chen Engineering Manager, Platform maya.chen@company.com | Slack: @maya
From: jordan.p@example.com To: dana.coach@example.com Cc: Subject: Week 5 check-in - morning routine is sticking, need your read on one thing
Dana,
Quick update and one question before our session Thursday.
Status: Five weeks into the morning routine we designed in March. Adherence is at 26 of 35 weekdays. The four modules (water, light, movement, paper planning) are now automatic enough that I do not think about the sequence, only the execution. Phone stays in the kitchen until 7:30am with no slips since week 2.
What is working:
- Arriving at 9am with a written shortlist has changed the texture of the work day. Less drift, fewer Slack-driven priorities.
- Light module is doing more than I expected. The mornings I skip it feel measurably flatter by mid-afternoon.
What I want your read on: The planning module is starting to bleed past 10 minutes. Some mornings it stretches to 20 because I am pulling weekly priorities into the daily list and getting tangled. Two options I am considering:
- Hold the 10 minute cap firm and add a separate Sunday evening planning block for the weekly view.
- Let weekday planning float to 15-20 minutes but accept the morning routine extends to 75 minutes total.
I lean toward option 1, but I want to make sure I am not just defending the original spec.
Thursday at 4pm still works on my end. I will bring the notebook.
Thanks, Jordan
Email - Database Decision Recommendation
Section titled “Email - Database Decision Recommendation”To: Priya Shah <priya@latticenotify.com> Cc: Marcus Chen <marcus@latticenotify.com> From: Ana Rivera <ana@latticenotify.com> Date: 2026-05-14 4:12pm Pacific Subject: Notification service datastore - recommending Postgres, decision needed by Friday
Priya - recommending we go with Postgres for the notification service, and asking you to lock the decision in our 11am Friday sync so the team can plan next sprint.
Background: yesterday’s architecture meeting compared Postgres (extend our current cluster, add a pg_notify-backed job queue) against DynamoDB (new datastore, better access-pattern fit for our 500K events/day launch load). Marcus and I aligned on a single recommendation overnight.
Why Postgres: our 8 backend engineers and 4-person on-call rotation already operate it at our scale. Adopting DynamoDB doubles the operational surface and we have no rollback plan if it goes wrong. The access-pattern advantage Marcus correctly identified is real but smaller than the operational cost at our current team size. We have a documented 5M events/day revisit threshold; if the Slack deal lands and we cross it, we have ~3 months of warning to plan a migration. Full reasoning is in ADR-0023 (draft) - link in #notify-arch.
What I need from you:
- Confirm the decision is locked at our 11am Friday sync so I can mark ADR-0023 Accepted before sprint planning at 2pm
- Confirm I should communicate the decision out to the broader engineering team in Friday’s all-hands update
Happy to walk through the reasoning in detail before Friday if useful - I have a 30-min slot open at 9am or 1:30pm tomorrow.
Ana