For organizers pairing two populations at one event
Meet Match1:1 meetings at your event, matched honestly and booked without collisions.
Enter the two sides you would pair, what each consented to, the meeting block in the published grid and any meeting number a sponsor package already names, and get - free in your browser, in the order the skill sets - a decision on whether to run 1:1 meetings at all, the consent gate, the matching mechanism with its criterion written as a sentence, a booked timetable that never double-books or crosses a session, the quota a package can honestly commit to and the no-show handling; then the one meeting brief to publish and the confirmations to send each pair. Answer no by default: developer attendees are not buyers, registration is not consent, and the meeting block is a guest in the grid. It never quotes a vendor or platform benchmark, never invents a person, an organization, a slot, a fill rate, a meeting count or a consent, hands per-sponsor tracking to sponsor fulfillment as one generic record, and labels every number of its own self-set.
The event free
Blank means today.
Sponsors and attendees, founders and investors, vendors and buyers.
The interview free
The skill's eleven questions, word for word
- 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.
- Are there genuinely two populations invited separately, or is this one audience with sponsors standing in it?
- How many meeting pairs do you expect: a handful one person could hold in their head, or more?
- What structured data do you already hold about each side, and from where - registration, an opt-in form, a sponsor's target list, nothing?
- 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.
- Where do meetings physically happen and who owns that space?
- Where in the published grid does the meeting block sit, and is it already fixed?
- Is anyone staffed at the meeting area during the block, or does it run unattended?
- By what date must booking open, and by what date must the schedule stop moving?
- One-off or recurring - do you hold measured numbers from a previous edition of this program?
- Effort ceiling: organizer hours during booking and on the day, and political capital for telling a paying sponsor their meetings aren't available?
Q5 per person is the consent column in card 3; Q7's block is card 4.
Only counts you measured on this program - never another event's.
The two sides free
The number is copied from the package as drafted or signed - the page never invents one. Blank availability is the whole block.
Write what each person consented to from the wording they saw. A directory listing or a registration is never re-purposed into matching - those people are excluded and counted.
The block, the criterion and the package free
Yours, from the block and the pairs you have - the page states no number.
The grid belongs to schedule design: the page lays no slot inside a session and never moves one.
The program, worked out free
What the page flags
Run it at all, and what may not move
The consent gate - settled before anything is collected
The matching mechanism - re-ranked, deleted rungs struck - and the criterion
The scheduling mechanic and the block inside the grid
The timetable - no person or table double-booked, no session crossed
Changed since the saved copy - which invites to re-send
The quota commitment posture - what a package can honestly hold
No-show handling and what gets measured
The files free
The timetable as a spreadsheet and a calendar (one event per pair, pending both acceptances), the unplaced pairs, the one generic outcome record to fill in during the block, the brief's skeleton and everything the page worked out.
The design metered
Pricing as soon as the session is ready...
Sign inThe reply could not be read. Here it is as it came back:
Caveats
The page's check of this reply
Saved meeting programs
How it works - and what is sourced
The order is the skill's: decide whether the program runs at all (Q1, Q2) and stop when it does not; write down what may not move; pick the matching mechanism and write the matching criterion as a sentence before any form; settle consent before collecting anything; pick the scheduling mechanic and lay the block inside the grid you were given, never across a session; set the quota commitment posture before the package is sold; choose the no-show handling and confirm every pairing with both sides before the schedule is published; publish one meeting brief; record per pair booked, held, empty or replaced; hand one generic outcome record to sponsor fulfillment. The nearest-sounding neighbour, hackathon team formation, is a different job and is routed there.
Sourced from the skill and its references: the eleven questions, the four menus with their rankings, promotions and deletions (one-sided pairing, an unaccepted meeting on a schedule, a bare prospectus number, overbooking without a measured count, an attendee-side penalty), the criterion's shape, the consent wording checklist, the slot-block construction, the commitment shapes, the make-good rules, the brief, the outcome record and the counting rules. The page's own, said wherever used: a pair needs side B's opt-in, both consents and at least one shared tag, ordered by the count of shared tags; slots wait out a session plus one buffer; feasible is the slots a sponsor is free in capped by its counterparts; named numbers are served first, then open capacity round-robin; and these self-set lines - at most 20 timetable rows and 10 unplaced rows go to the run (the CSV holds all), booking within 14 days is soon, a 40-word summary and at most 5 caveats. Never stated at all: a slot length, a fill rate, a no-show or acceptance percentage, a meeting count from another event.