The reply was accurate. It covered every point the customer raised, it was polite, and it took twenty minutes to write. Two days later the same customer writes back asking the question that was answered in the fourth paragraph. Nothing was wrong with the content. The format put the answer somewhere nobody was going to read.
Most advice about customer care email concerns tone. Format is the part that decides whether the tone is ever reached. A reply is read on a phone, between other things, starting from a preview line of a dozen words, and it is skimmed before it is read. A format that assumes an attentive reader at a desk is a format that loses information on the way out.
The conditions a reply has to survive
Four things are true of almost every customer care message, and each one constrains the format.
It is read on a phone. Narrow column, small screen, one hand. Long paragraphs turn into walls and get scrolled past rather than read.
It is judged from the preview line. Sender, subject and roughly the first ten words decide whether the message is opened now, later or never. Whatever sits in those ten words is the only part guaranteed to be seen.
It is skimmed first. Readers hunt for the answer before reading the reasoning, and they hunt by looking at the shape of the message. Structure that is visible without reading, such as short paragraphs and a genuine list, is what makes the hunt succeed.
It is read again later, out of context. A month on, either side may search for this message to settle what was agreed. That is an argument for naming the specific item in the subject and in the body rather than relying on the thread to carry the context.
Every rule below follows from one of those four.
The order of the blocks
A customer care reply has five blocks, and the order matters more than the wording of any of them.
The outcome or the state. What was decided, or where the matter stands. This goes first, in the first sentence, before any greeting pleasantry that might push it out of the preview.
The specific thing it concerns. The order number, the role applied for, the date of the submission, the fault reported. Named explicitly rather than referred to as "your request", because somebody with three open matters cannot otherwise tell which this is.
The reason or the detail. One short paragraph. This is where the explanation belongs, after the reader already knows the answer, when they are reading to understand rather than reading to find out.
What the reader does next. One action, stated as an action. If there is nothing for them to do, say that instead, because an absence of instruction is read as an unstated obligation.
How to reach a person. An address a human being reads, and by when a further reply would arrive.
The order inverts the one people write in naturally. Left alone, most writers reconstruct their own path: what was checked, what was found, what follows. That order is right for an internal note and wrong for a customer, because it asks them to hold the reasoning in mind before they know what it is for.
The subject line
The subject does two jobs. It gets the message opened now, and it gets the message found in a month.
A state followed by the specific thing satisfies both. "Refund approved: order 4821" or "Decision: assistant curator application" tells somebody what happened without opening anything, and it contains the string they will search for later. "Re: your enquiry" does neither.
Replying inside the existing thread keeps history together and is right for a live conversation. Starting a new subject is better when the message marks a change of state, because a customer watching for news about one specific matter will want it findable rather than buried in a chain of twelve messages.
One word class to keep out of the subject of any message that is not final: anything implying completion. "Closed", "resolved" or "complete" in the subject of a message that promises a further reply will be read as the decision, and the actual decision then looks like a reversal.
The first two lines carry the message
If only two lines were read, which is the realistic case, they have to contain the answer.
That rules out opening with thanks for getting in touch. It is not rude to leave it out, and it can go at the end where it costs nothing. It also rules out any sentence that describes the message itself, of the "this is to inform you that" variety, which spends the preview line announcing that a message exists.
The greeting is fine. A name and a line break take almost nothing, and the first sentence after it should be the outcome. On a narrow screen this puts the answer above the fold, which is the only structural decision in the whole format that reliably changes behaviour.
A useful check: read the first twelve words alone and ask whether somebody could act on them. If not, the reply is front loaded with ceremony.
Formatting the middle
One idea per paragraph, two to four sentences. Paragraph breaks are the only formatting most readers register. A single dense block reads as work; the same text in four short paragraphs reads as considered.
Lists only for genuinely parallel items. Three documents required, four steps in order, two dates offered. Numbered when the order matters, bulleted when it does not. A list of unrelated sentences is harder to read than prose, because it implies a parallel structure that is not there.
Bold for one thing, once. The date, or the single action needed. Bold on every claim means bold on nothing, and readers who skim will follow the bold text as though it were the message.
No emphasis that depends on colour alone. Colour is not available to every reader, and dark mode in some clients inverts it unpredictably. Anything that must be noticed needs to work in plain text.
Descriptive link text. A link reading "the returns form" survives being read aloud and being skimmed. A bare address in the middle of a sentence breaks the line badly on a narrow screen, and link text reading here is unusable to anybody navigating by links.
Tables sparingly. A table with more than two columns rarely survives a phone screen. Two short paragraphs usually carry the same information.
When the customer asked several questions
| Format | Best when | On a phone | Risk |
|---|---|---|---|
| One prose block | Two closely related questions with one answer | Reads fine if short | An individual question gets missed |
| Numbered answers mirroring their order | Three or more distinct questions | Scannable, each answer findable | Reads clerically if the answers are long |
| A short heading per question | Questions needing a paragraph each | Best for finding one answer later | Turns a reply into a document if overused |
Mirroring the customer's own order, whichever format is used, removes an argument about whether something was answered. Reordering the questions to suit the reply is how one of them gets quietly dropped.
The close
One action, one address, one name. If the matter is finished, saying so explicitly is part of the format, because a reader left uncertain will either wait indefinitely or write again to check.
The sender address deserves more thought than the signature. A reply from an address that does not accept replies tells the reader that the conversation is closed before they have decided whether they want to ask anything, and anybody who does reply gets a bounce. The small number of people who reply to a customer care message are usually the ones worth answering.
A name in the signature reads better than a department, and it gives a returning customer somebody to address. If replies need to reach a shared queue rather than one person's mailbox, the way to get both is a shared address with an individual's name above it.
Attachments are a format decision too. A document attached to a reply is fine when the reader needs to keep it. A document attached when a short paragraph would do adds weight, may be blocked, and cannot be read in the preview. Anything that must be read now belongs in the body.
Plain text, HTML, and what actually breaks
Most customer care mail is sent as HTML by default, and three things about that are worth knowing before a format becomes the house style.
Mail clients disagree about whether a raw line break inside HTML counts as a line break. A message composed with plain newlines can arrive as one continuous paragraph in some clients, which destroys every paragraph break in it. Explicit break markup, rather than relying on the whitespace in the source, is what keeps the structure intact everywhere.
Images are often not loaded. Any information carried only in an image, including a logo carrying the organisation's name and any diagram explaining a step, is absent for those readers. Alternative text covers part of it; keeping the essential sentence in real text covers the rest.
Dark mode rewrites colours in ways the sender cannot predict. Dark grey text on a white block can end up unreadable. A format that works in black on white and does not rely on a background colour survives this.
None of this argues for plain text only. It argues for HTML that is close to plain text in structure: real paragraphs, real lists, no layout doing work that words should do.
Testing the format before it becomes standard
Four checks, done once, on the reply that gets sent most often.
Send it to a mailbox that can be opened on a phone and read it there without scrolling. Whatever is visible on that first screen is the message as most people receive it.
Read the subject and the first ten words alone, without opening. If the state of the matter is not clear from those, the front of the message is spent on ceremony.
Load it with images blocked. Anything that disappears was never information.
Read only the bold text and the list items. Skimmers read exactly that, and the impression it leaves should match the impression the whole message leaves.
Where the format actually gets enforced
A format written down in a document is a suggestion. What holds is the wording people work from when they are busy, which means the format survives only if it is built into the saved replies rather than described somewhere separately.
That points at where the wording lives. Saved wording stored in one person's mail client drifts, because every edit has to be repeated by everybody and nobody can tell which version was used. Saved wording stored next to the queue, on the same screen as the request being answered, stays current and puts the specific details within reach so they do not have to be copied across by hand. The features that matter for that are a status on each item, a named owner, saved wording and a record of every send. Anybody who wants to see whether the format holds up in practice can open a live form and its replies and read one on a phone.
What to change first
Take the reply the team sends most often and move the outcome into the first sentence, above the greeting pleasantries. That single change does more than any other, because it puts the answer where the preview line and the skim both land. Then store the revised version where the queue is rather than in a document, so the format travels with the work: Halict keeps the saved reply beside the submission it answers instead of depending on memory.
Q1. Should a customer care email start with the answer or with an apology?
With the answer or the current state. An apology or a thank you at the top pushes the useful sentence out of the preview line, which is the only part of the message guaranteed to be read. Both belong at the end, where they cost nothing.
Q2. How long should a customer care email be?
Short enough that the first screen on a phone contains the outcome and what happens next. Length beyond that is fine when the reader needs detail, as long as the detail comes after the answer rather than before it.
Q3. Is it better to reply in the existing thread or start a new subject?
Reply in the thread for a live back and forth, because the history stays together. Start a new subject when the message marks a change of state, such as a decision or an approval, so the customer can find it later instead of hunting through a long chain.
Q4. Do bullet points help or hurt?
They help for genuinely parallel items, such as documents required or steps in order, and they hurt when unrelated sentences are broken into a list. A list implies the items belong to one set, so readers look for a pattern that is not there and slow down.
Q5. Why does a reply lose all its paragraph breaks in some mail clients?
Because clients disagree about whether a plain line break inside HTML counts as a line break. Messages that rely on the whitespace in the source can arrive as one unbroken paragraph, so the break has to be explicit in the markup rather than implied by the layout of the text.