A busy reader decides what to do with an email in the first few lines. If those lines are background — how the project started, who said what last week — the actual request lands somewhere in paragraph three, and the email gets parked for later. Later often means never.
An action-first email reverses the order. The reader learns what is needed from them before they learn why. Everything after that exists only to help them do it.
The four lines that matter
- The action: one verb, one object. “Please approve the revised timeline.”
- The owner: who should do it, by name, if more than one person is on the email.
- The deadline and the reason for it: “by Thursday 4 PM, so we can update the client on Friday.”
- What happens if it is not done, stated neutrally — only when it genuinely matters.
Hi team, following up on our discussion from last week regarding the delivery schedule and the concerns raised by the client, please check the attached and update ASAP.
Ravi — please approve the revised delivery date (12 November) by Thursday 4 PM, so we can confirm it to the client on Friday. The change and the reason are on page 1 of the attached plan.
Then add context — but only the useful kind
Context earns its place when it changes what the reader does or how confidently they can do it. Useful context: what changed, what you already checked, and what is still unconfirmed. Not useful: the full history of the thread, or a paragraph apologising for the follow-up.
- Separate confirmed facts from assumptions, and label the assumptions.
- Link or attach the one document needed to act, and say where in it to look.
- If you need two different things from two people, consider two emails.
A quick self-check before you send
Cover everything except the first two lines with your hand. Could the reader still act correctly? If not, the request is not where it should be. Then read only the subject line: does it tell the reader what kind of email this is — a decision, an FYI, a deadline?
Action-first does not mean blunt. A courteous opening line is fine; it just should not push the request out of view.
Examples in this guide are fictional and written for teaching — not client material or measured results.

