Professional Email

Learning outcomes

You can write grammatically perfect English and still send an email that gets ignored, misread, or answered three days late. The reason is rarely the grammar. It is that the email was built for the writer, who has all the context and all the time, instead of for the reader, who has neither. This page treats the email as a tool with a job: get a busy person to understand what you need and act on it. Everything here, from the subject line to the sign-off, serves that job.

After studying this page, you can:

• Write a subject line that makes the email findable later and tells the reader what is wanted.
• Put the main point or request in the first line or two, instead of building up to it.
• Keep one email to one purpose, and split when a message tries to do too much.
• Shape a message so a skimming reader still catches the ask: short paragraphs, bullets, and a bolded request.
• Choose a greeting and sign-off that fit the relationship and formality, and calibrate warmth so a request does not read as curt.
• Handle the common email jobs (a request, an update, an introduction, a graceful decline, a follow-up, a thank-you) with a structure that fits each.
• Apply reply-all and CC discipline, and judge when an email beats a chat message or a meeting.

Before we dive in

Here is an email that a careful writer might be proud of. A teammate has sent it to a colleague in another team.

Nothing in it is wrong. The grammar is clean, the tone is friendly, the writer is being polite. And yet it is a hard email to act on. The subject line, “Quick question,” tells Morgan nothing and will be impossible to find in a month. The actual request, the API schema, is buried in the second-to-last sentence, after a paragraph of warm-up that a busy reader will skim or skip. There is no deadline the reader can plan around, just “ideally before we lock the plan,” which assumes Morgan knows when that is. If Morgan reads this on a phone between meetings, the most likely outcome is “I’ll deal with that later,” and later does not come.

The problem this page solves is not how to be correct. It is that a good email and a correct email are different things. A correct email follows the rules of English. A good email is engineered for a specific reader who is busy, skimming, and juggling forty other messages, so that the reader can grasp what is needed and act on it in the few seconds of attention they will give it. Once you see the email as a tool with that job, every choice in it, the subject, the first line, the layout, the closing, stops being decoration and becomes a way to lower the cost of acting on your message.

The job of the email and the reader who skims

Start with the reader, because the reader is the whole design problem. The person opening your email is not reading it the way you read a novel, line by line, in order, giving each sentence its due. They are triaging an inbox. They glance at the sender and the subject, decide in about a second whether to open it now or defer it, and if they open it, they skim, their eye jumping to the first line, to anything bold, to bullet points, looking for the answer to one question: what does this person need from me, and how much work is it.

This changes what “well written” means. In an essay, you can build an argument, hold back the conclusion, and reward the patient reader at the end. An email reader is not patient and is not reading to the end. So the structure that works for an essay, context first, conclusion last, is exactly backwards for an email. Whatever the reader most needs, the request, the decision, the headline, has to come first, while you still have their attention, because you may not have it by paragraph three.

The subject line: findable and action-aware

The subject line does two jobs, and “Quick question” does neither. Its first job is to survive in a crowded inbox and stay findable later. Months from now, someone searching for the migration schema should be able to find this thread by typing a word they would actually think of. “Quick question” is invisible to that search; “Q3 migration: need updated API schema” is not. Its second job is to set the reader’s expectation before they open the email, so they know whether this needs action, by roughly when, and how big it is.

A strong subject line is specific and, when something is needed, action-aware. Compare a few:

Read down the “stronger” column and notice a pattern: each one front-loads the topic and, where relevant, the action and the timing. A reader who sees only the subject already knows roughly what to do. A few small habits help here. Lead with the topic so the most searchable word comes first. If action is needed, say so (“Decision needed,” “Action: ,” “Sign-off by Friday”). Keep it short enough to read in a glance, since long subjects get cut off on a phone. And when a thread has drifted onto a new topic, start a new email with a new subject rather than replying to a stale chain titled “Re: Re: lunch.”

The ask up front (bottom line up front)

This is the single highest-leverage move in email, and it has a name borrowed from military and journalistic writing: bottom line up front, often shortened to BLUF. State the request or the main point in the first line or two, before any context, because the reader is skimming and the first line is the line they are most likely to actually read. Context, reasons, and background come after the ask, where they support it for the reader who wants them, instead of in front of it, where they delay it for the reader who does not.

The instinct that fights this is strong and worth naming. In conversation, and in much polite writing, we build up: we set the scene, give the reasons, and arrive at the request at the end, so it feels earned rather than abrupt. That works when the listener is captive. In email the listener is not captive, and building up means the request arrives after the reader has stopped paying attention. Putting the ask first feels almost rude to a careful writer, as if you skipped the manners. You did not. You can still be warm; you just lead with the point and add the warmth around it.

Putting the ask up front also forces a useful clarity on you, the writer. If you cannot state the request in one sentence at the top, you may not yet be sure what you are actually asking for, and a reader will not be sure either. The discipline of the first line is partly a discipline of thinking. For the wider habit of stating the point before the support, see persuasive writing and the plain-first style in principles of clear prose.

One email, one purpose

