Hosted Buyer Program: Looking Under the Hood

Hosted Buyer Program: Looking Under the Hood

Hosted Buyer Programs (HBPs) have become a must-have for many B2B events, connecting prequalified buyers with relevant exhibitors to foster meaningful business relationships. In this post, we unpack the algorithms and engineering that power this crucial feature.

Beneath the smooth surface of a polished user experience lies a tough core engine. Algorithms, graphs, and optimization do the heavy lifting, with the traditional touch of let's fit this square into that circle that characterizes any carefully designed theory when it meets real-world messiness. Still with us? Great. Let's dive in!

The Assignment Problem: Events Edition

In 1962, D. Gale and L. S. Shapley [1] introduced the assignment problem, which laid the groundwork for understanding how to match two sets of agents based on preferences. The assignment problem is a fundamental combinatorial optimization problem that is still very active today, with fields of application ranging from admission control in French universities to kidney transplants programs¹.

HBP essentially boils down to a sophisticated assignment problem: how do we optimally match a set of buyers with relevant exhibitors for meaningful, business-driving meetings? At first glance, it seems simple—pair each buyer to suitable sellers—but the reality is much more complex.

Unlike textbook bipartite matching, live event scenarios introduce a mesh of interleaved constraints:

Physical Scheduling is limited by time (overlaps, event duration) and space (room capacity, access rights). HBP must avoid proposing impossible meetings.

Practical Attendees are busy. One cannot expect people to carefully grade every single potential meeting. We're limited to a few simple choices like “must meet”, “nice to meet”, or “do not meet”. For more nuance, HBP must extrapolate preferences using minimal user input.

Flexibility Real-world roles are fluid: a participant may buy milk and sell cheese; another might opt for a premium upgrade; journalists might squeeze in interviews… HBP must handle a hierarchy of possibly overlapping/conflicting conditions.

Fairness Purely optimal algorithmic solutions may inadvertently favor some, leaving others with little—HBP should nudge the system toward fair outcomes, so everyone benefits from the experience.

Individually, these five facets (assignment plus the constraints) are manageable. The real challenge—and opportunity—is orchestrating all of them together, without converting your workflow into an unwieldy machine. That's why, instead of off-the-shelf modules, we designed our own custom HBP algorithm.

Beauty is in the Eye of the Organizer

A fundamental issue of assignment is the blocking pair [5]: Consider three participants, say Alice, Bob, and Charlie, with only one possible meeting slot. Alice wants Bob, Bob wants Charlie, Charlie wants Alice.

Which meeting shall we schedule?

Set up Alice–Bob? Bob and Charlie will “block”: Bob wants Charlie, and Charlie has no meeting. Maybe Bob–Charlie then? Now Charlie and Alice block: Charlie seeks Alice, and Alice is left alone. Try Charlie–Alice? Alice and Bob block that.

The cycle highlights a simple truth: every participant views meetings differently. Focusing only on their perspective creates conflict. Instead, each meeting should have a value set by the organizer, folding in individual preferences and the broader event context into one clear score. After all, it's the organizer who orchestrates the event, so the final decision should rest here. Theoretically, this simplifies the problem [2]; practically, it allows meetings to be ranked by a single score.

One score to rule them all

Our scoring function is designed to synthesize all relevant signals, blending them smartly. These factors include:

Reciprocity If Alice wants to meet Bob, and Bob reciprocates, the score goes up.

Priority Premium participants or sponsor status should boost meeting scores.

Intensity “Must meet” preferences trump mere interest.

Affinity A shared background increases the value.

We structure signals in a precedence order: reciprocity outranks priority, which rules over intensity, which surpasses affinity. This ensures the most critical factors are always weighed first, with subtler signals retaining influence.

Armed with these weighted scores, meeting choices can be justified. In Alice-Bob-Charlie example above, should the organizer pick Alice–Bob and face objections from Bob and Charlie, there's a transparent rationale: perhaps Alice paid for premium priority, or flagged Bob as “must have”, or shares greater professional affinity. Maybe Charlie explicitly opted out of meeting Bob, etc.

One meeting at a time

A scoring function in hand, scheduling unfolds through a simple workflow.

Meetings ← All compatible meetings
for meeting ∈ Sorted(Meetings, decreasing)
    if IsValid(meeting)
        Instantiate(meeting)

Hosted Buyer Program core loop

Step-by-step, the process works as follows:

Preselect compatible meetings All conditions set by the organizer are reviewed; meetings explicitly disallowed by participants or those breaking condition options (e.g., existing contacts, colleagues) are excluded.

