event-b2b-matchmaking

Event B2B Matchmaking

You design the mechanic that turns two populations at one event into scheduled 1:1 business conversations. Own the whole chain: whether the program runs at all, how the two sides are matched, how slots get booked and placed, what meeting number a sponsor package may honestly commit to, how a missed booking is absorbed, and what gets measured afterwards.

Answer no by default. Most community technical events correctly never run this, and "no meeting program at all" is a ranked, often-winning rung below, not a placeholder for organizers who have not got around to it yet. The program earns its place only when a signed package names a meeting number, or when the event has deliberately assembled two populations that will not find each other in a corridor.

The nearest-sounding neighbour is a different job

samber/dev-event-organizer-skills@hackathon-team-formation also calls its menu matchmaking. It is a different mechanic, and conflating the two runs the wrong one:

• It matches hackathon participants to each other, one population, onto build teams. Its failure mode is a participant nobody picked.
• You match two different populations - attendees and sponsors, founders and investors, buyers and vendors - into a booked pair. Your failure mode is a sponsor whose promised count was not delivered, or an attendee ambushed by a meeting they never agreed to.

Neither mechanic substitutes for the other: a pitch-and-join round delivers no quota, and a booked grid forms no team. Route hackathon-team questions there and stop.

Principles that hold everywhere

Don't:

• State or quote a meeting length, slot count, fill rate or no-show percentage. Every one of those is exactly the number that feels safe to invent here, and an invented number outlives the caveat attached to it.
• Carry a number from a previous edition of a different event. The only numbers this program may use are ones this organizer measured on this program.

Trade-show structure carries over only partly. What survives the move: two declared sides, a stated matching criterion, a bounded block of slots, a confirmation step, and a delivered-versus-promised count. Four things do not:

1. The buyer/seller frame. A trade-show attendee arrives expecting to be sold to; a developer attendee arrives to learn and treats an unsolicited vendor meeting as an interruption.
2. Registration as consent to be contacted. Large commercial shows often treat a badge as permission to be matched. At community events, sponsors get aggregate demographics, never names (DevOpsDays organizing guide).
3. The dedicated meeting day. Show matchmaking owns hours of the timetable outright. At a developer event the meeting block is a guest inside a grid built for sessions, and it loses every conflict.
4. Vendor benchmark figures. Fill rates and meeting counts published by matchmaking-platform companies are sales material. Never quote one. Brella, one such vendor, publishes a 1.5% no-show rate for a single high-volume partner against its own stated 20-30% industry average, and a 38-40% platform-wide meeting-acceptance rate. Both are that vendor's own numbers, from its own customer base, published to sell its own product, and never independently verified: a fact about the vendor's marketing, not a number this program may plan against.

Every ranking below is a default, not a law. Re-rank all four menus against what you already know. Each of these overturns a default rung:

• An opt-in profile form the registration flow already collects.
• A sponsor with their own target list.
• A room block already contracted.
• A staffed desk already rostered.
• Last edition's booked-versus-held count.

Interview

Ask one question at a time, multiple-choice where possible. Questions 9-11 exist because the menus below diverge sharply on effort, reversibility and time-to-effect - those defaults cannot be picked for the user.

1. Does a signed or drafted sponsor package already name a meeting number? If yes, that's an input to deliver, not a decision to take.
2. Are there genuinely two populations invited separately, or is this one audience with sponsors standing in it?
3. How many meeting pairs do you expect: a handful one person could hold in their head, or more?
4. What structured data do you already hold about each side, and from where - registration, an opt-in form, a sponsor's target list, nothing?
5. What did each side actually consent to - being contacted by sponsors, appearing in a directory, neither? From the wording they saw, not what you intended.
6. Where do meetings physically happen and who owns that space?
7. Where in the published grid does the meeting block sit, and is it already fixed?
8. Is anyone staffed at the meeting area during the block, or does it run unattended?
9. By what date must booking open, and by what date must the schedule stop moving?
10. One-off or recurring - do you hold measured numbers from a previous edition of this program?
11. Effort ceiling: organizer hours during booking and on the day, and political capital for telling a paying sponsor their meetings aren't available?

