企业官网建设流程全解析

简介：这份B2B2C电商平台功能清单是一份面向电商从业者的结构化需求文档，适合产品、开发、测试与运营人员在平台规划、功能设计和系统验收阶段使用。文档从买家端与商家端两个角度梳理了大量真实业务场景，涵盖商品检索与筛选、购物车、订单结算、支付配送、优惠券、积分抵扣、预存款、售后评价等交易闭环，也包含店铺管理、商品上下架、库存调整、SEO设置、站内信、会员中心等后台配置功能。文件为1个PDF，压缩后约1.18MB，轻量易携带，可随时打开对照。目前已有96人学习浏览，对于正在搭建或优化B2B2C平台的团队来说，可以快速形成功能全景图，排查缺失模块，同时也能作为产品原型设计、开发任务拆解和功能验收清单的基础底稿，减少遗漏与返工成本。

1. 一份B2B2C功能清单PDF，为什么值得逐行读

搜到“B2B2C电商平台功能清单.pdf”的人，多半不是闲逛，而是正在做两件事之一：要么是产品经理被老板要求出一版全功能方案，要么是技术负责人要评估一套平台的复杂度，准备排期报价。这类PDF比网上满天飞的“电商平台白皮书”实在得多——它直接摊开告诉你，一套B2B2C系统至少要接住哪些角色、哪些交易、哪些钱账货。我的建议是别只存进网盘，把它当成检查清单用起来：对照现有系统的模块缺口、对照供应商报价是否虚高、对照研发排期是否过于乐观。这份内容适合三类人：准备从零搭建B2B2C平台的研发团队、要采购或替换平台的业务方、以及混迹电商项目的产品和技术。下文按我自己的拆解习惯，把这份清单从“目录”读成“施工图”。

2. 把B2B2C拆成三端：功能清单背后的角色边界

2.1 平台端、商家端、用户端：一份合格清单必须先分端

B2B2C的核心不是“多一个供应商”，而是同一套系统里要装下三种完全不同的使用习惯。平台端要的是管控和数据，商家端要的是自主经营和效率，C端用户要的是流畅下单和售后保障。功能清单如果不按这三端分别列模块，基本可以判断是门外汉拼凑的，因为角色一混，权限和流程必然打架。我见过的坑往往是这样的：平台后台和商家后台共用一套订单查询页面，导致商家能看到别人店铺的售后单字段，最后只能靠SQL硬隔离补救。

拿到一份清单，先把每一行归到三个端下面。平台端通常包含平台自营管理、商家审核、类目管理、平台营销活动、结算对账；商家端包含店铺装修、商品发布、订单处理、库存管理、优惠券配置、售后处理；C端用户端包含注册登录、商品浏览、购物车、下单支付、退款售后、消息通知。如果清单里某个功能描述模糊，比如“订单管理”不写清是哪个端用的，建议直接标疑问，因为后续技术方案里这一个词的偏差，能让数据库表结构多出两版改动。

三个端之间的协作必须拉成一张链路图去理解，而不是平铺直叙地看模块列表。我会用“一个店铺从开店到成交一单”的路径把清单里无关的模块串联起来：商家提交入驻申请走平台审核，通过后配置店铺信息、发布商品和设置运费，用户浏览商品下单，订单同步到商家后台确认发货，用户确认收货后平台向商家发起结算。中间任何一个节点断了，比如商家发布商品时不知道要走平台类目审核，上线后就会无限推倒重来。

2.2 从“三端”到“五条线”：订单、商品、会员、结算、营销

分完端，再分线。功能清单里模块再多，最后都归到五条核心业务线：商品线、会员线、订单线、结算线、营销线。每一份靠谱的B2B2C清单都必须覆盖这五条线，而且每条线里都要有平台端和商家端的交错逻辑，这是和普通B2C最大的区别。以商品线为例，清单里至少有两种商品类型：平台自营商品和商家商品。它们的商品详情页结构可能相似，但库存归属、价格策略、毛利计算、售后责任完全不同，数据库表设计上通常共用一个商品主表，再用字段区分商品来源和归属店铺ID。

