How to Write Better Emails With ChatGPT

Start with a short brief

Open a new ChatGPT conversation and write down the information that would change the email: who will read it, what they already know, what happened, what you need from them, and when. Add a boundary if a wrong sentence could make a promise or imply a decision that has not been approved. You can do this in plain sentences. OpenAI's prompting guidance recommends giving ChatGPT the goal, useful context, desired output, and boundaries that matter, without treating a long template as mandatory.

A scheduling note may need only two sentences of context. A customer delay needs the exact old and new times and a clear account of what is approved. If the new deadline is still a proposal, ask for an internal decision before drafting a customer-facing commitment.

Draft one email for [recipient and relationship]. They already know [relevant context].
I am writing because [purpose]. Confirmed facts: [names, dates, figures, decisions].
I need the reader to [one next action] by [deadline, if confirmed].
Keep the tone [specific description of how I normally write to this person].
Do not add [unknown cause, unapproved promise, or other boundary].

Return one specific subject line, a draft of about [length] words, and a short list of facts or decisions I still need to supply. If a missing fact would change the message, ask instead of guessing. Prepare a draft only; do not send it.

Replace every bracket before pasting the prompt. Read the missing-facts list before revising the email. If ChatGPT asks whether a deadline is approved, settle that question with the person who owns it. The four fictional cases below show how the same method changes with the reader and the stakes. The first three email texts are editorial examples of final drafts, not captured ChatGPT outputs. The Atlas case uses a recorded but partial ChatGPT run.

Example 1: request an update from colleagues

The fictional Project Delta launch checklist is due Thursday, October 1, 2026 at 16:00 UTC. Maya owns the accessibility review and Jin owns the link check. You need to know by Wednesday, September 30 at 12:00 UTC whether either task is blocked. The email should make the two owners and the reply deadline easy to scan without implying that either review is already done.

Draft a short email to Maya and Jin, colleagues who know Project Delta. The launch checklist is due Thursday, October 1, 2026 at 16:00 UTC. Maya owns the accessibility review; Jin owns the link check. Ask each person to flag any blocker by Wednesday, September 30 at 12:00 UTC, including the help they need. Do not say either review is complete. Return a subject and one email under 100 words.

Check the owners and both times against the project plan. A polished line thanking them for completing their reviews would be wrong: the brief only assigns the work. This is a routine email, so a short prompt and a factual check usually suffice.

Example 2: follow up without assigning blame

Suppose you asked Alex for Project Oak's delivery window on September 22 and have not received an answer by September 25. You need the earliest available delivery week by Tuesday, September 29 for a planning decision. You do not know why Alex has not replied. That last point keeps the draft from claiming Alex is busy, has missed the note, or is holding up the project.

Draft a polite follow-up to Alex. I asked on September 22 for the earliest delivery week for the fictional Project Oak. I have no reply as of September 25. Ask for the earliest available delivery week by Tuesday, September 29 so I can finish a plan. Do not assume why Alex has not replied, invent a delivery date, or claim the request is urgent. Return a subject and an email under 90 words.

The first sentence helps Alex find the earlier request. The next sentence names the answer you need. If the earlier email asked several questions, identify the one that blocks your next decision. Confirm that September 29 is a deadline you can reasonably set before using it.

Example 3: tell a client about an approved delay

A fictional client's report was due Wednesday, September 30, 2026 at 3 p.m. ET. The project owner has approved a new delivery time of Thursday, October 1 at 3 p.m. ET. No cause or compensation decision is confirmed. The client needs the change immediately, a brief apology, and a chance to say whether the new time affects their review.

Draft an email to a long-term client who knows the report. Today is Tuesday, September 29, 2026. The agreed delivery was Wednesday, September 30 by 3 p.m. ET. The project owner has approved Thursday, October 1 by 3 p.m. ET as the new delivery time. Apologize briefly, state the approved time, and ask whether it works for their review. The cause is unconfirmed and no compensation decision has been made. Do not blame a person or offer a credit. Return a subject and a draft under 110 words.

