Reciprocal matchmaking (event networking, mentoring, B2B partner matching, dating)

At conferences, trade fairs, mentoring schemes and dating apps, a recommendation only creates value if both sides accept it. Reciprocal recommenders score mutual fit, respect capacity limits and spread attention fairly, so that popular profiles are not flooded. Organisers get more and better meetings; participants spend less time searching.

Problem & value

• Today: attendees browse long lists or rely on chance encounters; chambers and mentoring programmes pair people by hand from questionnaires; dating apps rank by attractiveness signals, which concentrates attention on few profiles.
• AI value: better first meetings, less organiser effort, higher satisfaction, and fairer exposure. One-sided ranking (as in REC-008, KNOW-012, KNOW-017, AGENT-008) is not enough, because the best candidate for A may be unavailable or uninterested, wasting both sides' time.
• Evidence: event-matchmaking vendors such as Brella and Grip sell this as a core feature, and business-travel surveys report broad planner interest in AI matchmaking [1][2]. Rigorous, independent uplift numbers are scarce; measure your own baseline.

Variants

• Events and trade fairs: attendee-to-attendee and exhibitor-to-buyer matching with 1:1 meeting scheduling.
• Business cooperation: chambers of commerce and the Enterprise Europe Network match firms for partnering and brokerage events [3].
• Mentoring and buddy programmes: mentor-mentee, onboarding buddies, alumni, language tandems, volunteering.
• Public programmes: start-up support, research-industry brokerage.
• Dating and friendship apps (private use): the most sensitive variant, with special-category data and manipulation risk.

How it works

1. profiles + goals + (offers / needs) + feedback
2. embeddings and structured features (industry, role, language, availability)
3. directional score s(A
4. B) and s(B
5. A)
6. reciprocal combination (e.g. harmonic mean or product, minimum threshold on both)
7. congestion and fairness control (capacity caps, exposure re-ranking)
8. assignment / scheduling (matching with time slots)
9. invitations
10. accept / decline feedback
11. model update

• Directional scoring: text embeddings of free-text goals and bios, plus a gradient-boosted or two-tower model trained on past accepts. LLMs generate short "why you match" explanations and can normalise messy profiles; they should not decide the match alone.
• Reciprocity: combine both directions so that a one-sided strong signal does not produce a match the other side would reject.
• Congestion and capacity: treat it as an assignment problem (bipartite matching, optimisation solver) with limits on meetings per person, table slots and mentor hours.
• Human-in-the-loop: organisers set rules and review edge cases; participants can edit profile data, decline, and opt out of being recommended.

Data preparation

Needed are participant profiles (role, interests, goals, offers and needs), registration data, availability and capacity. They typically sit in the registration tool, a CRM or membership database, Excel lists and e-mail replies; for internal mentoring also in the HR system.

Typical gaps: free-text profiles that are short or vague, duplicate registrations, no structured fields for "I offer / I look for", missing consent for profile sharing, and outdated membership data.

Preparation steps: redesign the registration form with a few structured choice fields plus one free-text field, deduplicate and standardise company and job titles (PREP-011), agree a small category scheme for topics (PREP-019), and record consent for sharing profiles (PREP-025). Capture accept and decline signals from the first round as feedback (PREP-021). Tools are the registration platform's export, a spreadsheet and optionally OpenRefine for cleanup.

Effort share is low, about 10 to 20 percent, mostly the form redesign. Sensitive attributes should not be collected unless strictly needed; pseudonymise exports used for testing (PREP-022).

Implementation paths

Which path for whom

• SMB: A. Event, mentoring and matchmaking platforms with built-in matching are mature, EU-hostable and affordable for chambers, associations and organisers.
• Enterprise: B. Internal mentoring or partner matching must tie into HR or CRM data and identity systems, so a build on cloud APIs with embeddings and an optimiser fits better.
• Developer: C. Embeddings, a vector database and a solver (e.g. OR-Tools) run self-hosted on modest hardware and avoid sharing participant profiles.
• Public: C. Programmes of public bodies, universities or chambers favour self-hosted or sovereign EU cloud for participant data and procurement rules.
• Private: A. Dating, community and networking apps already deliver the matching; no own build is worthwhile.

Path A — Buy (recommended for most organisers and private users)

• Event platforms with AI matchmaking: Brella (Finland, EU), Grip (Netherlands, EU), Swapcard, Bizzabo, Cvent, Hopin-style suites; B2B brokerage tools used within the Enterprise Europe Network [1][3].
• Mentoring software: Chronus, MentorcliQ, PushFar (UK), Together; many HR suites include mentoring modules.
• Dating: consumer apps are closed products; building one is a Path B/C topic.
• Choose A when: event or programme is time-boxed, volumes are hundreds to tens of thousands, and organisers need scheduling, app and badge integration rather than a custom model. Check EU hosting, data processing agreement, and the opt-in design.

Path B — Build on cloud APIs

• Embeddings: EU-provider or EU-region embedding APIs (e.g. Mistral Embed, Azure OpenAI in EU regions, Vertex AI in EU locations); store vectors in Qdrant or pgvector.
• LLM layer: a frontier or EU model for profile cleanup, interest extraction and match explanations, using structured outputs.
• Scheduling: Google OR-Tools CP-SAT or a similar solver for meeting slots [4].
• Choose B when: you run recurring programmes and want custom rules and your own CRM or ticketing integration.

Path C — Self-host (open source)