订单线是五条线里最容易出边界问题的。B2B2C清单里的订单类型远比B2C多：常规订单、代销订单（平台代商家发货）、分销订单、预购订单，每种订单在拆单、发货、退款上都有额外分支。如果功能清单只有“订单管理”四个字，等于没有清单，只能算是标题。会员线同样要做层切分：一套体系同时服务买家（C端用户）和商家（B端企业账号），两者注册入口、审核流程、权限模型完全是两套逻辑，但常常被初学者揉在同一个用户表里，最后只能靠角色表甚至硬编码字段补救。

结算线是五条线里最容易被忽略、但一上线就让人睡不着的部分。一个正常流程是：用户支付100元，平台收到钱，平台分账给商家80元，平台留下20元佣金，如果用户后续退款，需要先冲正分账记录再退款给用户。功能清单如果不包含自动分账、结算账单、退款冲正这类明细模块，而只是签了微信支付和支付宝，后续财务对账基本要靠人肉跑Excel。建议拿到清单时，重点数一数“结算”“佣金”“对账”“分账”这四个词出现了多少次，出现得越具体，越说明整理人真做过平台，而不是抄了一版B2C模板。

3. 从PDF清单到落地：核心模块的选型、拆分与改造成本

3.1 商品与店铺模块：字段冗余不如一个中心化SKU模型

B2B2C的商品清单在落库时的核心争议是：多个商家发布的商品要不要统一走一个SKU池？我的答案是要，即便初期商家数量只有个位数也得这么设计。出发点很简单——线上零售核心是SKU，平台端后续的类目统计、全域库存查询、跨店比价、价格预警都要靠中心化的SKU模型支撑。如果每个商家自己私有一套商品表，平台端想看全平台有多少SKU，就只能遍历商家库，这在大促场景下是典型的重型慢查询。

common做法是商家端只维护“发布商品”和“编辑信息”的交互，物理存储统一落到平台建的SKU中心表。遇到商家私有规格（比如商家自定义的定制字段），可以在SKU中心表旁边挂扩展属性表，而不是直接给主表无脑加列。库存字段要单独说：代销模式里平台要掌握真实库存，建议用库存预占接口让平台销售端减量、商家发货后做最终确认，否则促销一开就超卖。清单里如果出现“库存对接”“库存同步”这种词，我的经验是直接拉长两到四周排期，别看它短，依赖关系极多。

3.2 订单与售后模块：拆单、异常状态机与责任归属

一个B2B2C订单本质是“用户下了一个单，平台上落成多张子单”的结构。功能清单里必须包含平台维度的母订单（parent_order）和商家维度的子订单（child_order），各自维护自己的状态机。常见做法是用户在购物车勾选了三家店铺的商品，提交后按店铺维度拆成三个子订单，各自独立发货、独立售后，但支付只发生一次。如果清单里没有“订单拆分”这个细节，就要警惕是不是把B2B2C做成了简单B2C的换皮。

订单状态机建议设计成“防错最小集”：待付款、待发货、待收货、已完成、已关闭、售后中。不要扩展出太多中间态，否则每个中间态都要写定时任务去扫。微信支付/支付宝回调后锁定支付单号，再放行拆单逻辑，保证不做成“先拆单后收款”。售后模块里，B2B2C的特殊点是责任归属——C端用户发起退款后，平台要决定是直接退款还是转给商家审核，这取决于订单类型和售后原因。我的设定是：自营商品直接走平台退款，商家商品先走商家审核，超过48小时未处理自动通过。

一个被反复踩的现实问题：退款金额要回到原支付账户，这对B2B2C分账链路是个不小的负担。建议每笔售后单记录冲正对象（原订单、原支付单号、原分账记录ID），这样财务对账时能顺着售后单往回追溯，否则退款出了错只能靠翻支付平台流水定位，十分痛苦。功能清单里如果连“原路退回”都没写，尽量在技术评审阶段补上，否则后期上线财务一定会找你哭。

3.3 分账与结算模块：佣金、流转与延迟结算策略

