会议上的商务配对怎么做？

问题到底是什么

参会人看不出谁值得花时间。胸牌上只有名字和公司，不会告诉你两米外那个人正要买你卖的东西。商务配对首先是信息问题，其次才是软件问题。

失败有两种，解法正好相反。第一种，几乎没人认识新的人：工具在那里，资料是空的，名录只是一串名字。第二种，配对效果够好，于是每一条请求都发给了同样的二十个人，其余的人得出结论：这场活动不是为他们办的。

三种配对方式，以及每种要你付出什么

多数会议想要第二种，默认得到的是第一种，却向赞助商承诺了第三种。在写进招展书之前，先想清楚你实际做的是哪一种。

「AI 配对」：先问输入是什么

把两个人配在一起，就是拿一个人能提供的，和另一个人想找的作比较。只要双方都是从你定义的清单里选的，这个比较就是一条规则，不管功能叫什么名字。按钮上的标签改变不了底下的机制。

这一点要紧，是出于实际原因，不是讲道理：规则可以解释、核对、纠正；说不出理由的排序不行。问每家厂商一个问题：输入是什么，参会人能不能看到自己为什么被推荐？ 如果答案是一份由你维护的主题清单，以及每张卡片上的一条理由，那你看到的就是规则。如果没人说得出某条推荐为什么出现，你就没法向收到糟糕推荐的参会人解释，也没法改。

语言模型在外围工作确实有用：整理某个人匆忙填写的资料，或者把自由填写的职位对应到你的角色清单上。那是在准备输入，不是在做配对。

决定一切的输入：一份主题清单

如果商务配对的做法里只能改一件事，就改这一件。双方用同一套词回答，配对才行得通；各写各的，配对就垮了。

一份清单，问两次

同一份清单同时回答「我能提供什么」和「我想找什么」。用两份清单，它们会越走越远，对不上。

短到能读完

要长到能区分同一类别里的两家公司，又要短到没人划到一半就放弃。按你的参会人群来写，不要照搬一套行业分类。

用他们自己的说法

用参会人对这些东西的叫法，不要用你的 CRM 里的叫法。一份没人看得懂的清单，只会被随便勾选。

报名一开放就不再改

之后再加主题，会把回答分成两截：早报名的人没见过新主题，所以永远不可能按新主题配上。

在哪里问，是另一个决定。报名表是唯一能让所有人都认真看的时刻，但它也是你想尽量做短的那张表。下面那篇表单设计指南有一条规则，用来判断哪些问题值得放进报名表，哪些该留到后续再问。

写明哪些角色应该见面

如果只看共同主题，系统会毫不犹豫地把两家供应商互相推荐。双方卖的是同一样东西，标了同一个主题，谁都不想见这一面。

• 用你的参会人的说法，给这场活动的角色命名：买家和供应商、投资人和创始人、临床医生和研究者，现场实际有哪些人就写哪些。
• 明确写出该见面的组合。 你没写下来的组合，工具没有理由优先推荐。
• 排除同事。 同一家公司的两个人不需要引荐。推荐列表里全是同事，是最快失去参会人信任的方式。
• 如果同一角色之间确实该见面，就允许。 两位临床医生常常确实想见面；负责同一片区域的两个经销商则不想。这要按你这场活动的情况判断，不是默认设置。

授权是机制的一部分

名录就是某一场具体活动上的一份实名名单，在任何人互发消息之前，它就已经是个人数据。最要紧的是三个决定：

• 列入名录靠自愿，不靠默认。 自愿加入得到的名录更小，但里面都是愿意被找到的人，这也是一份更好的名录。自动列出所有人，换来的是投诉和更差的效果。
• 联系方式只在对方接受后才交换。 名录里的卡片可以显示名字、角色和公司，而不显示邮箱。参会人同意的，是这一次交换本身。
• 隐藏就是双向隐藏。 不加入名录的人，也不该能浏览名录。否则不加入就成了一种惩罚，人们会出于错误的原因又加回来。

在收集信息的当下就说明每个回答谁能看到，并且不要让配对用的回答出现在给赞助商的导出里。你的合法依据是同意还是别的，要问你自己的律师。这篇不回答这个问题。

建立联系不等于见上面

接受一条请求，只是两个人原则上同意见面。多数社交工具到这里就停了，多数引荐也到这里就没了下文。一次会面要有时间、时长和地点。

双方都有空的时间

空闲时间应该从每个人收藏的场次里算出来，而不是靠另一份没人会填的日历。只显示某个时段有空，不要显示其他时段排了什么。

事先定好的时长

要短，而且固定。没有约定结束时间的会面，会拖进下一个场次，两个人都会怪这场活动。

一个说得出名字的地点

「2 号厅某个地方」只会让人找不到对方。给洽谈桌编号，并且在承诺这个功能之前，先数清楚你有几张桌子。

体面的拒绝方式

拒绝要和接受一样容易，并且可以提议换一个时间。否则人们干脆不回复，看起来就和功能坏了一模一样。

没人提前考虑的负荷问题

配对做得好，请求就会集中。最有名的讲者、最大的买家、最显眼的供应商，收到的请求会远远超过他们能接受的数量。请求没得到回复的人，都会说商务配对没用。

• 限制每人能发出的请求数。 有了上限，人就得挑选，而挑选过的请求比群发的请求更容易得到回复。
• 按匹配度排序，不按受欢迎程度。 如果推荐列表实际上是一张排行榜，它每过一小时都会让集中的问题更严重。
• 刷新推荐。 第二天早上打开列表的人，不该看到已经发过请求的那同样六个人。
• 提前告诉会被约爆的人。 如果你在开场之前而不是之后提醒，讲者和重点展商可以预留一段时间，或者关闭请求。

看覆盖面，不看总量

会面总数这个核心数字容易报告，却几乎说明不了什么。有三个比率能告诉你配对有没有用，其中第三个最说明问题。

# 参与率  =  自愿加入的参会人  ÷  已签到的参会人
# 接受率  =  被接受的会面  ÷  发出的会面请求
覆盖率  =  至少有 1 次被接受会面的参会人  ÷  自愿加入的参会人

总量高、覆盖率低，说明一小群人见了所有人。这是第二种失败，只是包装成了好结果。接受率低、参与率高，通常说明主题清单太粗：把人互相推荐的理由是对的，但没什么意思。

每家厂商都问同样的问题，包括我们：输入是什么、每条推荐是否附带理由、联系方式什么时候交换、选择不被列出的人会看到什么。