• Embeddings and rerankers: BGE-M3 (multilingual) and open rerankers via sentence-transformers [5]; small open LLMs (Mistral, Qwen, Llama class) for explanations.
• Stack: Qdrant or pgvector, LightFM / implicit / RecBole for collaborative signals, OR-Tools for assignment, n8n for workflows.
• Hardware: HW1 suffices for profile embeddings of tens of thousands of people; HW2 if you also run a local LLM.

Path D — Custom training

Worth it for large consumer platforms with millions of interactions: two-tower or graph neural networks trained on mutual accepts, with bandit exploration to cold-start new users. Needs many labelled accept/decline outcomes; most event and mentoring programmes lack that volume.

State of the art (2026)

• Reciprocal recommender research treats the problem as predicting mutual interest, using combined directional scores, then correcting for congestion; recent work adds embeddings, LLM-based profile understanding, and fairness-aware re-ranking [6].
• Typical production recipe: embedding retrieval, learned re-ranking, assignment optimisation, explanations by LLM, and bandit feedback.
• Limits and failure modes: cold start (new attendees with empty profiles), self-reported goals that do not predict real interest, popularity concentration, popularity bias reproducing demographic bias, no-shows, and explanations that sound plausible but misdescribe the other person. Stated preferences often differ from revealed behaviour, especially in dating.

Shared resources & combinations

• Same stack (recommender, embedding-text, vector-db): REC-008 job recommendations, REC-010 B2B recommendations, REC-004 segmentation, KNOW-017 funding and tender matching.
• Combines with: KNOW-012 expert finding, AGENT-008 candidate matching (note: HR selection is high-risk), calendar and scheduling agents, and event communications.
• Vector index and embedding service can be shared across programmes.

Effort, cost & KPIs

• Path A: days to weeks, per-event or per-seat subscription pricing.
• Path B: 1-3 months including integration and consent flow.
• Path C: 2-4 months; small server plus operations.
• Path D: quarters, specialised team.
• KPIs: meetings accepted and held, mutual-accept rate, no-show rate, post-event satisfaction, exposure inequality (Gini of recommendations received), time to first meeting, programme retention.

People & change

Involve the programme or event lead as process owner, management for the goals (fairness, number of meetings), IT for registration and identity integration, the DPO for consent, profile sharing and any special categories (especially in dating), and participants themselves, who must understand and trust how matches arise. Customers here are the participants.

Works council: depends. For events and member networks it is usually not involved. For internal mentoring, partner matching of employees or HR use, it applies: section 87(1) no. 6 BetrVG if the system logs or evaluates employee behaviour, section 90(1) no. 3 for information on AI-supported processes, and section 95(2a) if matching feeds selection or staffing guidelines. Public bodies involve the staff council.

Data protection: profiles are personal data; AVV with the platform vendor, DPO review and a DPIA if profiling is extensive or sensitive. Matching that decides on employment access may touch AI Act high-risk rules, see GUIDE-014.

AI literacy: support organisers with a short briefing on bias and popularity effects (GUIDE-006). Run a pilot with one event or mentoring cohort, let people opt in and out, explain why a match was suggested, and keep the organiser able to override pairings. Concerns about privacy and fairness are addressed by transparency and opt-out. See GUIDE-008, GUIDE-009 and GUIDE-005.

Risks, regulation & compliance

• EU AI Act: usually minimal for events and mentoring. Becomes high-risk if used for employment-related selection (Annex III, e.g. recruiting or allocating work opportunities) or for access to education or essential public programmes. Art. 5 prohibitions to avoid: manipulative or deceptive techniques that distort behaviour and cause significant harm (relevant for engagement-maximising dating apps), exploiting vulnerabilities of age or disability, and emotion recognition in workplace or education settings. Chatbot-style profile assistants need Art. 50 transparency [7].
• GDPR: profiles are personal data; legal basis normally consent or contract. Dating data can reveal sexual orientation, a special category under Art. 9, requiring explicit consent. Share contact details only after mutual accept; provide opt-out, deletion, and data minimisation; a DPIA is advisable for dating and large-scale profiling [8].
• DSA/platform duties: dating and community platforms face notice-and-action and minor-protection duties.
• Other risks: discrimination through proxies (age, gender, nationality), harassment and romance scams on dating apps, unwanted exposure of attendee lists, stalking via shared attendance data.
• Mitigations: opt-in visibility, exclusion of protected attributes from scoring, exposure caps, fairness audits, reporting and blocking tools, human organiser review.

Getting started

1. Define the match goal and success metric (held meetings, mentoring completion) and gather a baseline.
2. Collect minimal profile data with explicit consent; ask for offers and needs, not only job titles.
3. Pilot a Path A tool or a simple embedding-plus-rules prototype at one event.
4. Add reciprocal scoring, capacity caps and accept/decline feedback, then audit exposure fairness.
5. Do a DPIA and AI Act classification check before widening scope, especially if used for HR or dating.

Sources

1. Brella — AI-powered event networking and matchmaking — https://www.brella.io
2. Grip — event matchmaking — https://www.grip.events
3. Enterprise Europe Network (European Commission) — https://een.ec.europa.eu
4. Google OR-Tools — https://developers.google.com/optimization
5. BGE-M3 multilingual embedding model — https://huggingface.co/BAAI/bge-m3
6. Reciprocal recommender systems literature overview (RecSys / arXiv search) — https://arxiv.org/search/?query=reciprocal+recommender+systems&searchtype=all
7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
8. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj