A subject line is written once and read twice. The first read takes a second, in a list view or a lock-screen preview, and decides whether the message gets opened now or Thursday. The second happens eleven months later, when somebody is hunting for it with a handful of words to search against.
Both reads want the same thing — an accurate description of what is inside. They usually get a pitch.
Why readers stopped believing subject lines
The subject line is the one field in email that got optimized against its own readers. It sits atop every list, is guaranteed to be seen, and costs nothing to write — so it became where senders compete for attention rather than describe contents. Reasonable for a newsletter. The problem is that people writing ordinary work messages copied the technique, because in the short run it visibly works.
What follows is the erosion that happened to the word "urgent". A reader burned by "Quick question" (it was not) and "Following up" (on nothing they remember) stops reading subject lines as descriptions and starts reading them as claims by an interested party. You cannot fix that at the ecosystem level, only for the twenty or so people you correspond with regularly — which is the only audience most work messages have.
Say the topic and the ask type
The two facts a reader needs before opening are what the message is about and what it wants from them. Most subject lines supply the first and leave the second to be discovered in paragraph three.
Put both in:
- Decision needed — vendor by Friday
- Review request — API migration plan
- FYI, no reply needed — office move dates
Not "Vendor stuff", not "Quick sync?". The ask type is what changes behaviour: someone told they must decide handles the message differently from someone who thinks it is background reading — and can tell without opening it.
It is also the honest version of urgency. "Decision needed — vendor by Friday" states something checkable against what happens next; "URGENT" in caps states nothing. If you put a date in a subject line, make it a real one.
RelayLink formalises that half — every package carries a response shape, one of opinion, decision, review, info or fyi, as a stated field rather than a tone. Picking the shape is the same call as writing "Decision needed" at the front, except the reader's assistant can sort on it.
Front-load the distinguishing word
Subject lines get cut off. List views truncate them, notification previews truncate them harder, narrow windows hardest. Whatever survives is the first few words, so they have to tell this message apart from the nine others in the list.
"Following up on the conversation we had last week about the vendor decision" truncates to something indistinguishable from every other follow-up. "Vendor decision — following up from last week" still names the subject. Same words, different order.
The rule: your first three or four words should be the ones you would use to describe the message to a colleague in a corridor. Qualifiers go after. This matters more inside a wrapper — a RelayLink notification email leads with the sender's name and then the thread topic, so the topic starts well into the line, and throat-clearing at the front of it may never reach the preview.
Don't reuse a thread for a new topic
The most common subject-line failure is not a bad subject line. It is a good one describing a message that is no longer about that.
Replying to an old thread to raise something new is convenient for the sender and charges the recipient twice. Now, because the new thing hides behind a label saying it is the old thing. And later, because the archive holds a thread whose title describes only its first half — everything after the turn is unfindable by the words that describe it.
That second cost lands months later, often on somebody who is not you. Threads are the unit of retrieval in almost every mail system, and threading runs on message-identifier headers, with subject matching as a fallback in some clients. Neither notices that the humans changed topic halfway down.
RelayLink makes that blunt, because there is no keyword search over packages or threads at all. Discovery is the inbox, the thread list and thread status, each identifying a thread by its topic string alone. A stale topic is not a degraded search result; it is the only handle there is, pointing at the wrong thing.
New topic, new thread.
What a subject line cannot do
A subject line is a label on a container. It cannot improve the contents.
If a message has no clear ask — if the reader finishes it still working out what a good response would be — then "Decision needed" at the front is a false summary, and it burns the credibility this practice runs on. The reader learns that your "Decision needed" means "you were on the list".
So the order is fixed. Work out what you want back, write the message that produces it, then label the container. Designing backward from the reply comes first, because a description needs something to describe. A real ask under a vague subject gets answered late. A sharp subject over no ask gets answered never — and the subject line made it worse by working.
The ten-second check
Read your subject line as the recipient scanning forty of them. Does it say what this is about? Does it say what it wants? Is the distinguishing word near the front? Is it still true of the message underneath?
Four yeses gets you discounted less than average — the whole available prize. If you would rather that were structural than remembered, connect your assistant — a thread topic is required on anything new and capped at 120 characters, short enough that padding does not fit.