版本内容
酒店PC原型链接：https://modao.cc/proto/WrwITmdsebzkkmcyMZZXo/sharing?view_mode=read_only #PC（6.20）-分享
酒店APP原型链接：https://modao.cc/proto/pM7Tbjlvsebzkpaj8Iia7H/sharing?view_mode=read_only #APP（6.20）-分享
序号功能模块端口类型更新内容描述
1酒店拓客经理人PC+APP新增1、需求背景
理想状态：酒店老板可使用酒店端的推广二维码进行酒店的拓客推广；
①针对于酒店的拓客：酒店方可获得该拓客以后每一笔订单的收益；
②如果新客户在注册后1小时内通过该推广渠道预定该酒店的房间，此次预定将被视为“拓客单”；对于“拓客单”，平台将提供额外的布草补贴给到酒店；
现实场景：在许多酒店中，大堂经理或前台工作人员通常负责接待。在这些情况下，他们可能会选择使用个人的二维码来推荐新客户。这样做虽然可以使他们作为推荐人获得来自该客户未来订单的收益，但这会导致酒店整体的新客户增长缓慢，并且酒店无法获得平台提供的拓单布草补贴。
达成一致：部分酒店老板对于大堂经理或前台工作人员使用个人推荐码来推广新客户持开放态度，并愿意让工作人员获得来自这些客户未来订单的收益。但酒店方提出需要保留来自这些拓客订单的布草补贴，给到酒店。

2、系统实现
酒店后台：设置模块-新增【酒店拓客经理】设置，选取当前酒店下的主/子账号作为酒店的拓客经理人；
账号选择过滤条件：①账号需为当前酒店的主/子账号；②该账号已注册金时房客C端账号；
备注：①一个账号可为多家酒店的拓客经理，一家酒店最多可拥有5个拓客经理（多选）；
           ②权限控制：【酒店拓客经理】设置仅为酒店admin账号可见及设置；

3、拓单及推广收益
①拓单认定：当新用户扫描或输入“酒店拓客经理”的推广二维码或推广码，并在注册成功1小时内，在“酒店拓客经理”所在的任意家酒店成功下单，该订单将被视为酒店的“拓单”，酒店将获得此订单的布草补贴。
②该推荐人奖励：同时，该“酒店拓客经理”将成为这些新用户的推荐人，并有资格获得这些客户未来订单的收益。

4、注意！！！
目前得到的反馈是：以上方案仅部分酒店认可，系统层可做权限控制，以上功能仅对部分酒店开放，需由市场部提供有合作意向的酒店信息！！！
2OA新增酒店列表-正式签约酒店TAB，列表增加“拓客经理”字段（开启/未开启）；
开启：酒店超级管理员可见“拓客经理”模块；支持查看及编辑；且此功能正常使用，酒店布草补贴正常发放；
未开启：“拓客经理”模块隐藏；隐藏后清空该酒店下“拓客经理”绑定关系：（注意：历史已存在但未发放布草补贴的拓单，此类布草补贴收益正常发放；）
3布草补贴PC+APP新增1、需求背景
①合作酒店行为问题：观察到部分合作酒店通过不正当手段提高“拓单”价格，以此抵消更多交付的房费，这种做法给平台带来了不必要的损失。
②布草奖励经济压力：在酒店尚未完成房间交付的情况下，平台需要先行支付布草奖励，这给公司造成了额外的经济压力。

2、新版逻辑
与拓单相关变动：
①拓单-整笔订单都被认定为拓单，且整笔订单商家都需承担5小时时长，且拓单不可被认定为交付房；
②关于拓单补贴：额外给酒店布草补贴 ，判断交付房中是否包含拓单交付金额（就需要记录每一笔交付房的房费来自于那些订单）：
          i包含：每一笔交付房固定补贴【XXXX】元；
          ii不包含：无补贴；

