这款产品以旅行比价+预订为切入点，面向对价格敏感的使用者群体，通过大资料收集、整合、多平台资源暴露，运用分享砍价得现金券等运营手法，借力自研的AI智慧推荐系统，支援语音输入&搜寻&下单。
围绕全网比价、低价预订、分享砍价、快捷、科技范，帮助广大消费者找到携程&美团等OTA无法提供的低价&可订的旅游产品。
一、确定产品要支援的预订渠道
总的预订渠道分为线下和线上两大类。线上预订的主要渠道有APP、小程式、H5网页、web 网页等，线下渠道主要是门店，热线预订等。考虑到推广方便、开发迭代敏捷、获客成本、潮流趋势、人群属性、业务场景、搭载功能的载体、封杀下的存活等因素，做了如下分享，并最终确定 APP+小程式+H5 的线上预订渠道。
二、围绕产品所解决（比价）痛点找资料
要突出产品的比价必须做几件事： 业务资料尽量全； 参与平台尽量多；平台资源覆盖尽量广。要完成这几件事，进行了如下规划：下面以酒店资料为例。
1. 资料的获取主要从公开渠道 和 合作方获取（公开渠道其实大家都懂，合作那就更不用说了）。目前已经涵盖的平台数据共20个，酒店资料总量超过1600万条。
2. 资料的处理主要包括几个步骤： 格式标准化&算法去重&去僵尸&合并，最终提炼出一套标准格式的马踏飞燕酒店基础资料。
酒店静态资料有了，怎么把城市/POI跟酒店关联，供使用者查询使用呢？
3. Region资料的获取&整理&标准化由于酒店资料来自20个平台数据的提炼，同时有国内和海外之分，在Region资料的抽取方面刚开始走了很多的弯路，整理出来的资料出现过不全面，格式不对匹配校验难推进，资料重复错误等情况。最终采用逆向处理，才把全球的Region资料弄全，弄准确。
I. 对酒店基础资料进行 经纬度提取，校验，正确性验证。
II. 对提取的经纬度资料进行：google、百度、高德、腾讯 等格式的转化。
III. 通过多条经纬度反查Region，再对各反查结果进行清洗，整合，层级划分。
IV. 根据 百度，高德，腾讯 和 Google 在区域性上的资料优劣，采用优为主，劣为辅。
V. 通过层级整合出一套全球的Region 基础资料，再通过对映关联酒店资讯。
例如： 每个国家的Region划分存在较大差异：
百度资料在中国大陆和港澳台地方的Region 层级划分采用： 大洲-国家-省-市-县（区）-乡镇 的6层结构
而google资料在海外有优势，同时又考虑到google地图在不同国家的层级划分有差异，因此定义其层级划分时采用了兼多并广抓主的策略 ，设定了如下层级：continent，country，administrative_area_level_1，administrative_area_level_2，administrative_area_level_3，locality ，postal_Town，administrative_area_level_4，administrative_area_level_5，natural_feature,，sublocality，neighborhood。
通过上述处理整合出了一套12w+的树形结构Region基础资料，并支援根据酒店资源的新增情况同步扩充Region资料，真正做到了资料的可靠性高，可扩充套件性强，延伸面广，层级划分清晰；
三、围绕产品所解决（预订）痛点找资源
在完善酒店资料和Region关联酒店资料后，使用者可以找到全球260万酒店，也已经支援一键跳转到第三方合作平台下单。但此时使用者仍只能对各OTA进行比价，没有一手资源房型的低价供使用者预订，接入API 一手资源，提供跟直接的低价预订则是接下来的重头戏。这个过程持续的时间较长，先后接入了艺龙、去哪儿、好巧网、道旅网、捷旅假期、龙腾捷旅、美团、途牛、携程、聚优惠、同程等11个API平台。
在这个过程中抛开商务谈判外，对接多平台时各API的相容和展示模式，是产品必须全盘考虑到一个问题。
I. 展示模式：采用了淡化知名度&去中心化，全以价格优劣来分层展示，保证各平台的公平竞争。
II. API相容上：我们从使用者诉求出发，结合各API的资料支援情况，抽取并整合出一套标准的API界面格式；然后再根据标准的API格式对各平台界面进行解析。
这个过程不是一蹴而就的，需要进行了大量的沟通、整理提炼、相互改进等工作。
在策略上采用先易后难，由简到繁，进行了多个迭代： 首先只解决了房型名称和价格等核心资讯的展示；后续再迭代加入了早餐、床型、住客限制、容纳人数、房型图片、发票、礼盒、设施、取消政策及退款等功能。
III. 运营上： 根据功能的完善情况，推广上也慢慢发力，采用冷启动，循序渐进。这样使用者体验上：对房型的认知就慢慢由抽象不确定 到 可见更全面认识，增强了使用者对平台可靠性和真实性的信心。再加上截长图分享， 领红包砍价 和 小程式里的拉新活动，使用者能得到真实底价上的再减优惠。
V. 使用者感知上： 优化UI布局，增加必要的快捷筛选功能，增加权威性，又加入了酒店官网资料。
最终多平台比价的页面就打造出来了：
四、下单流程的梳理
前面讲到的主要是基础资料展示、界面资料展示、产品痛点的突出等方面的内容。使用者下单过程中的流畅便捷其实更关乎产品是否成功：使用者越到流程的末端，对异常和阻塞的容忍就越低，当精心挑选的房型在填写页、支付页出现异常时，没有一个使用者不会咆哮和愤怒。
因此这些页面的产品使用情况一定要站在使用者角度深刻体会，进行彻底解决或者友善的引导。
如：
I. 资料填写页：增加 常旅客&常用联络人 快捷入口，发票资讯的自动带入历史资料等。
II. 支付页：预设选中满足条件的现金券，减少干扰项。
III. 对各API的下单可靠性进行长时间的调研分析，针对分析结果进行重点优化，直至到达预定目标。
IV. 对影响入住的资讯进行突出展示，完善通知简讯，邮件等使用者资讯获取渠道。
为了产品的完整性，分步搭建起了：
app+小程式+h5预订的格局；对CRM公用模组 和 后台模组进行了整合；为了增强使用者的互动性，打造了网红酒店、完善点评系统、完善了LBS地图的立体展示等功能模组；对可能出现的风险点 规划了资料加密、反爬等技术提升；对资料进行了 持续的定期更新，保证资料的准确性和完整性；同时启动了唤醒计划。通过一系列的优化迭代，酒店订单由原来的每天0单、1单，经过近8个月的缓慢增长，攀升到目前的每天120单左右，预订确认失败率控制在2%以内。
目前酒店专案比价页的UV使用者达到170W+, 注册使用者56W+，小程式的 DAU 5000+，MAU 7W+，在没有广告推广的情况下新注册使用者以每天3000+左右增加，后续还会在效能，使用者体验和细节上继续提升。
给大家展示一下APP的首页，可以试试AI推荐和语音下单了， 下一版再解锁医美产品。
本文由 @飘雪的南方小城 原创释出于人人都是产品经理。未经许可，禁止转载。
题图来自PEXELS，基于CC0协议