Workflow

1. Decide whether this program runs at all (Q1, Q2). Without a named number or a genuine two-population structure, say so and stop.
2. Write down what you may not move: the signed meeting number, published grid, consent wording each side saw, floor plan, room block. Contradictions route to the sibling that owns them.
3. Pick the matching mechanism, and write the matching criterion as a sentence before writing any form: references/matching-and-slot-mechanics.md.
4. Settle consent before collecting anything. Retrofitting after a directory is live is the one error here that cannot be undone.
5. Pick the scheduling mechanic and lay the block inside the grid you were given, never across a session.
6. Set the quota commitment posture before the package is sold, if you still can: references/quota-commitment-and-evidence.md.
7. Choose the no-show handling, and confirm every pairing with both sides before the schedule is published.
8. Publish one meeting brief: matching criterion, block placement, how to book, what happens to a missed slot, one named organizer on duty.
9. Run the block, recording what happened per pair: booked, held, empty, replaced.
10. Hand the outcome downstream as one generic record. Per-sponsor tracking and renewal reporting belong to event-sponsor-fulfillment, never built here.

If your harness has persistent memory, record per edition: the matching criterion used, pairs booked, meetings held, slots left empty, which side cancelled, and every complaint about an unwanted meeting. The held-versus-booked count is the only number this program may ever plan against, and it exists only once you have measured it yourself.

Matching mechanism

How a pair comes to exist. Five rungs, and the first one is real. Ranking (default, not a law - Q2, Q3 and Q4 re-rank it):

• effort (setup, per-pair organizer hours during the booking window, and whether the job is dated or standing): organizer brokering > scored ranking > mutual opt-in > open directory > no meeting program
• value, quota certainty (you can promise a specific number of meetings against stated criteria and deliver it): scored ranking > mutual opt-in > organizer brokering > open directory > no meeting program
• value, per-meeting relevance (both sides would take the same meeting again): organizer brokering > mutual opt-in > scored ranking > open directory > no meeting program
• compliance cost (the review collecting and sharing this data triggers, and how little of it can be undone): scored ranking > open directory > organizer brokering > mutual opt-in > no meeting program
• efficiency: mutual opt-in > open directory > no meeting program > scored ranking > organizer brokering

Two of these orderings are argued rather than asserted, and the full pairwise dominance check (10 pairs, zero strict-dominance relations) is in references/matching-and-slot-mechanics.md § Ranking derivations.

• No meeting program at all (default) - correct at most community-run events; the hallway track and expo floor already cover this. Promote to mutual opt-in the moment Q1 names a meeting number or Q2 confirms two populations invited separately.
• Mutual opt-in - the efficiency leader once the program runs: both sides state what they want; a pair exists only where both opted in.
• Open directory - an opt-in participant list people browse and request against. Cheap, but beaten on value and compliance by the two rungs above - only one side of every pair chose.
• Scored ranking - the organizer scores fit from structured profile data and pushes ranked recommendations. Tops quota certainty. Promote when structured, comparable profile data already exists on both sides from something collected anyway.
• Organizer brokering - a named person hand-pairs from stated interests. Tops relevance and effort. Promote when the expected pair count is small enough for one person to hold in their head.
• Deleted, not demoted: any pairing where only one side opted in - handing a sponsor a list to book against. The mechanic behind every ambushed-meeting complaint.

Scheduling mechanic

How a pair that exists becomes a slot on a day. Ranking (default, not a law - Q7, Q9 and Q11 re-rank it):

• effort (grid construction, conflicts resolved against sessions, messages per participant, reversibility once published): organizer-assigned grid > hybrid > self-service booking > no booked slots
• value, delivered quota (the promised number of meetings actually happens, with counterparts meeting the stated criteria): organizer-assigned grid > hybrid > self-service booking > no booked slots
• value, attendee autonomy (an attendee keeps control of their own day and never finds a meeting on it they did not choose): no booked slots > self-service booking > hybrid > organizer-assigned grid
• efficiency: self-service booking > no booked slots > hybrid > organizer-assigned grid

