“Please review the attached draft by Thursday at 3 p.m. UTC and reply with approval or the sections that need changes” gives a colleague a task they can finish. “Thoughts on this?” leaves them guessing which draft you mean, what kind of feedback you want, and when you need it. A good business email answers those questions without making the reader sift through unnecessary detail.
Decide what the recipient needs to do
Before you write, decide what the email is for: to inform someone, request a decision, ask a question, or assign a task. If you need a reply, define what it should contain. A yes or no? A date, a file, or comments on particular points? Use that answer to guide the subject line, opening, and final request.
An email can carry several updates and still have just one decision that matters. Put that decision near the top, then give the background. If unrelated requests belong to different people, separate emails may be easier to track than one thread with several owners.
Write a subject line that identifies the task
“Update” and “Quick question” reveal little in a crowded inbox. Name the project or document and, when useful, the action or deadline:
- Decision: “Approval needed: onboarding checklist by 14 May”
- Review: “Review request: API guide, sections 2–3”
- Status: “Status: staging release moved to Tuesday”
Keep the subject accurate as the conversation changes. If an invoice discussion turns into a request for system access, start a new thread. Save “urgent” for a genuinely time-sensitive need, and state the actual deadline in the message.
Put the point in the first few lines
A short greeting is fine. A long project history before the request is harder to justify, particularly on a phone, where the first lines may be all someone sees in a notification. Lead with the request or key fact; follow with the context needed to respond.
Instead of opening with a recap of meetings, try: “Could you confirm which of the two deployment windows your team can support? We need to schedule the approved maintenance work by Wednesday.” Then list the options and any constraints. The reader knows what to look for.
If the message is purely informational, say “For your reference; no action needed.” Adding “Let me know your thoughts” out of habit invites a reply you may not need.
Make the response easy to produce
“Can you look at this?” could mean proofread it, approve it, test it, or investigate a problem. Ask for a response you can recognize: “Please check whether the installation steps work on Ubuntu 24.04 and list any step that fails.” For a document review, identify the version and relevant sections, then say whether you need a technical check, wording changes, or final approval.
When the choice is limited, offer options. “Please reply with A (Tuesday at 10:00 UTC) or B (Wednesday at 15:00 UTC), or suggest another time” takes less work to answer than “When are you free?” Leave room for an alternative when the recipient may have information you lack.
Number multiple requests so each can be answered in place:
- Confirm the owner of the staging environment.
- Approve or reject the proposed test window.
- Flag any users who need advance notice.
That also makes follow-up precise: “We have answers to items 1 and 3; item 2 is still open.” If the list has grown into a project plan, put the work in your team’s agreed tracking system and use email for the specific decision at hand.
Make deadlines and ownership explicit
“Soon,” “end of day,” and “next Friday” can mean different things in different locations. For a time-sensitive request, give the calendar date, time, and time zone. Explain a real dependency if it helps: “Please respond by 16:00 UTC on 12 June so we can finalize the schedule.” Don’t invent urgency to speed up a reply.
If several colleagues are copied, name the person who needs to act: “Maya, could you approve the draft? Ravi and Lee are copied for visibility.” Use To for people expected to participate and Cc for those who need to stay informed, unless your team has different conventions. No one should have to guess whether their silence counts as approval.
Use formatting that survives a busy inbox
Short paragraphs make it easier to find information and reply from a phone. Give each paragraph a purpose, such as the request, context, constraints, or next step. Lists help with questions, options, and deliverables, but turning every sentence into a bullet makes the email harder to read. Spell out internal shorthand when the recipient may be new to the project.
In a longer email, headings such as “Decision needed” and “Background” can help readers find their place. Don’t rely on bold text, color, or highlighting alone to carry an instruction. Formatting may display differently across email clients or be difficult to interpret with assistive technology; state the instruction in plain text too.
A technical email needs enough detail to identify an issue, not an entire log pasted into the body. Include the affected service, observed behavior, start time and time zone, environment, and a reference to an approved ticket or log location when relevant. Keep observations separate from suspected causes: “The staging job failed twice with an authentication error” does not claim to know why.
Handle attachments and sensitive details carefully
Don’t make the reader hunt for the file you want reviewed. Name it in the email, describe what it contains, and identify the version: “Attached: onboarding-checklist-v3.pdf; please review pages 2–4.” Check that it is attached before sending. For a shared document, give its agreed name and location rather than assuming everyone has access.
Keep sensitive information out of the email and its attachments unless it is needed for the task. Don’t paste passwords, secret keys, customer records, or full diagnostic logs for convenience. Use your organization’s approved secure channel or access-controlled location, and share only what is necessary. Before sending, check recipient addresses, distribution lists, and attachment permissions, especially if the thread includes external participants.
Security-related requests also need a clear authorized scope. “Please verify the firewall change on our staging network during the approved window” identifies the task and its limits. “Check all the systems” leaves too much open to interpretation about which assets and activities are permitted.
Reply in a way that closes the loop
A clear reply matters as much as a clear request. Answer each numbered item in a multi-part email, or quote only the small portion needed to identify your answer. If you cannot decide yet, explain what is blocking you and when you expect to update the sender. “I can confirm the test window after the maintenance schedule is published on Tuesday” tells them more than “Will check.”
Make any change of plan unmistakable. “Approved, except move the start to 15:00 UTC” can get lost in a long thread. Try: “Approved for Wednesday at 15:00 UTC. The earlier 14:00 slot is not approved.” For consequential decisions, confirm the final date, owner, and scope together rather than asking people to piece them together from earlier replies.
Before you send, read the email as its recipient: Why did I receive this? What do I need to do? Do I have the details to answer? If the reply needs a particular format, put it in the final line: “Please reply by 12 June with ‘approved’ or a numbered list of changes to the attached version 3.”
