Seller Communication Templates
Open the message builder
Every message the desk sends to a seller is built the same way: one line of context, one question or one request, one deadline, and one sentence about what happens next. Four parts, in that order, and nothing else. The constraint is the point. A message that fits that skeleton cannot wander, and a seller reading it between other tasks can answer it without asking which of six topics is being raised. The skeleton is deliberately dull, and dullness is what keeps a message from being read as a negotiating position.
Context comes first because a seller may be handling a dozen threads at once. The line names the order date, the item and the specific part in question, in as few words as the record allows: the pair ordered on the fourteenth, the left heel counter. Topics get separated rather than combined, since two questions in one message usually produce one answer, and it is rarely the answer to the harder question. Splitting topics also means a reply that answers one of them is visibly incomplete rather than quietly insufficient.
The request has to be answerable. Ask for a batch marker, a dispatch date, a measurement or a photograph, not for an opinion about quality. A request that can be met with a single word makes a non-answer visible, which is exactly what a later reader needs to see. Where a seller cannot answer, the silence itself becomes a dated fact that belongs in the file. The desk prefers a request a seller could answer badly, because a bad answer is information and no answer is not.
The deadline is the part most buyers skip, and it is the part that moves a thread. A date attached to a request is not a threat; it is information about when the next step happens if nothing arrives. The desk writes it as a plain date rather than a warning, and then keeps to it, because a deadline that is never acted on teaches the other side that the next one can be ignored. Set the date far enough out to be reasonable and near enough to matter; four working days is the figure the desk uses for most requests.
Choose the scenario
Six situations cover nearly every message the desk sends. Confirm a batch or a version before paying; confirm the dispatch window after paying; report a flaw with the photographs already attached; ask for a specific remedy; negotiate a partial refund against a stated figure; and close a case once the money has landed. Each has its own opening line and its own evidence expectation. The blocks are shapes rather than scripts to be followed word for word, and the facts inside them always belong to one particular order.
Using the wrong block wastes a round. A flaw report sent in the language of a pre-purchase question reads as haggling and invites a price discussion instead of a remedy. A remedy request sent without a photograph invites a request for a photograph, and the case loses two days. Choosing the block is really a decision about which facts the other side needs first. The desk's own note on this reads: the message that arrives second usually costs less than the message sent twice.
Pre-purchase messages carry the most value per word. A batch confirmation before payment settles a question that no later message can settle as cheaply, because nothing has been committed and no fault has to be alleged. In the desk's reading of buyer reports, pre-purchase replies are among the few message types that reliably change what eventually arrives. That reading covers replies only, so it says nothing about sellers who never answered, which is a separate question with a different lesson.
Closing messages are the ones most often forgotten, and the desk treats them as compulsory. A short line confirming the amount, the currency and the date turns a settlement into a record, and it prevents the same case being reopened a fortnight later over a detail nobody wrote down. It also ends the thread cleanly, which matters when the same storefront is used again. A case with a written ending is also easier to reopen if the settlement turns out to be incomplete.
Read the generated text
Read the draft back before sending it, with one question in mind: could a stranger holding the file act on this? If the message names no date, no measurement and no specific part, the answer is no, and the reply will be a request for clarification. Six seconds of reading prevents the most common wasted round in the desk's sample. Reading it aloud catches the sentences that only made sense while the file was open on the screen.
Check for accidental concessions. A friendly opening such as I know these things happen, or I should have checked the size chart, reads as an admission when it is quoted back inside a case file. Warmth is not the problem; agreeing to a fact that has not been established is. Keep the pleasantries in the greeting and the facts in the body. Everything meant to persuade lives in the documents, and everything in the message is a fact somebody could check.
Look for what translation does to a request. Idioms, sarcasm and long subordinate clauses survive poorly, and a question that depends on tone can arrive as a statement. Short sentences with concrete nouns travel better, and numbers written as digits are read correctly far more often than numbers written as words. Where a translation feels wrong, the useful move is to shorten the sentence rather than to repeat it in different words.
Read the message once more for the ask. A draft that explains the problem and never states what is wanted hands the initiative to the other side, and the first offer in an exchange tends to set the range for everything after it. Where the ask is a remedy, it should name one of the three forms the desk recognises: a refund, a partial refund at a stated figure, or a replacement. Naming one of those three also makes a refusal clear, and a clear refusal is a decision rather than a delay.
Common wording pitfalls
Vague quality words are the first pitfall. Bad quality, not as described and very poor all state a conclusion rather than an observation, and each invites a reply that disagrees with the conclusion. A scratch of eleven millimetres on the left panel is an observation, and the only useful answers to it are a remedy or a refusal. The same rule applies to praise: a sentence about how good the rest of the order looked adds nothing a reader can act on.
Questions that can be settled with one agreeable word are the second. Is it good quality, is it the same as the photo, and can you send a good batch all invite yes, and a yes of that kind cannot be checked later. Ask instead for the specific marker, measurement or date, so the answer carries information whichever way it goes. A question with two parts is a question with one answer, and the part left unanswered is usually the part that mattered.
The third pitfall is stacking. Three questions in one message typically produce an answer to the easiest one, and the other two are then treated as settled by silence. Send one request per message even when that means two messages a day apart, and keep each thread to one subject so a later reader can follow which reply answered what. Threads mixing subjects are also harder to attach to a case file, because the dates stop lining up with the topics.
Threats, review promises and legal language are the fourth pitfall, and all three cost more than they return. A threat invites a defensive reply from somebody who may have been willing to help; a promised review becomes a condition that can be quoted back; and a legal framing asks a seller to answer as an adversary. The desk describes process and evidence, gives no legal advice, and writes to sellers as though the thread will be read by a stranger later, because it usually is.
Template blocks and the wording they replace
Editorial compilation, sample size 0 for the blocks themselves; the four-part skeleton and the scenarios were written from a reading of 58 public thread entries in which a buyer quoted a message to a seller and the reply that followed, up to 2026-09-28. The table records wording this desk uses, not wording any platform recommends.
| Item | Reading |
|---|---|
| Scenario | Block the desk sends, and the wording it avoids |
| Ask for the batch | Names the batch marker and a reply date; avoids asking whether quality is good |
| Confirm dispatch window | States the date the order has to move by; avoids asking for a fast shipment |
| Report a flaw | Names the part, the measurement and the frames sent; avoids calling the item bad |
| Negotiate a partial refund | Puts one figure and one reason in a line; avoids asking what can be done |
| Close a settled case | Confirms amount, currency and date; avoids leaving the thread open |
Sources and checks
- Public community thread — Threads in which a buyer quoted their own message to a seller and the reply that followedn=58
- Editor analysis — Four-part skeleton and scenario set written by the desk; no platform wording reproducedno sample
Last checked · next review due · status current.