江阴帮
穷游行程助手产品经理梅子说，做这个产品的初衷是看到论坛上有用户会上传自己的行程，还有更多的用户在评论里“跪求行程”，那时候用户用word或者excel做行程，整个过程中要无数次翻墙搜Google map，漫天找攻略。梅子觉得这是种需求，也许值得做个产品，但最初整个团队其实很不确定。
和今天的行程助手类产品相比，这款产品在框架上并没有太多特别之处：选定目的地，添加目的地内部的城市、游玩时间、游玩景点、住宿和餐饮，补上目的地小交通和一些其他细节，最后打包生成行程。
用户既可以在PC端网页上设计行程，然后同步到app，也可以直接在app上完成行程设计。在我看来，这个产品有这么几个亮点：
- 基于用户数据的目的地：在很早版本的穷游论坛上，就有基于POI的“去过”和“想去”功能，这个数据积累为行程助手提供了帮助。在每个目的地和当地的大部分POI，行程助手可以用一个百分比展示这个景点在用户心中的受欢迎程度，例如去日本的87%都会去京都，去伊斯坦布尔必去蓝色清真寺。此外，在目的地小交通上，行程助手也会展示多少人搭乘飞机、多少人搭乘火车，单程所需时间等诸如此类。
- 基于用户数据的行程调整：行程助手有智能调整行程的功能，这套智能调整除了基于地理位置的相互关系之外，还会考虑其他用户历史习惯，例如用户去了景点A之后，有较大概率会去附近的景点B，那就会智能推荐的行程就会把B放在A的后边。
- 问路卡：用户选定一个POI（餐馆、景点等）后，产品可以展示它的当地语言，并在屏幕上变成一张卡片，用户可以直接拿着手机屏幕去找当地人问路。
- 接入Uber：行程助手通过API接入的方式，让用户可以直接预订Uber的车辆，当然这只限于Uber运营的国家和地区。
我们都能看到穷游做这款产品的优势，比如很多年积累下来的高质量用户（梅子说他们提供了大量有效的产品建议），比如基于穷游锦囊和目的地的大量结构化POI数据等。基于数据库，穷游行程助手在一开始所覆盖的境外目的地就比较全，功能也实用，加上忠实用户的试用，这让产品团队在过去两年中积累了不少数据，后台算法也基于这些数据进行滚动调整，POI数量也随之增加，进入了一个正向循环。
这也是为什么一个初创公司从零开始做一个行程助手并不容易——没有足够用户试用积累数据，数据库信息有限，很容易陷入恶性循环。梅子也认同这个观点。
作为一个诞生在PC时代的产品，行程助手也在尝试迎合移动端使用习惯。比如用户可以在app上随时增减行程，例如今天心情不好，原计划6个景点，现在减少到3个，“摇一摇”之后系统就会重新推荐一个新行程；再比如，行程助手还提供基于LBS的周边景点、餐饮的基本信息和评价的功能。这些简介一部分是来自于穷游的游记和论坛内容的，和其他竞争对手一样，穷游也在考虑如何将有价值的、包含POI的内容做结构化处理。梅子认为，行程助手就是很巧妙的解决方案，因为所有行程助手内的信息全部是结构化的。
穷游也在试图通过行程助手导向交易，现在PC端就提供添加景点后直接购买门票的功能——当然是导向”穷游折扣“。梅子说，目前工作的重点一个是扩大穷游折扣的SKU，另外就是加强app上的即时预订功能。但即时预订并不容易，因为穷游折扣的目的地产品大多是来自不同供应商的，供应链管理和实时的预订确认是两个难点。
目前穷游行程助手境外打开比例达到40%以上，已经积累了百万级别的用户，上千万个行程。
最后我跟梅子讨论了两个小问题：
做行程是不是入口：梅子认为“是的”，因为根据用户习惯，一般先有旅游灵感，然后确定目的地做行程，之后才考虑酒店机票（当然也有用户是先抢到便宜机票才做行程），因此通过行程助手导向其他交易是可行的，比如穷游的酒店信息就来自于Booking.com的产品库。
做行程助手遇到什么坑？梅子觉得最大的坑就是如何提升算法，让行程推荐更智能、更准确。另外通过PGC和UGC方法扩大POI也是一个难点，如我们上面所说只有覆盖较多目的地的行程助手才有意义。另外梅子认为，行程计划是一件复杂的事情，因为产品就变得复杂，这和用户的易用性是矛盾的。因为功能越多，用户就越难上手，而恰好小白用户是数量最多的一群人。梅子希望穷游行程助手能够让资深用户觉得好用（因为穷游汇集了用户群中相对资深的一帮游客），同时小白也很容易上手，比如优化智能推荐的功能（这个功能有时候对于资深用户来说其实是很鸡肋的）。
