Custom sourcing versus database retrieval

Expert networks describe themselves in similar language and operate in two quite different ways. One retrieves from a standing pool. The other recruits against the brief. The distinction is invisible on a website and decisive on a difficult question.

The database model

A database network invests in scale. It recruits experts continuously, tags them by sector, geography and seniority, and answers briefs by querying what it already holds. The economics are attractive: recruitment cost is amortised across many briefs, and marginal delivery cost is low.

For a common question in a well-covered market, this is the better model. Speed is genuinely fast, the tagging is reliable because it has been tested by prior briefs, and the client pays for a system that has already absorbed the sourcing cost.

The model degrades in a specific way. It cannot distinguish between "no suitable expert exists in the pool" and "the closest available profile is roughly adjacent". Both return results. The client receives a shortlist either way, and the quality difference only becomes apparent during the call.

The custom-sourcing model

A custom-sourcing network starts from the brief. It maps the seats that would produce the required experience, identifies people who have held them, approaches them individually, screens them and briefs them. Some become long-term members of the network; many take one call.

The cost profile is inverted. Sourcing is expensive per brief and cannot be amortised in the same way, which is why custom-sourcing networks typically carry different pricing structures. The compensating advantage is that the answer to "is there someone who can answer this" is determined by whether such a person exists, not by whether they were already signed up.

It is also slower, and honest custom sourcing says so. Two to five business days to a shortlist is a realistic figure when the pool is being built rather than queried.

Where each model belongs

Use retrieval when the question is standard, the market is deep, and speed matters more than precision: a channel check in a large consumer market, a broad sector overview, a first orientation call at the start of a diligence process.

Use custom sourcing when the question is narrow, the market is thin, or being wrong is expensive: regulatory practice in a single jurisdiction, a specific concession or licence, a named counterparty's operating reality, anything where the useful population is measured in dozens.

Many research programmes need both, at different points in the same workstream.

Hybrid claims deserve a specific question

Most networks now claim to do both. Often that is true in the sense that a sourcing team exists and is used when a query returns nothing. The question worth asking is what triggers custom sourcing, and who decides. If the trigger is a client complaint about a weak shortlist, the model is retrieval with a fallback. If the trigger is the brief itself, it is sourcing.

A related question: does the network charge for sourcing, shortlisting, or declined candidates. A network confident in its sourcing does not need to bill for the attempt.

What this means for how you buy

Compare like with like. A retrieval network's price should be read alongside its multipliers, minimums and platform fees; a sourcing network's price should be read alongside what is included and how many candidates you can decline.

Then compare the failure modes. The retrieval failure mode is a plausible expert who is subtly wrong for the question. The sourcing failure mode is a longer wait, or an honest statement that the person does not exist. For institutional research, the second failure mode is the one you can manage.