AI matching at events: why connections don't happen
At an event with several hundred registrations, the organizer usually shares a general list and suggests that people introduce themselves.
Formally there are many contacts, but useful ones are few: the list gives no signal as to who is looking for an integration partner, who for an investor, and who came for a contractor.
Manual contact matching runs into the curator's throughput: in a day they manage to connect 10–15 pairs and by no means keep all interests and requests in mind.
After that, chance takes over — the person sitting next to them at a table during a break or the first person who came up to the booth.
Hence the low conversion into a connection: a participant leaves with several business cards, but only a few move into a real conversation. A day after the event, the correspondence fades because the pair had no shared context for a next step — only an exchange of contacts.
AI participant matching changes the principle. Instead of a general list, the system builds a profile of each person: role, industry, current request, format of collaboration, and calculates the closeness of requests between people.
The output is not "everyone with everyone," but ranked recommendations of event participants with an explanation of why a particular pair makes sense.
Below we break down how this works: where request data comes from, how pairs are ranked, how slots, halls, and languages are taken into account — and why a recommendation without an explanation of the reason almost never turns into a meeting.
What changes when the system calculates recommendations
With manual networking, a participant spends the first hour figuring out who in the room is even relevant.
Organizers connect people from memory and based on a line in a list of job titles, so the time to the first useful contact is measured in tens of minutes, and part of the room never finds the right people.
A matching system works differently: the participant's profile is broken down into features — role, tasks for the coming quarter, industries of interest, what the person brings to a conversation and what they are looking for.
The weight of a pair is calculated not by word overlap but by reciprocity: if one person's request includes a task that the other can solve, and vice versa, the pair rises to the top. Recommendations go where the participant actually reads — to Telegram or the event app.
Measurable effects appear already by the second or third round of recommendations.
Time to first meaningful contact drops from an hour to ten to fifteen minutes, the share of mutual recommendations — those where both confirmed interest — grows roughly twofold compared with random introductions, and questions like "who should I talk to?" stop forming a queue at the organizers' desk.
Next, the system is further trained on outcomes: after a meeting, the participant marks whether it was useful, and these marks change the weights at the next event. Curators stop being dispatchers and focus on the program rather than routing people around the hall.
Matching quality is verifiable: you can see how many pairs reached contact, how many remained in correspondence, and at which iteration the output stopped improving.
Matching formats: manual selection, rules, model
The input to a matching system is the participant profile: role, industry, interests, purpose of attendance. The output is a ranked list of contacts with an explanation of why the pair was suggested.
The design of this layer determines how much manual work remains for the organizer and how predictably matching behaves with a new audience.
Rules-based matching is an explicit set of conditions: matching industry, role, geography, stated goals. Rules are transparent and explainable, but rigid filters easily produce an empty list or obvious pairs.
A trainable matching model ranks candidates by actual actions — whom they added to contacts, with whom they returned to a dialogue — and gradually refines the weights.
The hybrid format addresses the limitations of each approach: rules act as a filter and overcome the cold start, while the model handles ranking. Below is a comparison by applicability conditions, not by the "power" of the approach.
Comparison of approaches
| Option | When it fits | Limitations |
|---|---|---|
| Manual selection | Up to a few dozen participants, homogeneous audience | Does not scale, result depends on curator experience and is not reproducible |
| Rules-based matching | Criteria can be formalized: industry, role, geography, purpose of attendance | Rigid conditions produce an empty list; participant behavior is not taken into account |
| Trainable matching model | Many participants and a history of interactions | Requires data and feedback; there is no history at the first event |
| Hybrid format | Large-scale events with varying profile completeness | Requires feedback collection and recommendation quality control |
Practical takeaway: rules are responsible for making sure the list is not empty at all, while the model is responsible for the order within it.
How we implement AI matching: stages of work
Matching does not start with choosing a model, but with what is known about the participant. During data analysis, we look at which profile fields are filled in practice, how many of them are empty or free text, and how questionnaires differ between events. This determines the feature schema and which recommendations are worth building at all.
- Analysis of participant data. We consolidate registration profiles, applications, and contact exchange history into a single table: we calculate field completeness, remove duplicates, and discard values without signal.
- Participant feature schema. We break down the profile into features — industry, role, interests, goals, participation format. We normalize categories to a unified dictionary and free text to numerical representations; for each feature we record its weight and source.
- Matching setup. Constraints filter out clearly unsuitable pairs — role conflict, duplicates, incompatible format. The remaining pairs are scored by features and enter a ranked list with an explanation of what matched.
- Assembly into the event scenario. We distribute recommendations across rounds and groups taking into account the number of participants and time: the load must be spread evenly, without participants who are booked in all meetings.
- Recommendation validation. We run matching against past events where actual contacts are known and compare the share of successful pairs with manual selection — this shows the real gain.
- Handover of the solution. We provide configurations, a description of the feature schema, a dictionary update procedure, metrics, and the procedure for further training on "useful / not useful" marks. The team changes weights and rules without us.
After handover, matching remains manageable: it is clear why a pair was suggested and how the output will change when a feature is adjusted.
What we hand over to the event team after launch
Handover is not an archive with source code, but a working system that the event team uses on its own.
We provide the configured environment, documentation, and procedures, and then conduct acceptance testing on a real scenario: the organizer launches a matching round, checks the recommendation output, and edits weights without our participation.
Anything that remains unclear is recorded as an open handover item, not as "you'll figure it out as you go."
The package includes:
- Matching configuration — which participant features are used in AI matching, with what weights, and how to change them without rebuilding the solution.
- Relationship schema and data model — how profiles, interests, meeting requests, and post-event feedback relate to one another.
- Data visibility rules — what the participant sees, what is available to the organizer, which fields do not leave the closed environment, and how access roles are separated.
- Solution documentation — architecture, integration with registration and the calendar, list of external dependencies, and the procedure in case of failure.
- Team operating procedure — who launches the matching round, when they edit weights, and how they handle a complaint about a poor recommendation.
- Metrics dashboard — share of accepted recommendations, share of meetings that took place, participant coverage by segment.
- Role guidelines — short instructions for the organizer, moderator, and on-site support.
Each item is assigned to a specific role: the organizer configures the same solution, support explains it to the participant, and a technical specialist maintains it.
Therefore, after launch, changes to matching rules and data visibility follow an agreed path rather than being edited in a rush during the event.
Case study: how the number of mutual contacts grew
The organizer of an industry forum with 400 participants came with a typical problem: networking was in the program, but it brought no value.
Coordinators compiled introduction lists manually — it took two days, and still a significant portion of recommendations received no mutual response. People left with business cards and without substantive conversations.
What it was like before
The scheme replicated classic Speed Networking: pairs were linked by job title and industry, without taking into account what each side was looking for at the event.
About a third of the proposed pairs were mutually confirmed, and after the forum contacts almost never turned into correspondence. The organizer could not show partners that the business part of the program actually worked.
What we changed and what happened
We built the participant profile from the application — field, role, tasks for the year, interests — and generated pair recommendations based on them.
A day before the start, a person received a short list of suitable conversation partners and confirmed meetings in one click; a decline was also a signal and refined matching.
Mutual confirmations increased by about 2.5 times, and the share of meetings attended by both sides grew from half to almost nine tenths — the schedule stopped falling apart.
The organizer gained a dashboard with hall load by hour: idle slots are immediately visible, and after the forum there are numbers for reporting to partners. The completed profile carries over to the next event, so the core of participants returns.
How does rules-based matching differ from a trainable model?
Rules-based matching is an explicit set of conditions and weights: industry, role, interests, language, purpose of attendance. Every match is explainable and reproducible — you can see which criteria fired and how many points they contributed.
The downside is that weights are set by a person, and they do not change based on what participants actually choose on site.
A trainable model relies on actual interactions: contact exchanges, repeat conversations, "useful" marks. Data requirements here are strict — you need a volume of profile pairs with a known outcome, otherwise the model finds patterns in noise.
When history is insufficient, it degrades to a heuristic, and the predictability of the result falls.
| Approach | When it fits | Limitations |
|---|---|---|
| Hard rules | First event, no interaction history | Does not adapt to behavior, weights gradually become outdated |
| Trainable model | Interactions accumulated from several events | Sensitive to data volume, weak cold start |
| Hybrid | Events run as a stream | Requires regular error analysis and quality control |
At the start, rules produce even pairs and a clear reason for each match, while a model on scarce data makes mistakes unnoticed by the organizer. Later the picture flips: the more history accumulated, the better the model captures connections that cannot be built into rules.
A workable option is to start with rules and gradually move a share of recommendations to the model.
For profiles with categorical features, we use gradient boosting: CatBoost handles such features without manual encoding and shows the contribution of each factor, so the organizer sees not only the pair but also the reason.
Common doubts before starting a project
Before launch, the same doubts almost always surface: will there be enough data, what to do with empty fields, how to keep matching within a track.
These are exactly the questions that determine whether AI matching will be useful at the second event or remain a nice demonstration.
Below are answers to the point. If something is missing for a specific scenario, it is visible at the design stage, not on opening day.
Profiles are only partially filled in — will matching work?
Yes. Unfilled fields do not block a recommendation but reduce its weight: only what is specified participates in the calculation. The rest is inferred from indirect features — selected tracks, the stated purpose of attendance. The system shows what the matching is based on instead of offering a confident random pair.
How to handle the cold start while there is no contact history?
The first event should not be a blank shot, so the start comes from stated goals and track topics rather than behavior. Then signals are connected: attended sessions, responses to recommendations, mutual contacts. By the second wave, matching already relies on facts, not declarations.
Can recommendations be limited to a track?
Yes, this is a setting, not a separate customization. A pool is defined — track, stream, participation type, role — and matching runs only within it. It can also be expanded: suggest adjacent tracks if there are few matches within one's own.
The threshold for the number of recommendations is also configurable, so that no one leaves with an empty list or a hundred "suitable" people.
Who is responsible for quality after launch?
We hand over the system together with the quality loop: weight settings, feedback labeling, and analysis of why a particular pair was suggested. After launch, we stay in touch — we monitor the share of accepted contacts and adjust weights and rules. The matching logic is on our side; the data and goals are on yours.
Let's discuss the matching task for your event
To come back with an assessment rather than generalities, we need the event context. What already exists in working form is enough: the program with a slot grid, the participant list with profiles, networking goals, and rules about what can be shown to others about a person.
The task review takes one to two business days: we look at where the data comes from, how complete the profiles are, how many meetings per participant are needed, and whether recommendation moderation is required.
Then we assemble an implementation plan with stages, checkpoints, and timelines — we usually come back with it within a week. If there is little data, we will suggest how to collect it during registration so the process does not have to be rebuilt during the event itself.
What to send for an AI matching assessment:
- the program or slot grid — to understand the windows for meetings;
- the registration export: roles, interests, companies — in any convenient format, including a table;
- a description of networking goals: who would benefit from meeting whom and based on what feature;
- privacy rules and what the participant sees about themselves and others;
- examples of mailings and communication channels you already use;
- venue constraints: network access, screens, registration desks, volunteer assistance.
Then we work step by step: clarify requirements, agree on the data schema and recommendation rules, launch a pilot on part of the list, then roll it out to the entire event.
Describe the task in any convenient form — we will come back with an assessment, a plan, and timelines for preparing a proposal.
