KoltrixTwo-Sided Marketplace Emails: Buyers, Sellers and Disputes
Marketplaces email two audiences about the same events. How to map messages for buyers and sellers, relay conversations, handle disputes and route replies.
On this page(7 sections)
A single-sided SaaS product emails one kind of customer. A marketplace emails two, about the same events, with different interests: when an order is placed, the buyer wants reassurance and the seller wants instructions. Get the two out of step and you create support tickets on both sides.
This post covers how to plan marketplace email so each side gets the right message, conversations between them stay safe, and disputes don't turn into chaos.
Start with an event map, not templates
The most useful planning artifact for marketplace email is a table of events with a column for each side. It forces you to decide, for every event, who needs to know and what they need to do.
| Event | Buyer gets | Seller gets | Platform team gets |
|---|---|---|---|
| Order placed | Confirmation with what, when, total | New order with what to do and by when | Nothing, unless high value |
| Seller accepts | "Your order is confirmed" | Nothing (they just did it) | Nothing |
| Seller declines or times out | Explanation and next options | Reminder before timeout; notice after | Alert if declines spike |
| Shipped or delivered | Tracking or delivery confirmation | Confirmation that status updated | Nothing |
| Message sent between parties | Relayed message notification | Relayed message notification | Flagged keywords only |
| Review requested | Review prompt after completion | Review prompt for the buyer, if two-way | Nothing |
| Dispute opened | What happens next, timeline | What was claimed, how to respond, deadline | New case in the queue |
| Dispute resolved | Outcome and any refund | Outcome and any payout change | Case closed |
| Payout sent | Nothing | Payout notification | Nothing |
Write this table before you write a single template. Gaps show up immediately, such as an event where neither side is told anything, or one where both get the same generic message.
Write for each side's job
The same event means different things to each party.
Buyers want reassurance and clarity: what they bought, what happens next, when, and who to contact. Their emails should feel like receipts and status updates.
Sellers want instructions and deadlines: what they need to do, by when, and what happens if they don't. Their emails should feel like work orders.
For example, when an order is placed for a made-up handmade goods marketplace:
To the buyer:
Subject: Order confirmed: ceramic mug set from Hollow Clay Studio
Your order is placed. Hollow Clay Studio usually ships within
3 business days and will confirm shortly.
Total: $48.00. You can message the seller from your order page.
To the seller:
Subject: New order: ceramic mug set (respond by Thursday 5 p.m.)
You have a new order for 1 x ceramic mug set.
Please accept or decline by Thursday at 5 p.m. your time.
After that, the order is cancelled and the buyer refunded.The seller's subject line carries the deadline. The buyer's carries what they bought and who from.
Relayed messages vs direct contact
Most marketplaces let buyers and sellers talk to each other. The design question is whether they see each other's real email addresses.
Relayed conversations
Each party writes to a platform address, and the platform forwards the message. Real addresses stay hidden.
- Pros: Protects privacy, keeps transactions on the platform, gives you a record if a dispute arises, and lets you detect scams such as attempts to move payment off-platform.
- Cons: More engineering: inbound parsing, threading, handling replies from email clients, and dealing with quoted text.
Direct contact
You reveal email addresses after a certain point, such as a confirmed order.
- Pros: Simple to build.
- Cons: You lose visibility, transactions can leave the platform, and you've shared personal data that can be misused.
For most marketplaces, relayed messaging is worth the effort, at least until a transaction is complete. If you build it, make reply addresses unguessable. A reply address that's just a sequential ID lets anyone who can count insert messages into someone else's conversation. Sign or randomize the token.
Disputes: the emails that matter most
Disputes are where marketplace email is tested hardest. Both parties are frustrated, money is at stake, and every message may be quoted back to you later.
A few principles:
- Acknowledge immediately. The party opening the dispute should get a confirmation with a case reference and a timeline.
- Tell the other party exactly what was claimed and how to respond, with a deadline. Vague notices like "there's an issue with order 1234" generate replies asking what the issue is.
- Use the same case reference in every email in the subject line, so both sides and your team can search for it.
- State timelines and stick to them. If you say a decision comes within five business days, send an update on day five even if the answer is "we need two more days."
- Explain the outcome and the reasoning in the resolution email, along with any refund or payout change.
- Keep the tone neutral. Avoid language that sounds like you've decided before reviewing evidence.
Route dispute replies into a monitored queue staffed by people who can act, not a general inbox where they compete with password reset questions.
Payout and money notifications
Sellers care a lot about getting paid. Payout emails should state the amount, the period or orders covered, any fees or adjustments, and when funds should arrive, based on what your payment provider actually commits to. Don't invent timelines. If a payout is delayed or held, say so promptly and explain what the seller can do, if anything.
This is general operational guidance, not financial or legal advice. Payout terms and disclosures depend on your payment provider and jurisdiction.
Where replies go
Buyers and sellers will reply to automated emails, even ones that say "do not reply." Plan for it:
- Order and shipping emails: replies should go to the relayed conversation or a support queue, not disappear.
- Dispute emails: replies go to the dispute case.
- Payout emails: replies go to seller support.
A noreply address on any of these just moves the question to a contact form, minus the context. If you use a provider that threads replies to transactional mail back into a team inbox, such as Koltrix's signed reply addresses, the original message comes attached, which saves a round of "which order is this about?"
Key takeaways
- Build an event map with a column per side before writing templates.
- Buyers need reassurance; sellers need instructions and deadlines in the subject line.
- Relay conversations through the platform with unguessable reply addresses, at least until a transaction completes.
- Treat dispute email as a record: case references, clear claims, stated timelines and reasoned outcomes.
- Route replies from every automated email somewhere a person will read them.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