特殊情况处理：
①拓单金额分摊：如果一个拓单的金额被分摊到多个交付房中，每个拓单都有机会获得布草补贴。
②单一补贴规则：当一个交付房包含多个拓单金额时，每个交付房也只补贴一次。
备注：历史版本中-订单列表/订单详情/提现详情中的“拓单”标识显示保持不变；

4拓单标识区分PC+APP优化拓单来源：①新用户扫描拓客经理二维码并在注册成功1小时内，在“酒店拓客经理”所在的任意家酒店成功下单，该订单将被视为酒店的“拓单”②新用户扫描酒店推广二维码并在注册成功1小时内，在该酒店下的第一单，该订单将被视为酒店的“拓单”。设计注意：后端许区分两种不同拓单的类型，前端需展示不同色调标识；

涉及页面：订单列表、订单详情、提现列表；
5订单PC新增订单下载：下载当前订单，所有状态的订单均支持详情下载；
6PC+APP新增待入住、入住中、已完成的-子订单增加“交付房”标识；
即：当订单状态变为待入住时，开始判断交付房，并在对应的子订单单号后增加“交付房”标识；

注意：
①历史数据：线上已存在的待入住、入住中的订单“交付房”标识处理；
②未完成订单交付房显示：当订单/子订单状态由待完成（待入住、入住中）→已完结（强制退款、提前离店、已完成）时，当前订单之后的所有未完成子订单的交付房标识应及时变更显示；例如：当子订单A在待入住时被认定为“交付房”后，操作A订单退款，此时A订单的“交付房标”应去除，且A订单之后的所有子订单/订单都需重新判定新的“交付房”；
③已完成订单交付房显示：以最终的“交付房”判定结果显示；

优化订单列表-订单详情-订单明细中的“❓”文案需重新优化，内容如下：
1、按单间单日为维度，生成多个子订单
2、此处订单号前若显示“房子icon”标识，则表示：此子订单为预交付房，若中途出现退单，则交付房需重新计算，最终交付房以订单完成后的显示为准;
7总后台-订单新增总后台-订单详情-子订单号后同步增加“交付房”标识；
8PC+APP新增待入住/入住中订单-【确认入住】按钮，点击时增加校验：
未到入住日期：按钮显示为灰色，
按钮提示：当用户尝试点击灰色的【确认入住】按钮时，弹出Toast提示：“未到入住日期不可操作”。
9账单对账PC新增酒店PC-财务管理-账单对账-账单下载模板中新增：房间名称、入住日期、离店日期、客人姓名、订单总间夜字段；
备注：入住日期、离店日期＝预定的住宿日期；客人姓名需显示全部的客人姓名；实际入住间夜=预定间夜-退订的间夜数；
10多房价维护、多房态维护
房态看板		PC+APP优化需求
第二天早上六点之前，需支持修改昨天房间的价格及房量；

解决方案
选择修改日期时需根据当前服务器时间判断：
当服务器时间未超过当天早上六点（包括六点），则允许选择昨日日期；反之则不可选择昨日日期；
11OAPC新增酒店门户分析（确保前端页面开发完成，完成80%数据对接）
原型链接：https://modao.cc/proto/zcGpap1Isecc3zyLJvL0Cn/sharing?view_mode=read_only #酒店门户-分享
12财务门户：
提现分析（设计图完成）
酒店订单分析（设计图完成）
原型链接：https://modao.cc/proto/1amUrgtaryszvtMZo326p/sharing?view_mode=read_only #OA-财务门户-分享
6.18新增需求
1OAPC新增OA-酒店门户-酒店管理：新增二级菜单【辅助客服维护】：上传客服企业微信二维码；
2酒店端PC+APP新增酒店注册页面-点击提交新增弹框显示：
①点击【自主填写】：跳转资料提交页面；
②二维码：取OA维护的-首张客服二维码；
③点击“×”弹框关闭，停留在当前页面；
  • 无标签
写评论...