Treat the example schedules below as starting points to adjust to your circumstances.
Consider a fictional work message with the subject “Following up” and several paragraphs ending in “Thoughts?” The recipient may not know the requested action. The repair is to identify the decision, owner and deadline before adding background.
Work email helps a recipient act on a request. This guide offers example structures for subjects, requests and replies. Adapt them to your organisation; response times and subject lengths are working choices, not universal rules.
The subject line is competing with forty others
Your subject line gets read in a list alongside dozens of others. "Quick question," "Hello," "Following up," and "Checking in" lose that competition every time. A subject that tells the reader what the message is about, what they need to do, and by when gets opened first and answered first.
One example format is “[Type] Specific content (deadline)”. The following examples are fictional.
- [Request] Q3 revenue figures: confirm August numbers (by Thu 9/12 AM)
- [FYI] Notes from Tuesday's vendor meeting (no reply needed)
- [Review] Contract clause 4 revised wording (by 9/15)
- [Urgent] Server maintenance window moved to today 6 PM
The bracketed tag tells the reader in half a second what kind of action the email demands. A request needs an answer. An FYI needs to be read and filed. A review needs judgment and comments. If your company already uses a convention, follow it; if not, it's fine to start one within your own team and let it spread.
Keep subject lines under about 50 characters, which is roughly what a phone screen shows before truncating. Longer than that and the deadline, the most useful part, gets cut off. And when a thread drifts to a new topic, change the subject line. A budget approval buried under "Re: Re: Re: lunch spot for Friday" will never be found again by anyone, including you.
The ask belongs in the first three lines
The structural rule is that conclusions go first and background goes last. Most people read the preview pane, which shows two or three lines, and make a triage decision. If the ask isn't in those lines, the message goes into the "read later" pile, and later rarely comes.
An example body structure:
| Position | Content | Length |
|---|---|---|
| Line 1 | Greeting plus one sentence stating what you need | 1–2 lines |
| Block 2 | Specifics: what exactly, by when, in what format | 3–5 lines; numbered list if more than one item |
| Block 3 | Background, reasoning, context | As long as needed, often optional |
| Last line | Restate deadline, offer a way to reach you | 1 line |
A fictional rewrite of the unclear request:
"Hi Dana, I need you to confirm the August figures in the Q3 revenue sheet. Three cells highlighted in yellow on tab 2 of the attached file don't match the sales team's report; if you can tell me which version is correct by Thursday morning, I'll fix it before Friday's review. Background on where the discrepancy came from is below."
That's three sentences containing what (confirm August figures), where (tab 2, yellow cells), by when (Thursday morning), and why (Friday's review). The six paragraphs of history go underneath, and a busy reader can answer without reading them.
If you have more than one ask, number them. Three requests mixed into one paragraph reliably produce a reply addressing one of them. Numbered items let the other person respond in kind: "1 is done, 2 by next week, 3 after I check with the vendor." It's easier for both of you.
Attachments should be named in the body, specifically. Not "please see attached," but "the attached quote (PDF, 2 pages): I need you to check the total on page 2." And attach the file before you write the body. Everyone forgets attachments, including people with twenty years of experience, and the only reliable fix is a sequence change: attach first, write second.
Tone is set by distance, not by mood
The same request reads differently going to the person at the next desk versus a client's vice president. The variable is the distance between you and the reader, and misjudging it means the tone lands before the content does.
| Recipient | Opening | Register | Avoid |
|---|---|---|---|
| Teammate | "Hey Sam," | "Can you," "Could you" | Excess formality, long preambles |
| Other team or your manager | "Hi Dana," | "Could you please," "I'd like to request" | Slang, emoji, one-word replies |
| External client or vendor | "Hello Ms. Alvarez," or "Dear Mr. Chen," | "I would appreciate," "Would you be able to" | Internal jargon, abbreviations |
| Someone you've never contacted | Full name, your role, how you got their name | Formal until they set a different tone | Launching into the ask with no context |
One calibration that trips people up in English is the difference between asking and requesting. "Could you send me the file when you get a chance?" leans on goodwill and implies it's optional. "Please send the file by Thursday" is a business request with an implied obligation. Use the second form when there's an actual deadline or a contractual requirement, and the first when you're genuinely asking a favor. Mixing them up in either direction causes friction: the soft form on a hard deadline means the deadline gets missed, and the hard form on a favor reads as entitled.
When you have to say no or point out a mistake, use short sentences. The longer you circle the point, the more the reader worries about what's coming. "The date you proposed won't work on our end. I can commit to next Tuesday instead." Two sentences, a conclusion and an alternative, and everyone moves on.
When annoyed, pause and reread before sending if the deadline allows. Check that the facts, request and tone still serve the purpose. Choose a call when discussion would be clearer, and record decisions appropriately.
Handling CC, BCC, and Reply All
The To line means "you need to act." The CC line means "you should know." When that distinction blurs, everyone on CC assumes someone else is handling it and nobody replies. Put the person who needs to do something in To, and everyone else in CC.
Copying someone's manager does two things at once. It shares status, which is fine, but it also reads to the recipient as "your boss is watching," which is pressure. Doing that on a first request makes you look aggressive for no reason. The usual convention is to send the first request directly, and widen the CC only on the second follow-up.
BCC is for large sends where recipients shouldn't see each other's addresses: customer notices, event invitations. Quietly BCCing a colleague into an internal conversation so they can watch is the kind of thing that, when it comes out, and it usually does, costs you trust that's hard to earn back. Forward the email afterward with "sharing for your awareness" and you get the same result honestly.
Reply All is for when everyone on the thread genuinely needs the reply. "Got it, thanks" sent to twenty people creates twenty pieces of clutter. Reply to the sender by default; Reply All is the exception you choose deliberately.
Reply etiquette: within a day, or at least say when
Norms vary by company, but a reasonable default is to answer work email within one business day. If you can't give a substantive answer in that window, send one line: "Received, I'll have an answer for you by Thursday." What frustrates senders isn't a delay or even a no; it's silence.
Send a follow-up about one business day after the deadline you set has passed. Reply to your original message so the other person has the context in front of them, and keep it short: "Bumping this, could you take a look?" Add "let me know if you need anything else from me" so there's a graceful exit if they were stuck. On the second follow-up, widen the CC or pick up the phone. A third emailed reminder almost never works.
When you reply to a numbered list, reply by number. Quoting the other person's questions and answering beneath each one works well too. "Sounds good" as an entire reply is ambiguous; "Sounds good: I'll have item 1 by tomorrow morning and item 2 by Thursday after I confirm with Priya" is not.
If you're catching up on email at 11 p.m. or on a Sunday, use scheduled send. Most clients have it. A message that arrives at 11 p.m. tells the recipient you work at 11 p.m., and that expectation spreads through a team faster than any policy. Schedule it for 8 or 9 the next morning.
A thirty-second check before sending
Before sending, check these five items.
- Does the subject line alone tell the reader what to do?
- Are the ask and the deadline in the first three lines?
- Is the attachment actually attached, and mentioned in the body?
- Are To and CC split correctly?
- Is the recipient's name right, especially anything autocomplete filled in?
The last one seems trivial and is where the real accidents happen. Autocomplete picks a different Sarah in a different department, or the recipient list from a previous message is still sitting there. A large share of "internal document sent to an outside party" incidents start exactly this way. Filling in the To field last, after the body is written and checked, also prevents the classic accidental send from a stray keystroke.
Common mistakes and their fixes
Ending with "let me know your thoughts." That's not a question. Say what you want thoughts on: "Does the ad-spend justification on page 3 hold up? I'd like your read on that specifically."
Writing history first and the ask last. Flip it. Ask, specifics, then history.
Three unrelated topics in one email. Split them, or if you must send one message, use numbered sections with mini-headers. The subject line becomes the search index later, and "misc updates" indexes nothing.
"ASAP" and "at your earliest convenience" as deadlines. Write a date and a time. "Soon" means something different to everyone, and it's almost always slower than the sender intended.
Exclamation points and emoji in a work thread. Fine with a close teammate, but every email can be forwarded, and the audience for an email isn't the recipient; it's everyone the recipient might ever forward it to.
Before your next message, write the request in one sentence and check its recipient and attachments. Review whether the reply actually resolves the requested action.