高级产品经理、产品中心负责人，负责产品规划、版本范围、核心方案和项目推进，并协调业务、设计、研发、测试及外部服务商。
B2B 交易｜2021—2023
从 0 到 1 搭建 B2B 交易平台
以最小交易闭环为起点，完成微信小程序、商户端和运营端的基础产品建设，并逐步补充支付、结算、营销与信用支付。
完成小程序、商户端和运营端基础版本上线，跑通从商品发布、下单支付到商户结算的交易与资金闭环。
01
背景与难点
先说明为什么要做
业务背景
项目从零起步，需要先验证交易能否跑通，再逐步满足商户经营、平台运营、资金结算和银行信用支付等需求。
主要难点
早期资源有限，但用户端、商户端和运营端必须同步具备基本能力；资金链路涉及担保交易、分账、退款和对账，规则边界多。
核心使用者
- 企业采购用户：找商品、下单并完成支付
- 平台商户：发布商品、处理订单并查看结算
- 平台运营：审核商户、配置活动和处理异常
- 财务及银行：完成对账、结算与信用支付
产品目标
- 01用最小范围跑通商品到结算的完整闭环
- 02保证小程序、商户端和运营端使用同一套交易规则
- 03把支付、分账、退款和对账做成可核对的资金链路
- 04在基础交易稳定后再引入分销和信用支付
02
业务流程
业务怎么流转，产品负责到哪里
商户发品
商品、库存、价格与审核
买家下单
购物车、订单、优惠计算
完成支付
担保交易、快捷或信用支付
履约确认
发货、收货、售后退款
分账结算
服务费、佣金、商户对账
流程图展示主链路；各节点涉及的状态、异常处理、接口和后台配置，在下方“产品判断”和“方案落地”中展开。
03
产品判断
我如何把问题转成产品方案
01
看到的问题
从零开始时需求很多，若按端分别排期，很容易出现页面有了但交易跑不通。
我的判断
首期范围应按一笔订单的完整生命周期确定，而不是按页面数量确定。
落地方案
以商品发布、下单、支付、履约和结算为主链路，同步建设三端必需能力。
02
看到的问题
担保交易、分账、服务费和退款互相影响，单独设计会造成账实不一致。
我的判断
资金规则必须先于营销玩法稳定，并能对应到每笔订单和结算单。
落地方案
统一订单金额、支付单、分账明细、服务费和退款记录，补齐商户对账入口。
03
看到的问题
银行贷款支付的结果并非即时成功，直接套用普通支付会产生错误订单状态。
我的判断
信用支付是一种异步支付方式，需要独立的处理中和异常恢复机制。
落地方案
在收银台增加额度选择、结果查询、处理中状态和异常退款流程。
04
方案落地
我具体负责并交付了什么
- 01
规划用户、商户、账户、商品、购物车、订单、支付和结算等模块，确定首期范围和后续迭代节奏。
- 02
接入聚合担保交易和银行卡快捷支付，设计合并支付、分账、绑卡支付、退款及商户对账流程。
- 03
设计账期补贴、拼团和分销体系，实现平台服务费实时划扣、分销关系记录和佣金结算。
- 04
接入银行授信与贷款支付，在收银台支持企业信用额度支付、结果查询及异常退款。
- 05
建立需求评审、版本排期和上线验收机制，推动多端产品按共同交易规则交付。
主要交付物
平台产品规划多端信息架构订单支付与结算规则分销佣金方案银行信用支付方案
05
结果与复盘
结果、能力证据与下一步思考
按订单闭环定首期
首版不是按端拆功能，而是围绕一笔订单从发品到结算，确定小程序、商户端和运营端的共同范围。
资金记录可核对
将支付单、分账明细、服务费、佣金、退款和结算单建立对应关系，支持商户对账。
处理异步信用支付
为银行贷款支付单独设计处理中、结果查询和异常退款，没有直接套用普通支付状态。
项目结果完成小程序、商户端和运营端基础版本上线，跑通从商品发布、下单支付到商户结算的交易与资金闭环。
项目复盘
0 到 1 阶段的关键是克制：先确保一笔真实交易能够从前台走到商户结算，再增加营销和金融能力。若重新推进，我会更早建立统一的交易状态字典和版本指标看板。