You spent forty minutes with your assistant working out whether to rebuild the client's checkout or keep patching it. You have a real recommendation, a real tradeoff, and a number attached to each. Then you open your mail client, and forty minutes of thinking comes out as either eleven paragraphs of justification or a shrug in three lines.
Two days later: "whatever you think is best."
That is not trust. It is the client declining to own the decision — and an unowned decision on a freelance engagement still has an owner. It is you. Three months later, when the patch broke exactly as you warned, nothing in the thread shows that anyone but you chose it. That is the week of unpaid rework, or the scope change you now have to justify from behind.
Both failure modes have the same cause
Over-explaining and under-explaining look like opposites. They are the same mistake: you sent your reasoning instead of their decision.
The eleven-paragraph version is your working shown. To a client it reads as covering yourself, and the question is somewhere in paragraph nine. The three-line version is a conclusion with no handle on it, so the safest reply is the empty one. Neither contains a question a busy person can answer in a sentence.
Separate the recommendation from the options
The options are the space: what was genuinely possible, and what each costs in time, money, and risk. Write them as if you had no preference. Describe A in the light of your preference for B and the client can smell it — A stops being a real choice and becomes decoration.
The recommendation comes after, in its own paragraph: which one, why, and what you gave up. "I recommend the patch. It holds through the launch and costs a third of the rebuild. What we lose is that the same class of bug can recur, and we will have this conversation again inside a year."
The seam is what lets a client take your recommendation or pick a different option without it feeling like an argument with you — which matters more in freelance work, where you do not absorb the disagreement in a hallway afterwards.
Name the part of the decision that is actually theirs
You own which approaches are sound. They own how much soundness is worth to them.
A client cannot evaluate whether your migration plan is competent, and asking them to is theatre. They can absolutely evaluate whether three extra weeks is worth removing a known risk — it is their money and their calendar. Ask something on your side of the line and you get "whatever you think is best", correctly, because you asked a question they cannot answer.
So put the ask in their currency with a closed answer set: "Spend three extra weeks now to remove this risk, or accept it and ship on the original date?" One decision per message. If answering well means opening an attachment, you assigned homework rather than asking for a decision. The general version of that discipline is how to ask for a decision so you actually get one; the freelance-specific part is that the bounded question doubles as your record of who chose.
State the default if they do not reply
"If I do not hear by Thursday, I will proceed with the patch and hold the rebuild estimate open to the end of the month."
Three things happen. Silence stops being ambiguous. The client learns that not replying is itself a choice. And you keep working through the gap instead of eating dead air or billing for it.
A default only works if you honour it. Quietly wait an extra week every time and you have taught the client your dates are decorative.
Label the assumption they can correct
The expensive freelance failure is not rejection. It is a recommendation built on a premise the client knew was false and never mentioned, because it sat buried mid-paragraph instead of on its own line.
"Assuming the October launch date still holds" takes six seconds to read and gets back "it moved to January" — which changes the recommendation and saves two weeks of work in the wrong direction. Mark which claims are confirmed and which are your read. Clients correct a labelled line. They do not correct a paragraph, and they will not tell you which premise broke it; they just go quiet.
Where a briefing formalises this
A briefing is that structure made sendable. Two parts earn their keep in client work. The assumption labels let the client correct one inferred line rather than reject the package. The provenance label attributes commitments to you rather than to a draft you skimmed — verbatim, human-authored is earned only when your wording differs from the assistant's, so approval is never recorded as authorship.
On RelayLink the assistant assembles the briefing from your private session and you review the exact package before anything is released — the send flow in full.
When this is overhead
For "is Tuesday still fine for the call?", an email is faster and all of this is ceremony. Use the structure when the decision has a cost, a date, or a scope attached — maybe one message in ten. And none of it rescues a recommendation you have not made: with no lean you are asking for an opinion, and the format shows the gap instead of hiding it.
The checklist works in any email you write by hand, so take that first. If you would rather have the assembly done from the session you already had, connect your assistant.