Building an expert marketplace: connect booking, video and payment

What does an expert marketplace MVP need?

It needs a customer to find a suitable expert, choose a real available slot, understand the price, complete the consultation and receive a consistent payment outcome. A polished directory demonstrates discovery. It does not demonstrate the entire service.

Calledge brings expert discovery, scheduling, video calls, payments and invoicing into a platform that supports branded instances. Allom focuses on connecting businesses with relevant experts. Those two project scopes expose an important distinction: matching somebody with an expert and delivering the consultation are different product problems.

The design recommendations below address the second problem. They are a practical way to scope a new build, rather than a description of undocumented internals of either project.

Give each stage its own state

A consultation can be requested, reserved, confirmed, delivered, cancelled or disputed. Payment has a separate lifecycle. The two lifecycles influence each other, but collapsing them into a single status makes exceptions hard to explain.

Before building the interface, write down what each state means. Which actor can move it forward? Which external event confirms it? Can the action be repeated safely? What does the customer see while the result is uncertain?

For a first release, keep the number of customer choices modest. One consultation format and one clear cancellation policy can be easier to validate than several subscription, group and instant booking models at once.

Decide who owns availability

Availability is a promise that the product makes to two people. If an expert’s calendar is connected, identify which system owns the reservation and how competing requests are resolved. If an operator confirms bookings manually, make that state visible to the customer.

Test the uncomfortable cases early: two customers choosing the same slot, an expert changing availability during checkout, a missed payment confirmation and a call provider becoming unavailable. The response may involve an operator in the first release. What matters is that responsibility is explicit.

Treat payment events as a workflow

Stripe documents that webhook events may arrive more than once and may arrive out of order. Its idempotency mechanism supports retrying certain API requests without repeating the operation. A marketplace still needs its own consistent processing and reconciliation around those provider behaviors.

Before implementing payments, clarify who receives funds, who handles refunds and when the expert should be paid. Stripe Connect’s charge type documentation describes how integration choices affect funds flow and responsibility. The correct choice follows the operating model and the provider’s current availability for your markets.

For the MVP, a useful acceptance test follows one booking through a repeated event and then a cancellation. The customer, expert and operator should see mutually consistent outcomes. Do not make the browser’s success screen the only record of a transaction.

Build the operator’s view with the customer journey

When an exception occurs, somebody needs a way to find the consultation, inspect its current state and resolve it. That can begin as a small internal screen. It should expose the facts needed to act without asking the operator to reconstruct a story from several vendors.

The commercial benefit is concrete: customers can buy the promised service, and the team can handle the exceptions. Once that journey works, discovery, matching and brand customization have a stronger foundation to grow from.