The migration email earlier failed partly because it tried to carry too much: a greeting, congratulations on a launch, a sprawl of migration context, and, somewhere in there, a request. When one email carries several unrelated jobs, the reader can act on one and lose the rest, and the thread becomes impossible to track because replies to “the email about three things” can only address one thing at a time.

The rule is one email, one purpose. Decide the single thing this message exists to do, get the reader to send a file, to approve a plan, to know a status, and build the whole email around that. If you genuinely have three unrelated asks for the same person, three short emails with three clear subject lines will almost always get a faster, more complete response than one long email with three buried asks, because each one is its own trackable, answerable unit. The exception is a deliberate digest, a weekly update where the purpose itself is “here are the several things,” and even then the structure has to make each item separately scannable.

Scannability: shape the message for the eye

A skimming reader does not read a wall of text; they bounce off it. So the second half of designing for the skim, after putting the ask first, is shaping the message so the eye can travel it fast and still land on what matters. Three tools do most of the work, and they are about layout, not language.

Short paragraphs come first. A paragraph that runs eight lines deep reads as a chore before a single word is processed; the same content split into two or three short paragraphs reads as approachable. Aim for paragraphs of a few sentences, one idea each, with white space between them that gives the eye a place to rest.

Bullet points come next, for anything that is really a list: several questions, a set of options, the steps of a process, the items you need. Prose hides a list inside sentences, where the reader has to dig each item out; bullets lay them side by side where the reader can see all of them at once and answer each. If your email asks for three things, three bullets will get you three answers far more reliably than one paragraph mentioning all three.

And bolding comes last, used with restraint. Bold the actual ask, and perhaps the deadline, so that a reader who skims and reads nothing else still catches the one thing you need. Bold loses its power when everything is bold, so reserve it for the request and the date, not for emphasis scattered through the message. The diagram below shows how these pieces assemble into an email built for a skim.

Notice the order in the diagram: the point lives at the top, in the subject and the first line, and everything below it is support that the reader can take or skip. The next-step box matters as much as the ask. An email that explains a situation but never says who should do what, by when, leaves the reader to guess, and a guessing reader usually does nothing. End on the action, not on a vague “let me know your thoughts.”

Greetings and sign-offs

The opener and the closer carry almost no information and almost all of the relationship. They are where you set how close and how formal the email is, so they should be tuned to who the reader is, not chosen by habit. This is the warmth and formality of register and tone applied to the two slots of an email where the reader feels them most.

On greetings, the practical range runs from casual to formal. “Hi Sam,” is the workhorse for most workplace email: warm, professional, and right for a peer, a manager, or a familiar contact. “Hey Sam,” is fine for a close teammate and too loose for a client or a first contact. “Dear Mr. Lee,” moves up the formality scale for an external, senior, or first-time recipient, or a context where care and convention matter. “Hi team,” or “Hi all,” opens a group message. The safe default for someone you do not know well is “Hi NAME,” which is warm without being presumptuous; reserve “Dear” for genuinely formal occasions, since it can read as stiff between colleagues.

Sign-offs work the same way, as a dial from warm-casual to formal. “Thanks,” is the everyday close when there is any ask at all, since it thanks the reader in advance for acting. “Best,” and “Best regards,” are neutral, safe closers for almost any professional email. “Cheers,” is warm and informal, common in British and Australian English and among teammates, and slightly out of place in a formal note to a client. “Kind regards,” and “Regards,” sit on the formal end for external or first contacts. The closer should match the greeting in temperature: a warm “Hi Sam,” paired with a stiff “Yours faithfully,” reads as oddly mixed.

Tone, warmth, and softening the ask

An email can be perfectly structured and still land badly because it sounds curt or cold. This is the written-tone problem in full: the reader cannot hear your voice, so warmth and politeness have to be built from words, and an efficient message that skips them reads as colder than you meant. The whole mechanism, why text loses tone and how to add it back, lives in tone in writing; here we apply it to the move email needs most often, softening a request.

A bare imperative, “Send me the schema by Thursday,” is efficient and reads as an order. The fix is not to bury the ask again; it is to keep the ask clear and add a softener and a reason around it. “Could you send the schema by Thursday? We are mapping our fields next week and would love to start from your version.” The request is just as clear, the deadline is just as firm, but the modal “could you,” the reason, and a touch of warmth turn an order into a request between colleagues. Softening is not weakening: the deadline stays, the point stays, only the temperature changes.

There is a real balance to hold. Too curt, all imperatives and no warmth, and you read as cold or annoyed even when you are neither. Too formal or too padded, “I would be most grateful if you could possibly see your way to perhaps sending,” and you waste the reader’s time and sound stiff or sarcastic between peers. The target is warm and clear: lead with the ask, soften the verb, give the reason, keep the deadline, and add a small human signal like a “thanks” or a “no rush if this week is tight.” The mechanics of how much to soften, and when softening tips into vagueness, are in tone in writing.

The common email jobs, done well

Most workplace email is one of a handful of recurring jobs, and each has a structure that fits it. Learn the shape of each and you stop composing from scratch every time. The table gives the recommended structure and an example opening line for the most common five.