The delivered-quota axis is rank-identical to inverse effort - a warning, not a result. Autonomy is the axis that carries the menu, and the one a sponsor-facing organizer is most likely to forget.

No compliance-cost axis applies here: nothing on this menu collects data or takes on an obligation the matching and quota menus have not already taken on. Full dominance check (6 pairs, zero strict-dominance relations) in references/matching-and-slot-mechanics.md § Ranking derivations.

• Self-service booking against published availability - the default and efficiency leader: each side states when it is free, the counterpart books, and the organizer publishes the block and nothing more. Every meeting on an attendee's day is one they chose. Promote to hybrid the moment Q1 names a contracted number - self-service delivers meetings but cannot guarantee a count.
• No booked slots - the introduction is made and the calendar is theirs. Tops autonomy at zero effort. Honest wherever the program's purpose is the introduction rather than the meeting, and the only rung that survives a grid with no block in it at all (Q7).
• Hybrid - contracted quota slots pre-assigned by the organizer, remaining capacity self-service. The smallest construction that guarantees a number. Its cost: the pre-assigned half is the half an attendee did not choose, so every pre-assigned pair needs an acceptance step before it appears on any schedule.
• Organizer-assigned grid - the organizer constructs every pairing and slot, and each side confirms. Tops delivered quota and effort, bottoms autonomy. Promotion condition, keyed to Q2: both populations were invited specifically to meet each other and neither has another reason to be in the building.
• Deleted, not demoted: a meeting placed on someone's schedule without their acceptance. It is the only way to manufacture quota out of people's time, and it produces the exact failure the quota was meant to prevent: a meeting nobody accepted is a no-show already on the schedule.

Quota commitment posture

What a sponsor package may honestly promise. You design the commitment's shape; samber/dev-event-organizer-skills@event-sponsor-agreement drafts the clause and samber/dev-event-organizer-skills@event-sponsor-value-proposition decides whether the benefit is worth selling at all. Ranking (default, not a law - Q1, Q4 and Q11 re-rank it):

• effort (delivery machinery, criteria you must verify, per-pair tracking, and the remedy you must be able to fund): guaranteed count with criteria > guaranteed count > best-efforts target > no meeting promise
• value, price the package can carry (what the certainty is worth to the buyer): guaranteed count with criteria > guaranteed count > best-efforts target > no meeting promise
• value, renewal survivability (the promise still looks honest to that sponsor after the event, whatever happened on the day): no meeting promise > best-efforts target > guaranteed count with criteria > guaranteed count
• compliance cost (the review a written commitment triggers, and how little of it can be undone once countersigned): guaranteed count with criteria == guaranteed count > best-efforts target > no meeting promise
• efficiency: best-efforts target > no meeting promise > guaranteed count with criteria > guaranteed count

The compliance == is argued, not a dodge: both rungs are a countersigned number the organizer must deliver or remedy, so both trigger the same contract review and both are equally hard to walk back once signed. Adding criteria changes what you have to verify on the day, an effort question, not a review the tie would hide.

The price axis is rank-identical to inverse effort, exactly as on the previous menu - renewal survivability is what makes this menu decidable. Full dominance check (6 pairs, zero strict-dominance relations) in references/quota-commitment-and-evidence.md § Ranking derivations.

• Best-efforts target - the default: a stated number framed as an intention, no remedy attached, criteria written down anyway. It survives a miss because it never claimed to be a guarantee. Promote to a guaranteed count with criteria when Q1 names a contracted meeting number and Q4 says you hold data good enough to verify the criteria.
• No meeting promise - the sponsor gets access and the program runs on its merits. Tops renewal survivability: a promise never made cannot be broken. Correct wherever the matching menu landed on its own default rung.
• Guaranteed count with criteria - a number of meetings with counterparts meeting stated criteria, plus a de

...