07 / 交易与协同

山海集团旅游平台

连接用户端 App、商户与分销体系、旅游业务中台，让内容、预订、订单与结算形成完整路径。

山海云途2021.08 — 2022.03

我的角色: 产品经理
负责范围: 用户研究 · 多端产品 · 分销与业务中台

项目背景 / 故事从这里开始

用户付完款，旅行服务才刚开始。

买一件普通商品，支付后通常是等待收货；买一次旅行，用户还要确认出行日期、填写同行人的证件、等待成团，并在出发后持续获得服务。山海集团旅游平台要承接的，正是这段从购买到实际出行的过程。

我负责的产品同时连接游客、旅行社门店、业务员与平台管理人员。在调研 20+ 家旅行社门店、50+ 分销商的基础上，我把消费者体验、业务员经营和平台结算放到同一条链路中梳理：前台每一个状态，都需要有对应的业务关系和处理规则。

01

关键问题

从心动到出发，怎样接住一次旅行？

遇到的问题

旅游订单并不会在付款后立即完成。出行人信息可能尚未补齐，日期和成团状态还需要确认，退款与客服也会继续发生。如果只围绕下单设计页面，后续服务就容易重新回到电话和人工沟通中。

我的判断

我把主链路定义为一次完整的出行生命周期，让订单既承接交易，也承接出行准备、履约和售后。用户在不同阶段需要看到的状态与操作，应当随任务变化。

让内容自然走向预订

商品详情用图文表达旅行体验，提供参考行程、价格和分享入口。进入预订后，再集中确认出行日期、成人与儿童数量、优惠及支付方式，把内容浏览与交易条件衔接起来。

让准备工作跟着订单走

将出行人与订单关联，提供常用旅客、证件信息和出行日期的填写与管理。支付完成后仍然承接信息补充，帮助用户继续完成出发前的准备。

用状态解释下一步

围绕待付款、待确认、完成与失效等状态组织订单内容；通过行程时间线和出行凭证连接实际履约，并提供退款申请、撤销申请和关键场景的客服入口。

保留持续服务的入口

个人中心聚合订单与行程，消息中心区分订单、行程通知和团长会话，关注小店保留用户与服务方的关系。购买之后，用户仍能找到相关事项和沟通入口。

01内容与分享
02确认预订条件
03补齐出行信息
04行程与持续服务

C 端 · 从商品内容到预订

旅游商品详情设计稿，展示酒店内容、参考行程、价格和下单入口 — 以图文内容呈现旅行体验，将参考行程、价格与预订入口放在同一页面。

旅游商品分享设计稿，提供微信、朋友圈和图片分享入口 — 商品内容可以转为分享卡片，通过微信、朋友圈或图片继续传播。

提交旅游订单设计稿，包含出行日期、成人儿童数量、优惠与支付方式 — 下单时集中确认日期、出行人数、优惠和支付金额，让预订条件在付款前可见。

C 端 · 出行准备与订单履约

填写出行人信息设计稿，包含常用旅客、证件和紧急联系人 — 把出行人信息与订单关联，支持常用旅客选择和证件补充。

旅游订单待核销设计稿，提供出行确认码与订单信息 — 出行确认码连接线上订单与现场核销，让支付后的履约有可操作的凭证。

行程详情设计稿，按时间线展示成团、出发和每日安排 — 用时间线串起成团、出发与每日安排，把购买延伸到实际出行。

C 端 · 行程、消息与小店关注

项目设计稿查看完整图

个人中心汇总行程和订单状态，常用信息与专属客服承接出行前后的服务。

游客消息中心设计稿，区分系统通知、订单消息、行程消息与团长会话 — 将订单、行程通知和团长沟通集中到消息中心，方便用户继续处理旅行相关事项。

关注小店设计稿，展示团长资料、旅游商品与关注状态 — 保留关注的小店和团长，让用户能够回到熟悉的服务方浏览线路。

这一段设计的重点，是把购买、准备与服务放回同一次旅行体验中。

02

关键问题

业务员分享商品之后，怎样继续经营客户？

遇到的问题

旅游销售依赖长期客户关系。商品在微信和朋友圈中传播，订单、服务和收益却分散在不同环节。业务员需要的不只是一个分享链接，还需要知道客户来自哪里、订单由谁服务，以及自己的经营情况。

我的判断

我围绕业务员的任务梳理产品：卖什么、服务谁、订单推进到哪一步、收入如何查看。把商品、客户、订单与收益关联起来，才有机会让线下经营过程沉淀到系统中。

用商铺承接商品经营

通过个人商铺组织可销售商品，提供二维码与分享入口，让商品传播有统一的承接页面；同时连接区域产品库与商铺的上架经营关系。

用工作台承接持续服务

