很偶然的机缘，想起并翻到将近三年前一个系列邮件，当时在工作转换过程中，和3个好朋友做了一阵子微信公告号的聊天比价，正好回顾一下。
流程方面，首先关注公告号；
其次，在输入框里打类似“上海“ ，”入住日期”，信息正确识别的话，返回1个大图带3个酒店的多图文信息；
点击大图到列表页（点击酒店直接到详情页），列表页是上海的10个酒店
点击进详情以后，内容是基本位置信息，以及在3个主要ota上的价格、评分。
当时有考虑了如下几点所谓的产品调性和特质。
1、场景是什么
既然是手机，是专门用来定今夜酒店么？
可否在别处已经订好酒店的情况下，转发确认邮件，然后公共号可以随时查几个可替换的酒店，相当于截单？（截单这个玩法在创业领域很常见，房产网站就有不做前面生意专门截单的）
2、移动搜酒店，那么和app搜酒店的区别是什么
多家比价和比评论，后续问题是那么和马蜂窝的区别是什么，回答是移动化和推荐。
3、推荐是特色，那么推荐依据是什么
微信是可以获取位置的，首先是位置远近。
其次是抓取几个ota上的评分和排序，黑盒用别人的排序。
带上纯点评（不能订）网站的打分。
如果是曾经用过的客人，输入过的、点选过的偏好是最完美的，不过冷启动无法避免。
4、卖点是什么
除了微信号的便捷，期望能推荐到客人偏好，减少对比的时间成本。
所谓偏好依重要度高低为：
价格、距离、灵活取消需求、星级，wifi，早餐，禁烟，宠物，其他
引导客人输入需求很关键，比如说，明天 上海 五星级酒店 带早餐 有wifi，第二次操作会非常爽，偏好已经影响了推荐。
当时遇到的困难
首先还没有分词、大数据的概念（甚至想过要注册帐号留历史信息，现在看来，对机器学习来说毫无必要）；
其次相当于一个小型meta search的后台需求，相对于业余尝试来说，过大（其实都没有到考虑变现的阶段，哪怕是资深玩家，做这类产品最后变现都成了另类分销，毫无悬念）；
最核心的问题可能是实际上没有很好自圆其说的卖点；
最后是微信公告号输入信息的交互模式并没有多少用户买账，测试都无法很好进行下去。
后来
种种因素最后也没有继续，现在回头看看，即便换上现在的交互更灵活的小程序，换上更充裕的开发资源，和更多的数据玩法积累，旅行比价和内容推荐定位的狭窄、尴尬，和推广冷启动的困难仍然巨大。
anyway，仍然是非常棒的回忆，觉得很值得记录，以此留念。
