YUNLEZHU · PRODUCT NEWS
云乐住酒店数字化运营能力再升级
连接老会员、前台收款、多门店餐饮与订单履约
酒店上线线上预订后，真正影响长期运营效率的，往往不是有没有一个下单页面，而是线下积累的老客户如何进入会员体系、前台收款能否留下清晰记录、不同门店的餐饮订单是否会混在一起，以及订单完成后能否准确核销。
围绕这些日常问题，云乐住进一步调整了酒店小程序的会员、点餐和后台管理流程，让客户身份、账户权益、门店归属与实际履约之间形成更可靠的连接。
此次升级聚焦：历史会员承接、可追溯的人工充值、会员生日资料、多门店菜单与购物车隔离、点餐履约核销。
先把酒店已有客户沉淀到线上会员体系
不少酒店在使用线上系统之前，已经通过纸质登记、表格、收银系统或其他渠道积累了一批老会员。这些会员可能已经拥有余额、积分、等级或累计消费记录，但过去通常需要等客户重新进入小程序后再人工核对。
云乐住现在支持酒店先按手机号建立历史会员资料，并录入姓名、生日及原有权益。当客户在小程序中完成手机号授权，系统会在当前酒店平台范围内寻找对应记录，确认唯一匹配后再完成身份识别。
这种方式既能延续原有会员资产，也能避免仅凭昵称或临时访客记录合并账户。完成识别后，顾客可以继续使用原有余额、积分和会员等级，酒店也能逐步形成统一的线上客户档案。
让前台充值从“改余额”变成一笔可核对的业务记录
线下充值常见于酒店前台。客户可能通过现金、转账或其他方式付款，工作人员随后需要把相应金额加入会员账户。如果只是直接修改余额，后续很难判断增加原因，也不利于财务对账和责任追溯。
新版将后台充值设计为独立操作。工作人员需要分别填写实收金额、赠送金额和备注，系统自动保存操作人、充值来源及余额变化。重复提交保护可以降低网络卡顿或连续点击造成的重复入账风险，相关记录还可按会员、订单号、手机号或操作人员检索和导出。
补充生日资料，为后续会员关怀留出空间
会员可以在个人资料中填写生日。为了减少频繁修改带来的营销数据失真，生日首次保存后由系统锁定，如录入有误可联系酒店工作人员核实后调整。后台会员列表也会呈现客户来源、识别进度和生日资料，帮助酒店逐步完善会员画像。
多门店点餐先确认“在哪家店”，再处理“买什么”
连锁酒店开展客房送餐或门店零售时，相同商品可能由不同门店提供，菜单、库存和履约人员也不相同。如果顾客在下单过程中丢失门店信息，就可能出现订单到了错误门店、购物车商品混合或价格核对困难。
云乐住在点餐页面突出展示当前服务门店，并提供可配置的门店切换入口。通过平台入口访问时，客户可以从已开放点餐的酒店中进行选择；通过房间或餐桌二维码进入时，页面会锁定二维码对应门店，避免误切换。
不同酒店的菜单和购物车分别保存。切换门店不会删除原购物车，但原门店商品不能与新门店商品放在同一订单内结算，从业务源头明确订单归属。
把送达信息和订单完成动作放回正确流程
新版点餐结算页集中呈现服务门店、配送或自提方式、送达位置、联系手机和商品清单。酒店将送达位置设置为房间号、餐桌号或其他名称后，顾客会看到对应提示；需要配送时，必要信息必须填写完整才能提交。
订单进入门店后，普通点餐订单可以通过二维码执行核销并完成。系统会按照点餐或商城的真实业务类型分派退款、取消、出餐、发货和完成操作，减少不同订单状态机混用引起的履约问题。
细节修复继续围绕真实经营场景展开
本次还修复了钟点房与长租房搜索条件混用的问题。顾客从首页选择钟点房后，进入搜索和门店列表仍会保持对应模式，减少搜索结果与预订需求不一致的情况。
分销海报扫码与新版首页的参数衔接得到恢复，客户从推广海报进入时能够继续执行推广关系识别。微信订单页面路径也按订房、商城和点餐分别展示，便于运营人员复制到微信公众平台。
后台图片库则改善了批量选择、移动、删除和分页操作，并进一步限制平台及门店可操作的数据范围。对于采用多租户模式的酒店管理系统，这些权限边界是保障日常素材和业务数据安全的重要基础。
版本更新提醒：本次升级涉及数据库结构、小程序页面及交互流程。系统更新后，需要上传最新小程序代码并重新提交微信审核，审核通过后再发布给客户使用。
从老会员资料承接，到前台充值、多门店点餐和订单核销，云乐住持续围绕酒店真实工作流程完善数字化能力，让酒店预订系统不仅能服务客户下单，也能连接会员经营、现场服务和后台管理。