Two sides of the market.One view of the operation.

The marketplace model

People, organisations and listings have different jobs.

A marketplace may have sellers, suppliers, buyers, employers, applicants or service providers. One organisation can participate in more than one role. A CRM model needs to represent those relationships without creating duplicate versions of the same person every time a new transaction begins.

Connect the operational records to the platform’s identifiers. A listing, booking or job should be traceable to its source. Decide whether the public platform or the CRM owns each field and which events are copied. A second, conflicting transaction database is a problem to avoid.

The CRM can complement the existing marketplace rather than replace the customer product. We scope the internal operation separately from the public listing experience, payment flow and participant accounts.

Operating workflows

Turn platform activity into a clear queue of work.

Supplier onboarding may need a document check, an owner and a next action. Buyer enquiries may need qualification and matching. A disputed booking may need its messages, payment status and assigned operator in one place. These are different queues with different completion rules.

We design views around responsibility and urgency. An operator should know what is waiting, why it is blocked and which source holds the answer. Managers need reports that separate participant acquisition, active supply, transactions and fulfilment instead of conflating them into one pipeline total.

Integrations should handle repeated events and failed requests. Receiving the same platform webhook twice must not create two tasks or two opportunities. The team needs visible connection health and a way to resolve exceptions.

Operational agents

Prepare context at the handover point.

An agent can prepare an enquiry brief, flag missing supplier information or assemble context for an operator resolving a case. Suggested matches need an agreed source and an explanation of the criteria; a plausible answer alone is insufficient.

Payment changes, refunds, listings and external messages require the appropriate permissions and review rules. Access to a CRM record should not silently grant the agent the power to change a payment provider or public marketplace account. Scope those actions explicitly.

The first release

Choose one operational bottleneck to resolve completely.

Start with a journey such as supplier onboarding, lead qualification or the handover after a booking. Bring the current platform API, representative records and the tools operators use outside it. The scope should cover the event, record, owner, action and observable outcome.

Our owned marketplace products give us direct experience with participant journeys, listings and the operational work behind a platform. Discovery applies that experience to the specific data, APIs and commercial rules your marketplace uses.

Custom CRM engagements start from £50,000, with the migration, platform connections, ownership and running costs agreed in the proposal. The operator gains a system built for the marketplace’s business model, with a clear plan for continuity after launch.