The client gets the changed commitment in the first sentence; the colleagues in Example 1 got task assignments. This draft does not fill the missing cause with a plausible excuse. Before sending it, confirm that the project owner still approves the new time. If approval is pending, send an internal request for a decision and hold the client draft.

Example 4: keep an incident update inside known facts

The site's August 18 ChatGPT run used a fictional Atlas reporting incident. Its audience was customer success managers, so the support route below is an internal channel, not a customer-facing instruction. The incident began at 09:20 UTC and affected export generation. Dashboard viewing was unaffected; the previous scheduled export was available as a workaround. Engineering was investigating, the next update was due by 13:00 UTC, and urgent cases belonged in #atlas-support with an account ID. The brief contained no root cause, restoration time, customer count, or compensation decision.

Draft an internal email to Atlas customer success managers using only these fictional facts. The reporting incident began August 18 at 09:20 UTC. Export generation is affected; dashboard viewing is unaffected. The current workaround is to download the previous scheduled export. Engineering is investigating. The next update will be provided by 13:00 UTC. For urgent cases, ask managers to post in #atlas-support with the account ID. Do not add a root cause, restoration estimate, compensation promise, customer count, or other impact claim. Return a subject, an email under 160 words, and a list of any missing facts.

The August 18 run record reports that one ChatGPT draft preserved the known facts and omitted the prohibited claims. The screenshot is partial, so the edited example above is not presented as a transcript of that output. Compare each time, affected function, unaffected function, workaround, investigation state, update commitment, and support route with the source brief. One successful synthetic run does not establish how a future incident draft will behave. At send time, the incident owner must still confirm that the workaround, audience, and 13:00 UTC update are current.

Revise for the person who will read it

Read the first two sentences without looking at your prompt. A colleague who knows the project usually needs the action and deadline. A customer affected by a delay needs the changed commitment and what it means for them. If the draft opens with several lines of background, move the useful fact or request to the top. Ask ChatGPT to change one aspect at a time, then compare the revision with the brief again.

Shorten this email and put the requested action in the first two sentences. Preserve the recipient, names, dates, time zones, figures, approved commitments, and unanswered questions. Do not make the tone warmer or more certain. Show the revised email, then list anything you changed that could affect its meaning.

That change list is a review aid, not proof that every sentence is safe. Check the actual draft. If ChatGPT repeatedly changes a protected fact or turns an unknown into a promise, stop revising that version. Use the brief as an outline and write the consequential sentence yourself.

Handle missing and sensitive information

If you cannot supply a date, approval, price, cause, or policy answer, keep that gap visible. A client-delay draft should state an approved delivery time only when the project owner has approved it. Otherwise ask for the decision internally first. If the recipient needs to know an investigation is open, say so without filling the gap with a likely-sounding explanation.

Use placeholders such as [Client] and [Amount] when you can draft without real identifiers. Check the rest of the description too: a rare project name or detailed incident timeline may identify the situation even when a name is removed. Follow your organization's rules for what may be entered into ChatGPT and who must review employment, legal, health, financial, security, or other restricted messages. A privacy setting does not replace that permission.

Check the composed email before sending

Copy the edited draft into your email app and inspect it there. The subject, recipient fields, reply-all choice, links, formatting, and attachments can change after the ChatGPT stage.

• Address the right people. Check To, Cc, Bcc, and reply-all behavior.
• Compare names, dates, time zones, figures, links, and attachment names with the approved source.
• Make the one reply or decision you need easy to find.
• Remove placeholders, prompt notes, and any sentence you would not say yourself.
• Confirm that no new promise, cause, price, policy statement, or deadline slipped into the final version.
• For an incident, complaint, payment, policy, or other consequential email, obtain the review your organization requires.

The downloadable pre-send record gives consequential messages a place to record known facts, unknowns, the requested action, and the final checks. A routine note may need only the checks above. Keep the level of review proportionate to what the email can commit you or someone else to.