Four days, nothing back. The instinct is to write the nudge.
Write the diagnosis first. A follow-up that ignores why the first message failed sends the same failure again with an apology stapled to the front, and the second silence is much harder to recover from than the first.
Work the list in order. Only the last step involves writing anything.
Diagnose before you nudge
Was there an actual ask? The most common reason a briefing gets no reply is that it never required one. Information with an implied question reads, on the other end, as information. You meant do you agree; they read noted; nobody misbehaved. If the response shape you picked was fyi, silence is the correct outcome — a thread whose last package is an FYI settles to idle once it has been seen, rather than sitting there as an open obligation. Picking the shape deliberately only works before the send.
Was it answerable at the cost you implied? "Quick question" is a claim about the reply, not about the request. If answering means pulling numbers, reading the attachment properly, or checking with a third person, the reader has a thirty-minute task and five minutes. It gets deferred, and deferred is where messages die. The test is whether they could have answered from what was already in front of them.
Was the deadline real? A date with no constraint behind it and no stated consequence is a preference, and readers price preferences accordingly. How to set a deadline someone will believe has the mechanics; the short version is that "by Friday" and "after Friday I go with option B" land differently because only one of them is checkable.
Did it arrive at a bad time? The least interesting explanation, and the one that most often turns out to be true. Ship week, travel, a quarter close, a sick kid. Nothing about your message caused it and nothing about your message fixes it.
There is a fifth check, embarrassing often enough to do first: confirm the thread is actually waiting on them. RelayLink groups threads under three headings — awaiting the user's reply, awaiting others, and idle — and threads turn up under the first heading more often than people expect. They answered briefly, you read it, and you are the one who went quiet.
What the system will tell you
For threads in the awaiting-others group, RelayLink adds exactly one piece of information about the most recent package: they have seen it, or not seen yet. That is all of it. No timestamp, no count, no per-package history, nothing about which sections were read.
You can narrow it to one person by passing their email, and it is worth knowing the shape of the window — the check scans the fifty most recently active threads and returns at most twenty-five rows, with the per-person filter applied after that scan. A thread you last touched months ago may simply not appear.
One consequence people miss: the flag describes the latest package on the thread. Send a nudge and it starts describing the nudge. If you want to know whether the original briefing landed, ask before you follow up, not after.
What "seen" means, precisely
Seen means one of exactly two things happened. The recipient's assistant pulled the package through MCP, or somebody fetched the magic-link page. Nothing else counts.
It is not email-open tracking, and it structurally cannot be. Notifications go out as plain text with no HTML body, so there is no pixel to fire. Someone can read the entire notification in their mail client — your note, the TL;DR — and the thread will still say not seen yet. That state is ordinary rather than exotic: the email carries your note and the summary, but the context brief lives behind the link.
In the other direction, a fetch is a fetch. A link-scanning appliance in front of a corporate mailbox will request that URL, and RelayLink will record it. The product's own wording is deliberately cautious for this reason. Seen is not read, and it is a long way from read the brief and formed a view.
Treat it as evidence about reach, not about attention.
Then write the follow-up
The flag splits the problem cleanly.
Not seen. Reach is the suspect, not indifference. Confirm you used the address they actually read, then consider the spam folder — why mail lands there is rarely about the sentence you wrote. If they have already told you it never arrived, work that case separately.
Seen, and nothing came back. Reach is fine, so the ask is the problem. Do not resend the same package with "bumping this" on top. Send a smaller one — the single decision, the two options, the date. Following up without nagging is mostly about making the second message cheaper to answer than the first, not more insistent.
Either way the follow-up is a new package on the thread, drafted and approved like anything else. There is no unsend and no edit-in-place, so the original stays exactly as it was sent — which is fine, because a dated record of what you asked is what lets the second message be three lines long.
Silence is sometimes the answer
Sometimes the answer is no and they would rather not put it in writing. Sometimes the decision was never theirs and saying so feels like an admission. Sometimes you asked a person with no stake in the outcome, and a person with no stake has nothing to send.
The move that respects all three is to stop asking and start declaring. Name the default, do the thing on the date, and let the next message be a courtesy rather than a request. That is also the only follow-up that improves your position when it goes unanswered too — the reply was always the point, and if the reply is not coming, the next best outcome is a decision that stopped waiting for it.
A second unanswered follow-up is information about the relationship, not about the email system.
If you would rather ask a status question than reread a thread, connect your assistant — and ask it before you write the nudge, not after.