Three of these deserve a closer look, because they are the ones learners most often get wrong. The first is making a request well, which is the table’s whole top row in practice: a clear ask, a real reason, and a specific deadline beat a vague “whenever you can,” because a deadline with a reason helps the reader prioritize rather than pressures them, and “whenever you can” usually means never. Give the date and say why the date exists.

The second is declining or pushing back gracefully, which feels hard and is mostly structure. Thank the person for the ask or the idea, decline clearly so there is no false hope, give a short honest reason without over-explaining, and where you can, offer an alternative, another person, another time, a smaller version. “I can’t take the full project, but I could review the design if that helps” declines and stays useful in one breath. The mistake is the vague non-decline, “let me see if I can find time,” which leaves everyone waiting and is unkinder than a clear no. The deeper softening moves behind a graceful no live in tone in writing.

The third is the polite follow-up, the nudge. When a request has gone unanswered, the goal is to make acting easy again, not to make the reader feel bad. Keep it short, reference the original so they do not have to dig, restate the ask in one line, and stay warm. “Just floating this back up, no worries if it has been a busy week, still hoping for the figures before Friday.” Avoid the passive-aggressive markers, a sharp “per my last email,” a pointed “as I mentioned,” that turn a nudge into a jab; the channel strips your tone, so those words land harder in text than you intend. And thanking, the simplest job, is worth doing specifically: “thanks for turning the schema around so fast, it unblocked our whole week” lands far better than a generic “thanks.”

Etiquette: reply-all, CC, and choosing the channel

Two small disciplines prevent most email friction, and both are about respecting other people’s inboxes. The first is reply-all and CC discipline. CC, the carbon-copy line, means “for your awareness, no action needed”; put people there who should see the thread but do not need to act, and keep the people who must act on the To line. Reply-all sends your message to everyone on the thread, which is right when the whole group needs your answer and wrong, and mildly infuriating, when only the sender does. A “thanks, got it” sent reply-all to twenty people is the classic reply-all storm: each person now has a message they did not need, and if a few people reply-all in turn, the inbox fills with noise. The rule is simple. Reply-all only when everyone genuinely needs your reply; otherwise reply to the sender alone. And use BCC, the blind copy, to protect a large list’s addresses or to drop a group from a thread cleanly.

The second discipline is choosing the channel at all, because not everything should be an email. Email suits a message that needs a record, that reaches people across teams or time zones, that carries a request someone will act on later, or that is too long or too formal for a quick chat. A fast back-and-forth, a quick yes or no, or a casual heads-up belongs in chat, where the looser, shorter style is the norm; the moves for that channel are in Slack and chat. And some things should be neither: a tense disagreement, a sensitive piece of feedback, or a decision that needs real-time give-and-take is often faster and kinder as a five-minute call or meeting than as a chain of carefully worded emails that each take an hour to write and still leave room to misread.

Mental Model: a memo for a busy reader, not a letter

The wrong model, the one that produces the buried-ask email, is that an email is a kind of letter. A letter opens with pleasantries, sets the scene, builds toward its point, and closes warmly, and it can do all that because the recipient sat down to read it from top to bottom. If you carry the letter model into email, you write the warm-up, the context, and the slow build, and you put the request at the end where a letter-reader would expect it. The trouble is that no one reads email like a letter.

The better model is that an email is a memo addressed to a busy person who will skim it. A memo leads with its conclusion, states the action up front, supports it with just enough detail, and respects the reader’s time above all. Hold this model and every choice on this page falls out of it: the subject line is specific because the reader files it by subject, the ask comes first because the reader reads the first line and maybe no more, the layout is scannable because the reader skims, and the tone is warm because warmth has to be added by hand when there is no voice. You are not writing to express yourself or to be admired for your prose. You are lowering the cost, for one specific busy person, of understanding what you need and doing it. When the email is hard to act on, it is not the reader who failed.

Common mistakes

The first mistake is the vague subject line. “Quick question,” “Update,” “Hi,” and “Re: Re: stuff” tell the reader nothing and vanish in a search. Name the topic and, if action is needed, signal it: “Q3 migration: need API schema by Thursday.”

The second is burying the ask at the bottom. Writers build up to the request the way they would in conversation, and the request arrives after the reader has stopped reading. Put the ask in the first line or two, then give the reason.

The third is the wall of text. A dense block of prose reads as a chore and hides the point. Break it into short paragraphs, pull lists into bullets, and bold the actual ask so a skimming reader catches it.

The fourth is the wrong tone, in either direction. Too curt, all imperatives and no warmth, reads as cold or annoyed; too formal or too padded between peers reads as stiff or sarcastic. Lead with a clear ask, soften the verb, give the reason, and add a small human touch.

The fifth is the reply-all storm and loose CC habits. Reply-all only when the whole group needs your reply, keep action-needed people on the To line and awareness-only people on CC, and do not add people who do not need the thread.

The sixth is leaving no clear next step. An email that describes a situation but never says who does what, by when, leaves the reader guessing, and a guessing reader does nothing. End on the action.

Mastery Questions