分账是B2B2C相对B2C最复杂的模块，也是最容易出现系统性资金错的环节。正常路径描述是：用户支付100元到平台商户号，平台把可结算金额算出来，按佣金规则截留平台收入，剩余金额打入商家子账户或自动结算到商家银行卡。技术上要么用微信支付/支付宝的分账能力，要么在平台自己的账户体系里记账后发起转账。前者合规但有限制，比如部分支付方式不支持自动分账；后者灵活但要自己处理可用余额、冻结、流水这三张表，工程量大不少。

我一般建议初期直接采用支付渠道原生的分账功能，原因很简单：省了自己维护资金流水和账务差异核对的工作量。确认好平台方和商家方在支付渠道上都属于同一商户号下的不同子商户，所有分账行为都留痕可查。等到单量做到日均几千单、平台有专门财务人员后，再自建结算中心也不迟——毕竟自建系统一旦资金错账，追查成本极高，牵一发动全身。

结算频率上，建议预留“T+N”配置而不是写死T+1。有些商家资质不全，需要人工审核后才能打款；有些类目有账期政策。所以结算模块里至少要有一个可配置的结算周期表，字段包含商家ID、周期类型（按天/按周/按自然月）、冻结天数、最低可结算金额、结算状态。这个表在功能清单里经常被省略，但上线后运营基本天天要用，加一个字段简单，但一开始不设计就是事故。

3.4 会员与营销模块：统一账户体系下的多端权限

B2B2C的会员体系要区分C端用户与B端商家管理员，两者建议直接拆成两套能力，不要在一个用户表上叠加角色字段了事。C端会员维护昵称、手机号、等级、积分、优惠券；B端管理员维护所属店铺、操作权限、审核流。一套账号登录两个端也不是不行，比如手机号注册成C端用户后又申请成为某个店铺的管理员，此时两者通过union_id关联，但各自的基础表保持独立。这个设计能少掉很多权限越权的破事。

营销模块里的促销类型要分清“平台级”和“店铺级”。平台级是全场通用的优惠券、满减、秒杀，由平台出资补贴；店铺级则限定在某一个商家的店铺范围内，商家自己承担成本。功能清单里如果出现“优惠券”这类通用词却未标归属，落地时极容易权限混乱——商家能设置平台级优惠券的致命影响是活动预算失控。每条优惠券记录都要带scope_type字段和scope_value（店铺ID或全平台标识），数据权限过滤时强制拼上对应字段，防止越权创建和超额领取。

同步要考虑的是促销叠加规则，比如“满减和优惠券能不能同时用”“秒杀商品能不能用店铺券”。这类规则虽然看起来只是几个if，但如果不定义清楚，技术开发做了半截，测试阶段才发现互相矛盾，返工量极大。拿清单核对时，只看有没有一个“促销优先级配置”的描述，没有的话就在评审阶段补成需求项，否则无脑编码就是给自己埋坑。

4. 避坑：B2B2C功能清单落地时的五个典型踩雷点

4.1 供应商和自营商品在同一个商品池里互相干扰

现象：商家上架和平台自营在同一批商品上架后被重复推荐，列表里同一款商品出现两条完全一样的数据，各自价格不同，用户下单后不知道该归属到谁的库存。 原因：商品表没有设计supplier归属维度，或归属字段只是挂在扩展信息里没有进主键约束，导致商品数据检索时按类目或关键词直接翻倍查出来。 解决：商品主表必须显式包含supplier_id，除非特殊情况不做软删除。查询商品列表时背负强制条件：supplier_id = 指定值或sale_channel IN ('self', 'merchant')二选一。上架时还要校验类目下是否已有同SPU归属冲突，冲突则展示“已存在”而不是允许重复发布。

4.2 店铺独立装修与平台统一风控的权限冲突

现象：商家为了引流，在店铺首页嵌了自己的外部客服二维码，绕过了平台在线客服体系，平台无法追踪聊天记录。 原因：店铺装修功能开放了富文本自定义模块，但运营审核机制只抓敏感词，没有拦截外链和自定义JS片段。 解决：装修模块的素材统一走平台CDN，不允许商家直接传HTML和Javascript，外部链接统一用白名单域名过滤。涉及联系方式字段时，由平台统一生成模板占位符，商家侧只填内容，不填URL。功能清单里若没写“店铺装修审核流”（哪怕是自动审核），一定要在需求阶段加进去，上线后补审核就是裸奔。

