通了一宿的宵，干到早上7:00，产出了设计说明书，以后会慢慢细化。。。
背景：Allen经常旅行，他会搜索目的地酒店的房型和价格信息，然后下单。但是他也为搜索这些信息花费的时间和精力而苦恼。
解决思路：直接让消费者发出一个心理预期价格和出行计划，让不同酒店来接单。
痛点：为了能找到合适的酒店费时、费力。
关键字：经常、搜索、目的地、酒店、房型、价格、心理预期价格、出行计划、酒店接单
分析：
1.“经常”：Allen这类消费人群经常旅行，所以在产品形态上要有Web端和移动端。Web端是为了让Allen在做那些低频次长决策的时候使用，如春节全家出行、单位集体出行、蜜月行等；移动端是为了让Allen在做那些低频次短决策时使用，如一场说走就走的旅行、临时的出差等等；
2.搜索：要在全网抓取供应商信息，包括最上游的酒店、 GDS，OTA 等网站，横向比较后最终呈现给用户少数最优的酒店选择；
3.目的地：推送的酒店一定要离目的地近，景点、商圈等；
4.房型：搜索的前提条件，可以为用户添加一些写好的标签，如“单人间”、“商务间”、“高速WiFi”等。
5.价格：要考虑价格范围在预期价格的+-10%左右（客户可以接受的范围）；
6.心理预期价格：输入心理预期价格让商家接单；
7.出行计划:要考虑到达时间、离开时间、交通工具、游玩天数等；
8.酒店接单：不提倡酒店抢单，用户先下单，推送到满足条件的各个酒店，看酒店是否愿意接单，将满足条件且愿意接单的酒店推送回用户，添加酒店评分机制，让用户自己选择。
首页：
Paste_Image.png
1.在目的地输入界面处默认定位为用户最可能去的地方，当点击输入框时会出现下拉单，根据用户消费习惯，默认为国内或国际，展示近期热门的旅游地，搜索框中可通过输入城市名或城市首字母搜索；
2.入住时间默认为本日，离开时间默认为次日，点击输入可通过日历选择具体入住和离开时间；（日历上节假日要标红提示用户在这段时间内人比较多）
3.根据目的地和入住时间长短，在输入期望价格框提供参考价格，下拉单中可让用户自行选择价格区间，也可直接输入具体价格。
在输入完目的地、入住离开时间、期望价格后无需点击，直接搜索，自动展示结果。
ps：输入要让用户尽可能便捷，目的地城市不止一个时，对第二个要有预判。
搜索界面：
Paste_Image.png
搜索结果：
1.根据目的地、入住离开时间、期望价格(+-10%)显示默认搜索结果。因为Allen的痛点是在找酒店时费时费力，所以在界面设计上考虑到用户的 “选择困难症”，以及页面跳转对用户会产生的决策影响，所以抛弃常规的列表形式，以可视化的价格地图替代，这样做的好处还能让用户根据地图上的景点就近选择酒店；
2.展示酒店数量上要合适，5个左右最佳，检索出的酒店在价格方面要在预期价格的范围内，考虑酒店舒适度情况（根据酒店评分），酒店标准要相近；
3.用户可在该页面细化目的地，这次目的地的划分选择要比首页的划分要细致，展示商圈、行政区、热门景点、机场车站、地铁线路、临近大学、临近医院等标签让用户直接点击选择。在进一步选定目的地后，在目的地的半径范围内如果符合条件的酒店过多，则按酒店的评分排序取top5；如果在目的地的半径范围内符合条件的酒店过少，则展示最近的几个酒店（按用户所定的价格区间选取）；
4.在界面左下角部门加入快速筛选按钮（可多选），选择机场、火车站、客运站、热门景点、购物街中一个或几个，自动筛选出符合条件的酒店；
5.右上角的价格区间显示附近酒店的最低价和最高价，滑动轮默认在用户所选的价格上，通过滑动滑轮可以改变价格选项，此时地图上的对应结果也一同变化；
6.对于最符合的top5酒店展示酒店名称、价格、评分，其他同样也满足条件但未进入top5的酒店在地图上用红色坐标标出。
自定价格抢单页：
Paste_Image.png
用户在首页面点击“自定价格”后，跳转到该页面，用户在选择好筛选条件后，点击“发布订单”按钮，系统会立即将订单消息推送给符合用户筛选条件的所有酒店，酒店在接到订单后选择是否愿意接单，将愿意接单的商家显示在价格地图上，每隔60秒更新一次地图（延长数据的更新时间有利于刺激酒店马上接单，先接单就会先显示在地图上，被用户选择的可能性就越大）。用户可以在对比完愿意接单的商家后，根据酒店评分、价格、评价等因素选择酒店。
逻辑算法（为简化叙述，在这里将建模逻辑用自然语言代替，想要了解深层逻辑算法可发我邮件）
第一阶：
搜索的优先级 1>2>3
1.目的地，半径500m 2.入住离开时间 3.期望价格+-10%
搜索过程：
若1未满足，增大搜索半径，每次+100m，当搜索到符合条件的酒店后检索2；2为硬性条件不可更改，若没有房间则弹出窗口提示用户，当搜索到符合条件的酒店后检索3；但没有满足用户期望价格+-10%的酒店时，增大价格区间，每次+5%。
当第一阶执行完毕后进行第二阶
第二阶
A:当符合1、2、3的酒店数量>5时，对符合条件的酒店排序 （1）>（2）>（3）>（4）>（5）
（1）舒适度（有酒店评分决定）；
（2）离目的地远近（不是直线距离，而是实际路程）；
（3）价格（因为已经在期望价格的范围内了，所以差价不会很大）；
（4）离公共交通设施的距离；
（5）离其他优质资源的距离（如其它景点、美食等）。
B:酒店数量<5时，根据A中的算法搜索出符合的酒店补位。
核心点：
1.搜索上要在目的地抓取供应商信息，包括最上游的酒店、 GDS，OTA 等网站，横向比较后最终呈现给用户少数最优的酒店选择；
2.“在自定价格选择酒店”的过程中，酒店方面是否愿意合作？该功能实质上是一个O2O模式，服务者（酒店）是否成熟，愿不愿意接受这样的消费模式会决定该O2O功能线下推广的难易程度；
3.系统的稳定程度，技术部门的支持力度，系统的更新迭代周期，这些都将直接的影响用户体验，需要在技术上得到保障。
风险点：
1.在技术上实现抓取信息的难易程度，如果出现大规模宕机现象会给用户带来很大的损失，导致用户的流失；
2.在“在自定价格选择酒店”的过程中会不会存在恶性竞争的事情发生；
3.在前期的推广运营中是否需要对商家进行补贴，如果补贴后没能达到预期效果，该如何应对。
移动端demo（时间问题只做了iOS端的，Android的找时间补上。。。）
Paste_Image.png
谢谢各位看官~
网友评论