Once a buyer has found a seller offering they want to purchase, or a seller has found a buyer request they want to fulfill, the next question is how they initiate the transaction booking process. Sometimes this is a one-step unilateral decision (e.g., “buy now”) and other times it involves more steps or negotiations to get to a transaction. You always want the least friction possible while still ensuring that both sides fully understand what they’ll be giving and receiving and will be happy with the outcome.
What types of communication do you need between users?
When getting users to a transaction, there are times that the platform will need to allow communications between users. This can happen before the transaction to negotiate terms or can happen during the services to ensure both sides know what’s going on. Here are a few communication options.
Offline communiciation |
The easiest way to set up communication is to just let users discuss terms off your platform. This works if your business model does not rely on a transaction fee, since offline communication can lead to circumventing a platform fee. You can allow one side to send over their contact info or allow them to display contact info to other users on the platform. |
Email relay |
If you still want to allow emails, but want to maintain user privacy or reduce the risk of transactions happening offline, you could set up an email relay service such as Sendgrid or Postmark which would not expose the user’s personal email addresses. |
In-app messaging |
Another common and simple way to handle messaging is to have an internal messenger on the platform. Users would be able to see the messages after logging into the platform, and you can set up email notifications for when a new message is delivered. You can also pair this with an email relay to make it possible for users to reply to the email and have that response get delivered into the platform. |
SMS / audio |
Some types of marketplaces would benefit from more immediate notifications or timely back and forth during the transaction itself. This is common for ride sharing or delivery marketplaces. For these types, you may want to integrate with something like Twilio Proxy, which allows a temporary intermediary phone number to be set up that both parties can use to communicate with each other. |
Video |
Some marketplaces require live video chats, whether that is in the purchase evaluation phase like in a consultation or scoping call, or as part of the service offered itself, such as with coaching or a virtual therapist. The simplest way would be to require sellers to set up their own video platform on Zoom or Google Hangouts and provide the links when someone purchases their service. A more complex way would be to build a custom video chat experience using a service like Twilio or Jitsi. |
How is the transaction initiated and confirmed?
This is the critical step in your marketplace platform, where your users agree to a transaction! Because this is the step that marks success for all parties (buyer, seller, and platform), it is important to make it as frictionless as possible, while still ensuring that each party knows what they are getting into (and can customize as needed). There are a few common options.
Instant purchase or booking |
This is the “buy now” approach, and is most common with products, events, and certain services. This is the optimal option because it’s the least friction and simplest. However, this is only possible when everything about the transaction is clear to both parties and when the seller will definitely accept, such as when selling specific products or offering clear service time windows that they will deliver on regardless of the buyer.
|
Multiple vendor checkout |
Buyers may want to add products from different vendors to their cart and checkout all at once. This however, can be a complicated flow and you’ll want to think through the user experience and tradeoffs if you go this route. The complication comes from separating out invoices and payments for each vendor for their respective items. This is possible with providers like Stripe, but is a more custom flow. Large marketplaces such as Etsy often require one purchase per vendor at a time to avoid these complications. |
Bid or proposal |
With this option, the initiator sends a request to the receiver, where they can either confirm, decline, or counter. This is the classic Airbnb option, where you reach out to the host to request certain dates and they can respond. This is also how some service marketplaces work, where service providers may have a calendar of availability but want to confirm to avoid conflicts off the platform. This is also the most common approach for gig platforms where the buyer issues a project or request, and then multiple vendors submit proposals to be reviewed by the buyer. Upon accepting a proposal, the others proposals can be auto-rejected. |
Discussion or negotiation of terms |
This is the least structured option, where one side simply starts a dialogue with the other to try to reach an agreement on a transaction. This is best for highly complex transactions (e.g., real estate contracts) or transactions where “fit” is the key and needs time for both sides to trust one another such as skilled contractors. Chats can happen in the app, via email, or via text or SMS. The key to this approach is knowing when a transaction has actually occurred, because users may try to take the transaction offline. Offering additional value such as payment and analytics tracking or insurance can mitigate this risk, and you can offer a simple invoicing service to incentivize users to keep the transaction on platform. |
How are the terms of the transaction determined?
Every transaction between buyer and seller has terms about what the seller will do and what the buyer will pay. Some marketplaces (e.g., product) are so commonplace that you may not think of the terms, while in others every contract is unique. Terms clearly have a legal angle, so you should consult your lawyer (or at least templates that are out there) as part of your process. But for product UX here are some options.
Platform generated terms |
This is the most common way to set the transaction terms and is typical for product marketplaces where the transaction terms are mostly standard. Here the terms are agreed to by both sides when they first sign up for the platform and agree to the site’s terms and conditions. |
Auto-generated custom contract |
For some marketplaces, an explicit contract is warranted between two sides, to ensure they are explicit about what they agree to. Here a custom contract can be generated by filling in some terms based on user choices, and an e-signature contract is generated to be signed by both parties. This is sometimes necessary with complex transactions such as real estate or expensive consulting work, especially where there is more risk of something going wrong. You can use services like Docusign, Hellosign, or Eversign for this, which will allow contracts to be emailed to users and/or embedded within the site itself. |
Manual custom contract |
For platforms where sides discuss projects off platform or through an in-app messenger, contracts are often decided through uploading fully custom docs. There will still be some site-wide terms governing these free-form interactions (i.e., saying “we’ll connect you, you’re on your own”). This is good for situations that are highly custom and where there are professionals on both sides who are used to working with contracts (and perhaps where the sellers have their own) -- e.g., a construction marketplace or design agency marketplace. |