围绕客户、团和订单组织工作台，连接人员管理、订单处理和出行服务，让业务人员从统一入口跟进销售后的任务。

把发团拆成可核对的步骤

针对未固定时间的商品，通过选期、待发团管理和邀请进团组织履约。成员列表同时呈现出行人信息、确认状态和关联业务员，方便发团前逐项核对。

让经营情况能够回看

营销业绩呈现销售额、订单数与收益趋势，市场分析按成员比较经营情况，KPI 页面记录个人与团队目标进度。不同视角分别回应业务员和管理者的日常任务。

B 端 · 商铺经营与工作台

业务员商铺设计稿，提供商品经营、二维码和分享入口 — 个人商铺承接商品经营与传播，让业务员有持续服务客户的入口。

业务工作台设计稿，包含客户、团、订单和经营分析 — 把客户、团、订单与经营分析组织到工作台，支持销售之后的服务任务。

B 端 · 选期、建团与游客协作

商户建团选择日期设计稿，展示日历与确认日期操作 — 未固定出行时间的商品，通过建团选期明确后续服务的出发日期。

商户待发团管理设计稿，包含团长、日期、成员、游客与业务员信息 — 团管理集中呈现成员、资料补充状态与相关业务员，为发团前的核对提供依据。

邀请游客进团设计稿，按订单关联出行人并汇总成人与儿童人数 — 按订单选择同行游客，区分待确认和未填写出行人的状态，并汇总进团人数。

B 端 · 销售表现与团队目标

商户营销业绩设计稿，按时间查看销售额、订单数和收益 — 通过时间筛选与趋势图查看销售额、订单数和收益，支持日常经营回看。

商户市场分析设计稿，按成员查看销售额与订单数 — 按成员呈现销售额和订单数，帮助管理者比较不同成员的经营情况。

商户KPI管理设计稿，展示个人与团队目标进度 — 将个人和团队的目标、周期与完成进度放在一起，便于持续跟进。

我关注的是一笔生意从获客到服务的连续性，而不仅是单个功能是否齐全。

03

关键问题

一笔订单，如何对应多方的服务与收益？

遇到的问题

总部、门店与个人之间存在多层渠道关系；一笔订单还可能涉及推荐人、接单人和发团人。商品能否销售、谁应当获得佣金、何时可以提现，都需要明确规则，仅有一张订单表无法解释这些关系。

我的判断

我先拆清渠道层级、订单关系、佣金类型和结算条件，再设计页面。商品是否允许被平台使用，与某个渠道是否选择销售，也需要分别表达，避免商品状态与渠道经营状态混在一起。

分开商品规则与渠道经营

建立商品 SKU 和多价格体系，支持直营、代理与活动价。商品后台将出行日期、行程费用、成本与售价、移动端详情、发布信息及分佣方案组织在一起，使同一商品能够进入不同渠道的经营流程。

把关系转成可执行的结算条件

围绕三级分销识别订单关联角色，再连接佣金方案、发放与解锁条件。用户侧用可用资金、冻结资金和明细呈现状态，中台负责承接订单与财务结算规则。

01确认订单关系
02匹配渠道与方案
03判断结算条件
04佣金发放 / 解锁

业务中台 · 商品、行程与分佣配置

旅游商品管理后台设计稿，包含行程、成本与售价、移动端详情配置、发布和分佣方案 — 同一份商品资料连接行程费用、多价格、移动端内容和渠道分佣，展示前台交易背后的配置关系。

B 端 · 提成构成与账户资金

分销提成详情设计稿，通过图表和成员明细展示提成金额 — 用提成分布与成员明细解释收益构成，与账户中的可用、冻结状态互相补充。

账户资金设计稿，区分可用金额、冻结金额与提现入口 — 区分可用与冻结资金，让结算条件在用户侧有明确的状态表达。

冻结资金明细设计稿，按月份展示冻结与释放记录 — 明细页承接资金追踪；完整的分佣计算规则在业务中台中定义。

先找到稳定的业务对象与关系，复杂的线下协作才能变成系统可以执行的规则。

交付与复盘

这段经历，留下了什么？

工作内容与交付

我的工作覆盖消费者 App、商户与分销体系，以及商品、订单和财务中台。三端通过同一组商品、订单和服务关系衔接，形成从旅行决策到结算的产品方案。

旅游社区与预订 App
商户端 / 三级分销
商品 / 订单 / 财务中台
SKU 与多价格体系

我带走的方法

这段经历让我形成了处理复杂业务的顺序：先理解各方正在完成的任务，再拆解角色、流程、状态与规则，最后决定页面如何组织。

20+ / 50+调研旅行社门店 / 分销商

现有资料能说明产品范围与设计方案，尚不足以量化转化率、结算效率或收益提升。配图为项目设计稿，页面中的金额、销量等为示例数据。