This lesson is not about the difficult email you have been avoiding for three days — that
one has its own practical case in Level 4. It is about the ordinary email:
the order to a supplier, the reply to an inspection, the note to the team, the message to the
professional body. The one written ten times a week, and precisely because it is routine,
the one where getting it right saves the most time — it is not a one-off case you solve once,
it is a task that repeats every working day of the year.
The whole thing in one sentence. The time saved does not come from the AI
inventing the message: it comes from you giving it four pieces of
information — who it is for, what you want to achieve, what tone, and what cannot be left
out — and letting it handle the mechanical part of turning them into well-built sentences,
which is the part that actually eats time when writing from scratch.
The four details that turn a vague request into a useful draft
| Detail | What happens if it is missing |
|---|
| Who it is addressed to. |
An email to a supplier and one to an inspector are not written in the same
register, and without saying so the model picks a generic one that does not quite
fit either. |
| What you want to achieve with the message. |
"Write an email about the order" does not say whether you want to complain about a
delay, ask for a discount, or simply confirm a date — and each of those is a
different email, not a variation in tone on the same one. |
| The tone. |
Formal, friendly, firm without being hostile — saying so avoids the surprise of
getting a draft that reads like a lawyer's letter for a simple reminder to a supplier
you have worked with for years. |
| What cannot be left out. |
The order number, the deadline, the contact person's name. Without saying so
explicitly, the model writes a well-worded email that is empty of the specific
details that make it actionable. |
The habit that saves the most time of all: dictate, do not type. For short,
frequent emails, speaking the four details above out loud — using your phone's or computer's
voice dictation — and letting the model turn that into a well-written email is usually faster
than typing it, even counting the time spent reviewing the draft afterwards. It is the same
logic you already saw in the images-and-voice lesson, applied here in your favour: voice
identifies less here, because there is no patient data involved at all, so that lesson's risk
barely applies to this specific use, leaving only the speed advantage without the privacy
problem the clinical voice note had.
A full example, and what is wrong with it
An order to a manufacturer is four days late on the agreed date, and it needs a message asking
what is going on without sounding aggressive, because this is a supplier you have worked well
with for years.
The request, spoken aloud in fifteen seconds: "Write me an email for Delta
Labs, order number 4471, that was due Monday and today is Friday. Friendly tone, we've worked
with them for years, I don't want it to sound like I'm complaining in writing. Make sure the
order number is clear and that I need to know if it's arriving this week, because I have
customers waiting for that product."
The first draft
"Good morning: I'm writing because order no. 4471 was due to arrive on Monday and we still
have not received it. We've worked together for several years and you've always been very
reliable, so I imagine something must have come up. Could you confirm whether it will
arrive this week? I have customers waiting for that product and it would help to know as
soon as possible. Thanks as always for your work, best regards."
And now, what is worth checking before sending it:
- The draft is good, and it still needs reading. Not because it is likely
to contain a serious error — the risk is low for this kind of email — but because "I
imagine something must have come up" is a sentence the model added on its own, not
something you said. It is harmless here, but it is exactly the kind of addition worth
checking every time, because in another context it could be a claim you did not want to
make.
- The requested tone — friendly, not sounding like a complaint — was
achieved. This is the part that genuinely took time to write well from scratch:
finding the balance between asking firmly and not sounding hostile with a trusted
supplier. That is where the real saving is, not in typing the words.
- The specific details you asked for are all there. The order number, the
date, the urgency of customers waiting. This is the fastest and most important check: a
well-written email missing the order number forces a second exchange just to clarify which
order is being discussed.
- Before sending, a ten-second read, not a deep review. For a low-risk
email like this one, the level of scrutiny does not need to match a clinical document.
Matching the level of checking to the real risk of the message is part of using the tool
well, not a shortcut: reviewing everything at the same intensity always ends up meaning
everything gets reviewed with too little intensity, which is worse than grading it on
purpose.
And if your pharmacy is not like that
If several of you write, each with a different style. Ask the model to keep
your own style by pasting two or three previous emails as reference, instead of letting it
default to a generic tone. The result sounds far more like something you would actually
write, and far less like a textbook corporate email.
If the email goes to an official body — professional college, inspection, social
security. Here the friendly tone does not apply and the risk of one extra sentence
does matter: explicitly ask for "formal, without adding any explanation I have not given you"
and review the whole draft, not just the details, because in this register any extra nuance
can read as an admission you did not intend to make.
If these are short WhatsApp messages, not emails. The same method works
just as well, but explicitly ask for the length: "three lines, no long courtesy phrases",
because the model defaults to writing with the length of an email even when the destination
is a chat.
If you have fixed templates for the most repeated notices — holiday closures, opening
hours changes. It is not worth generating those from scratch every time: save the
good text once and use AI only for the piece that changes — the specific dates — not to
rewrite what already works.
If the message includes any patient detail, even indirectly. Then this
lesson is no longer the one that applies: go back to the privacy lesson before writing
anything. An email to a patient's doctor about their treatment is not an everyday message,
it is exactly the case that lesson covers.
If the email is replying to a customer complaint, not one you are writing first.
Here it is worth pasting the customer's original message in full, rather than summarising it
yourself first, because the right tone for the reply depends on nuances of the original
message that are easily lost when summarising — whether they were angry, whether they were
only asking for information, whether they had already written before. And remember the
prompt-injection lesson: a message from an unknown customer is external content, so give it a
look before pasting it.
How much time this actually saves
There is no universal figure, but the pattern repeats: an email that takes five or ten
minutes by hand — thinking of the phrasing, deleting, rewriting the tone — drops to one or two
with this method, counting the time spent dictating the request and reviewing the result. The
saving is not in the part where you decide WHAT to say — you still do that, it is the four
details of the request — it is in the part where that idea gets turned into well-built
sentences, which is what genuinely eats the time when starting from zero each time. With one
email a day, five days a week, the difference between five minutes and one adds up to more
than three hours a month recovered — time that goes back to the counter, not time that just
disappears.
When it does not work first time
The draft always comes out too long, with courtesy phrases I never
use.
Explicitly ask for a number of sentences or a length target, and give
it a real example of yours as a style reference. A model tends to pad things out for safety
if you do not give it a clear limit, the same way it does with any other request that has
no format specified.
I get the feeling it sounds the same every day, you can tell it's
AI.
It is common if you always start from the same generic request. Give it
more specific context about the actual situation — not just the goal, also some concrete
detail of the day-to-day — and ask it to avoid the most typical stock phrases of the genre
("looking forward to hearing from you", "kind regards in advance"), which are what gives
the origin away the most.
I dictated the request and it misheard a proper name.
This is the usual weak point of voice dictation: proper names and
figures. Always check these before sending, even when the rest of the text is perfect — it
is exactly the ten-second check this lesson's example describes, and it is precisely where
dictation fails most often.
Is it worth it for a two-line email, or is it faster to just write it
myself?
For a truly trivial message, typing it yourself is often faster. The
tool pays off more the longer or the more delicate in tone the message is — a careful
complaint email, a reply to a tense supplier — and pays off little or nothing for a
one-line "received, thanks", where the request itself takes almost as long as writing the
whole message by hand.
The tone comes out right but it invents details I never gave it.
Add a fixed line to your request: "do not add any date, detail or
explanation I have not given you." It does not remove the risk entirely — the
hallucinations lesson already explained why — but it reduces it substantially, and it is
worth keeping as a standard opening line for this kind of request.
I write the request and the result does not sound anything like how I
talk.
That is the symptom of not having given it any reference to your own
style. Paste two or three of your own previous messages — with a tone similar to what you
need now — and explicitly ask it to write "in this same style", instead of trusting it to
infer that purely from a description of the tone. The difference between asking for
"formal" and giving a real example of your own formality usually shows in the very first
draft it returns.
I need the same email in another language besides English, do I ask
for that separately?
Ask for the translation as an explicit step from the already-reviewed
draft, not as part of the same initial request. Translating a different draft in each
language multiplies the risk of a different nuance slipping into each version, and
reviewing twice from scratch costs more than reviewing once and carefully translating that
single, already-checked version.
Before moving on
- I give the four details — who it is for, what I am trying to achieve, what tone, and
what cannot be left out — instead of just asking "write an email about X".
- I match the level of review to the real risk of the message, not the same for every
one.
- I always check proper names and figures when I dictated the request by voice.
- I save the templates that already work instead of regenerating them from scratch every
time.
- I know which kind of message is worth using this tool for and which is not worth it at
all.
← Revisit: anatomy of a good prompt
Next: summarising a research paper →
← Back to the AI School