4.3 佣金结算把退款和优惠券计算成一笔糊涂账

现象：财务月结时佣金总有几百笔对不上，退款订单被重复计佣或在退款时未返还佣金。 原因：佣金结算用的基数是“订单金额”，而不是“实付金额”，退款时也没有生成佣金冲正记录。 解决：统一以用户实际支付金额为佣金计费基数。实付金额 = 商品总价 - 商家承担优惠券金额 - 平台补贴优惠券金额 - 满减抵扣金额，平台佣金 = 实付金额 × 佣金率（分类目SKU）。售后确认退款后，自动生成一条负向佣金流水，把原单的已记佣金冲正。功能清单里必须包含“退款冲正”这个动作，没有就当作不可用方案来处理。

4.4 代销模式下的共享库存超卖

现象：大促时平台自营和商家各自卖同一个SKU，最后订单量超过商家真实库存，发货跟不上，客户投诉到平台。 原因：库存模型上平台和商家各管一套库存数字，没有把平台销售端的“可售库存”和商家物理库存打通，或只有定时同步没有实时预占。 解决：代销商品必须在平台库存中心维护一个可售库存字段（逻辑库存），每次平台订单生成前做预占（预占成功才放行支付链路），商家发货后把预占转成实扣，未发货的订单取消时回补预占库存。定时同步只能当兜底对账，不能作为唯一数据源。

4.5 售后责任归属不清导致用户两边踢皮球

现象：用户买了商家的商品要退货，平台客服说找店铺客服，店铺客服说退款只能平台发起，用户被晾了两天。 原因：订单归属和售后归属的规则没有切分干净，平台和商家各自的售后处理权限边界模糊。 解决：下单选门店归属商家，售后受理节点只有一端。常见做法是：平台发起原单原路退款（平台按商家保证金和货款垫付，后续与商家结算扣除），自营商户售后直接平台处理，商家店铺售后由商家审核，超过48小时未操作自动判定同意。这个“自动判责”的超时规则一定要写在清单里，否则商家每天琢磨怎么拖着不退款，平台还得自掏腰包兜底。

5. 用功能清单做技术评审：从核对表到排期估算的技巧

拿到PDF不像拿到一份需求文档，它没有优先级、没有业务规则，只是一堆模块名。我会把它转成一张“分阶段核对表”再排期。拆解方法是先给每个功能点打分：是否属于核心交易链路（订单、支付、库存、结算），是否有外部依赖（支付渠道、物流接口、短信、OSS），是否涉及资金安全（退款、分账、提现）。核心链路且高外部依赖的模块放第一优先级，其余往后排。

具体估算上，用“人月”比“人日”更稳。一个成熟的B2B2C最小可用版本，商品、订单、会员、支付四个主模块加商家后台、平台后台两个管理端，配齐审批流与基础数据统计，大约需要8到10个工程师投入5到6个月，中间还要算上一轮完整的联调对账。凡是只报3个月的，说明连分账、售后、优惠叠加规则都没有展开评估。功能清单恰好是一个很好的探针，用它去要求对方把每个模块拆成页面级描述，凡是拆不出“页面-接口-数据表-定时任务”四件套的，很可能只是拼了一个目录。

上线前的验证最好从“经济核验”开始：用录单把用户支付、平台分账、商家结算、退款冲正四个动作跑一遍，然后对账三张表看金额是否守恒。再准备两个商家两个SKU，分别从自营和代销两个入口下单，覆盖拆单、预占库存和佣金比例变更三种场景。这套动作跑完了，系统的大坑基本都填得差不多了。功能清单这种东西，不是用来背诵的，是用来做校准。把每一行都问一遍“谁在用、怎么触发、失败怎么办”，这套平台的架构才不会在交付三个月后让技术部集体救火。最后分享一个我的习惯：每次评审完这类清单，都会顺手在末尾标一版“本次不做的功能”，把边界写清楚才不会越做越膨胀，希望帮到你。

本文还有配套的精品资源，点击获取