How to collect feedback in a two-sided marketplace

Buyers and sellers want different things

A marketplace has two customers who depend on each other. A buyer wants a fast, reliable way to find and pay for what they need. A seller wants visibility, fair fees and payments that arrive on time. Their feedback sounds different, and it asks for different fixes. A buyer who reports that search returns the wrong results needs a relevance fix. A seller who reports a delayed payout needs a finance fix.

Mixing those reports into one stream makes both harder to read. The team that owns payouts sees buyer complaints about delivery. The team that owns search reads seller questions about fees. Separating the two sides from the start keeps each group of reports with the people who can act on them.

Option one: one product per side

The cleanest setup is two products: one for buyers and one for sellers. Each product gets its own public key, its own allowed origins and its own notification webhook. The inbox filters by status and type work per product, so the buyer team reads only buyer messages.

Give each product a clear name, such as "Marketplace buyers" and "Marketplace sellers". Point the buyer product's allowed origins at the buyer site or app, and point the seller product at the seller dashboard. If the two sides share a web app, you can still load two widgets with two keys on different routes, as long as each route uses one key.

Two products cost nothing extra, and they stop the most common problem: a seller reading a buyer's complaint about a missing package and wondering why it reached them.

Option two: one product with a side in metadata

If your marketplace is small, one product with a side value in metadata may be enough. Set the side right before the form opens, so the metadata matches the screen the person is on:

window.EscutaProduto = window.EscutaProduto || { q: [] };
(window.EscutaProduto.q ||= []).push([
  "identify",
  [{ email: user.email, name: user.name, id: user.id, side: "seller" }],
]);

The metadata is stored with each item. The limitation is the inbox itself. Escuta Produto filters by status, type and text search, so you cannot click "sellers only" in the dashboard. Choose this option while the volume is low, and move to two products once the inbox grows. Splitting by side later is harder than starting with two products, so decide early if you can.

Escuta Produto has no tags. Use the side value as your grouping key, and use internal notes for decisions on each item.

Ask each side at the right moment

Timing matters more than the form. Ask buyers after a delivery or a completed booking, when they know whether the product matched the listing. Ask sellers after their first payout or after their listing is approved, when they have experienced the whole flow once.

Avoid the checkout. A buyer who is paying should not see a feedback form, and a seller with a listing still in review is waiting on your team, not answering a survey. Place a quiet link on the order history page for buyers and on the payouts page for sellers. The article on asking for feedback after a first success describes how to pick the right moment in more depth.

Use the matching type for each entry point. A buyer who reports a problem with an order can use the bug type, while a seller's suggestion about fees fits the idea type. Preselect the type with data-escuta-open so people do not have to choose.

Keep private details out of metadata

Marketplaces hold sensitive data: payment details, delivery addresses, tax records and bank information. None of that belongs in feedback metadata. Use ids rather than names where you can, such as an order id, a listing id or a seller id that your team can look up. Keep the metadata small, as it is capped at 4 KB.

Remember that the inbox is for your team. A buyer's address in a message is still personal data, so write the privacy notice to match what you collect, and remove details from a message before you share it outside the team.

Route each side's alerts

Each product posts to its own Slack or Discord channel. Create one channel for buyer feedback and one for seller feedback, and point each product's webhook at its channel. A new item shows its type, rating, sender and a 500-character excerpt, so the team that owns the problem sees it first.

If both sides go to one channel, you are back to a shared queue. Keep them apart. The article on organizing Slack channels for product feedback covers the trade-offs of one channel per product and one shared channel.

Set up Escuta Produto for your marketplace

Create two products, copy each public key into the right part of your app, and set the allowed origins for each site. Send a test report from a buyer account and a seller account, then check that each item lands in the right inbox and that the webhook posts to the right channel.

The notifications guide explains the webhook setup, and the widget reference lists the options for placement and language. For the first-run experience on the seller side, collecting feedback in a SaaS product shows how to identify logged-in users with plan and account metadata. You can also route marketplace feedback from a backend job with the REST API reference when a report starts in a system other than your web app.