如果你拆解一下食物配送的这个事，其实它分成了两部分体验。第一部分是：选择一家餐厅（搜索），第二部分是从菜单中选择食物。如果对于个人来说，这是非常容易办到的事。你知道你喜欢什么，当天的感觉如何，从菜单上选什么来吃简直就是小菜一碟。

　　但是如果出现下面的问题呢？

　　如果是一个团体来点餐，会出现什么情况？更具体点，如果是一个团体在叫午餐，会发生什么？谁来选择餐厅？谁来给大家派发这个菜单？

　　Kip 采取了一反往常的做法，没有在某家特定的餐厅去寻找你喜欢的吃的，而是它会去寻找一家餐厅，这家餐厅里面包含了你团队所有成员都喜欢的吃的。

　　也许你身边有一个同事对某些食物过敏，一吃就会有生命危险，又或者你的同事是一名素食主义者，或则因为宗教等原因不吃大肉。

　　这一切都不是事儿。Kip 会把你们每一个人的偏好全部记住，从某个区域中挑选出来一家不踩在任何人「口味禁忌之地」的餐厅，然后更关键的是，给每一个人发送一份特别定制的菜单供其挑选。

　　来，让我们再用刚才的问题对这个项目做一个判定：

　　这个事情是不是只有 Kip 能做？有没有其他的解决方案成为 Kip 的可替代选项？

　　如果是在手机应用中干这件事呢？

　　因为都是各自为战，它们之间是不可能出现什么交互的。而 Bot 的妙处就在于它能够轻松实现横跨多个平台进行数据的传递和交互。如果一个人在是在 Slack 上，atv，第二个人是在 上，第三个人他只用收发邮件。Kip 可以让这三个人同步共享信息，而这是应用没有办法做到的事。

　　如果是让网页来做这件事呢？

　　这会花费好长好长时间，因为网页需要给每一个人浏览，如果你是在Seamless、Grubhub、DoorDash 等网站上创建账户，其实就只能由一个用户来管理。这个人必须询问每一个人要吃什么，然后清点结果，最后在菜单上面截屏生成图片，黏贴到对话框，然后点餐。

　　在为 Café 进行了多项测试之后，我们意识到了自己是可以开发出一款非常强大、实用的 Bot 产品来的，按照上面的思路，它其实能用于多个行业。在经过审慎考虑之后，我们最终决定将「团队搜索共识引擎」申请为专利技术。

　　只有这样，才能在如今不断升温的 开发领域突出重围，而接下来，我们还会抽时间具体说一下 Café 的设计细节和操作流程，它是怎样服务于一群人的。