A lead from a marketplace is not a plain "name + phone number" line. The moment it enters your system, it arrives with a load of structured information: the source that captured it, the quality score it was given before distribution, the category and geographic zone it's tagged to, the timestamp of its capture, and the proof of the customer's consent to be contacted again. Integrating a marketplace lead well, then, isn't just copying contact details into a CRM: it's preserving that structure end to end, rather than flattening it into a raw contact that would lose precisely what sets it apart from a bought list.
This dossier explains, independent of any single category, how to connect a marketplace's flow cleanly to your CRM and internal processes: what a lead actually carries beyond contact details, the technical routes by which it reaches your tool, how to map the fields without losing source traceability, how to align your handling steps with the two-sided model — including the feedback loop back to the operator — and finally the data governance to respect under the three-party FADP framework. The goal is never to compute a return, but to move a verified request along without damaging its usefulness.
What a marketplace lead carries beyond contact details
On a structured marketplace, a lead is never reduced to a name, a number and an e-mail address. It travels with a set of attributes that qualify it and make it usable: the identifier of the source that captured it, the quality score computed before distribution, the category and geographic zone it was tagged to, the precise timestamp of capture — its freshness — and the reference to the explicit consent the final customer gave to be contacted by a professional. It is exactly this load of information that separates a marketplace lead from a contact pulled off a list resold in bulk: the list carries only contact details, whereas the verified request carries its context.
Integrating correctly therefore means treating these attributes as first-class fields in the CRM, not as disposable metadata. Keeping the source identifier lets you later analyse your results source by source; keeping the score and category lets you route the request to the right handling queue; keeping the timestamp lets you prioritise the freshest requests, whose conversion rate into appointments is mechanically higher; keeping the consent reference lets you prove, at any moment, on what basis the customer may be contacted. An integration that crushes these fields to keep only the phone number loses the traceability that gives the model its value, and drops back down to the level of a plain file.
The routes a lead takes into the CRM
A lead can reach your CRM by several routes, from the most manual to the most automated. E-mail notification is the simplest: each validated request triggers a message that someone re-keys into the tool by hand. Periodic export (a CSV file, a spreadsheet) gathers several requests into a batch. The webhook and real-time API, by contrast, push each validated request straight into your pipeline the moment it's distributed, with its information load intact. Finally, some native connectors link the marketplace to the most common CRMs with no custom development. Whatever route you pick, one rule prevails: the lead's structure — source, score, category, zone, timestamp, consent — must survive the transfer, not just the contact details.
The choice depends on your volume and existing tooling. A small operation may start with e-mail and manual entry, but as soon as volume rises, re-keying becomes a source of errors and, above all, of delay: every minute lost between capture and the first call erodes freshness, one of the model's most decisive factors. A marketplace relays requests very quickly after capture; it would be a shame for your internal plumbing to add hours of latency. Automated ingestion via webhook or API makes each request appear in the right person's queue as soon as it's distributed, metadata included, and removes both the delay and the risk of faulty re-copying.
Mapping the fields without losing source traceability
Field mapping consists of matching each piece of information carried by the lead to a specific field in your CRM. The classic trap is to cram everything into a single "comment" field, which makes the attributes unusable. Good practice is to create dedicated fields: one for the source identifier, one for the score, one for the category, one for the zone, one for the timestamp, one for the consent reference. You also need to keep a stable, unique external identifier for each lead: it's what will later let you reconcile your CRM record with the original event on the marketplace side, to send back a status or raise a dispute.
One point deserves particular care: deduplication. Avoiding internal duplicates is healthy, but a genuine duplicate must not be confused with a legitimately shared lead. On a marketplace where exclusivity is arbitrated, the same request may be sent to several companies when it's distributed as shared: that's not an anomaly, it's the chosen distribution mode, known and capped in advance. Your deduplication rule must therefore rely on the external identifier and not on the phone number alone, so as not to wrongly reject a valid request. For the rest, normalise formats (phone numbers, category mapped to your internal taxonomy) while keeping the original values in raw fields: the external identifier, the source and the timestamp form the traceability spine that ties each record to its verifiable origin.
Aligning your handling processes with the two-sided model
A marketplace is two-sided: it links a "sources" side and a "receiving companies" side under shared rules. The receiving company's handling process therefore has every reason to close the loop rather than stop at receipt. It starts with a clear internal commitment: who calls back, within what timeframe — a fresh request is handled first — and under what statuses. It continues with feedback to the operator whenever possible: unreachable contact after several attempts, need out of zone, confirmed duplicate, converted request. This feedback isn't a formality: it feeds the scoring system and the evaluation of sources, and so improves the average quality of the requests in circulation, for you as for the other companies in your category.
In concrete terms, model a readable chain of statuses in the CRM: new, contacted, reached, qualified, appointment, won or lost, with explicit rejection reasons (invalid number, out of scope, duplicate). Those rejection reasons are precisely what the operator arbitrates: sending them back within the set window is part of the two-sided model's implicit contract, and it's what makes legitimate disputes possible. Finally, wire up reminders and automatic tasks so no fresh request sleeps in a queue: the value of a marketplace lead drops fast if no one handles it, and no upstream scoring makes up for a first call that never happened.
Data governance and FADP compliance in the CRM
The Swiss data protection framework (FADP) involves three parties in a marketplace request: the final customer who expresses the need, the source that captured their consent, and the receiving company that contacts them again. That consent travels with the lead; your CRM must therefore store it, make it viewable, and let you honour it — including when a customer asks not to be contacted again or to be erased. This calls for a dedicated consent field, with its reference, rather than a note lost in a comment. It also calls for keeping the provenance of each record: knowing that a request comes from the marketplace, and from which source, isn't just useful for analysis — it's evidence of the legal basis on which you're acting.
Sound governance comes down to a few simple principles. Restrict access to records by role, set a proportionate retention period and purge beyond it, and never mix marketplace leads — duly consented and traced — with contacts collected cold, whose legal basis is different: traceability would lose all meaning. Finally, plan a process to propagate an erasure request back to the operator, so that the three parties stay consistent. This hygiene isn't added bureaucracy: it's precisely what gives full weight, downstream, to the consent gathered by the source and the scoring applied by the platform.