Sort by decreasing scores This is where the magic happens. When we process a meeting, we know that it is more important than any meeting not processed yet, so we can fully focus on it.

Validate meeting Compatibility isn't enough. Schedule checks, load levels, room logistics, and dynamic issues (such as not meeting the same company twice) are all considered.

Instantiate the meeting Choose the best time and place for that meeting: Avoid gaps, minimize commute, prefer dedicated spaces like booths… Tag the meeting with its score, including some basic affinity details.

Repeat Continue until no further meetings can be placed, or participant quotas are reached.

Performance is a central theme: our current system can process thousands of participants and hundreds of thousands of meeting possibilities in mere seconds.

Beware of Unicorns

Some competitors promise “perfect” solutions no matter what you throw at them, often touting terms like “AI-powered” or “machine learning-enhanced”. We promise “best-effort” solutions, grounded in good old-fashioned algorithmic principles and practical engineering².

Above all, we emphasize that no algorithm can guarantee a flawless match in such a complex, constraint-laden environment. Consider for example the following scenarios, which may look trivial but are inspired by real events:

One for all, and all for one

One organizer wants to set up one-to-one meetings between one single buyer and multiple exhibitors. After receiving our proposal, they complain that exhibitors are mostly idle. The issue here? Unlike Schrödinger's cat, the buyer is not in a superposition of states and can only be at one place at a time. In other words: exhibitors have to wait their turn.

Sometimes the organizer's expectations clash with physical and practical constraints, in ways that are not necessarily as obvious as in the above example. HBP keeps track of such conflicts (e.g. people, place, and time availabilities) to help the organizer understand what happened, and why.

Have your cake and eat it too

Quality or quantity?

Consider the small one-time-slot-only HBP described in Figure 3. You have a true decision to make:

  • Match Alice with Bob, Charlie with Diana, ending up with two acceptable meetings, or
  • Select the high-profile meeting with Bob and Charlie, leaving Alice and Diana without meetings.

We cannot stress this enough: no algorithm can magically solve such dilemmas. One must choose between quality (fewer, higher-value meetings) and quantity (more meetings, possibly of lower value). We choose quality, because it is easier to tell Alice and Diana that Bob and Charlie really want to meet than to explain Bob and Charlie that they will not meet because Alice and Diana refuse to meet.

That being said, quantity has its perks too. Notably it helps fairness, ensuring more participants get at least one meeting. To balance quality and quantity, HBP incorporates a fairness heuristic through its minimum/maximum number of meetings parameters:

Quality prevails for a participant until they reach their minimum number of meetings.

Quantity takes over afterwards, favoring meetings with under-allocated participants.

Conclusion

Swapcard's Hosted Buyer Program is a smart solution to the complex challenge of matching buyers and exhibitors. Built on top of academic research, it uses a scoring system that balances organizer goals with participant preferences, ensuring fair, flexible, and high-quality meetings.

For users, this means faster, more relevant matches and a smoother experience overall. HBP processes thousands of participants and meeting options in seconds, turning a complicated process into an efficient, personalized journey that helps everyone get more value from the event.


References

[1] D. Gale and L. S. Shapley, “College Admissions and the Stability of Marriage,” The American Mathematical Monthly, vol. 69, no. 1, pp. 9–15, 1962, Accessed: Sep. 05, 2025. [Online]. Available: http://www.jstor.org/stable/2312726
[2] F. Mathieu, “Self-stabilization in preference-based systems,” Peer-to-Peer Networking and Applications, vol. 1, no. 2, pp. 104–121, 2008, doi: 10.1007/s12083-008-0009-3.
[3] F. Mathieu, G. Postelnicu, and J. Reynier, “The Stable Configuration of Acyclic Preference-Based Systems,” in INFOCOM 2009, Rio de Janeiro, Brazil: IEEE, Apr. 2009, pp. 1440–1448. doi: 10.1109/INFCOM.2009.5062060.
[4] C. Comte, F. Mathieu, S. M. Varma, and A. Bušić, “Online Stochastic Matching: A Polytope Perspective,” Nov. 2024. [Online]. Available: https://hal.science/hal-03502084
[5] C.-P. Teo, J. Sethuraman, and W.-P. Tan, “Gale-Shapley Stable Marriage Problem Revisited: Strategic Issues and Applications,” Management Science, vol. 47, no. 9, pp. 1252–1267, 2001, doi: 10.1287/mnsc.47.9.1252.9784.

¹Incidentally, my own research touches on this field ([2], [3], or [4]).
²And yes, before you ask: it's also “AI-powered” and “machine learning-enhanced”. But what isn't nowadays?