简介这是一份B2B2C电商平台的功能清单文档面向电商产品经理、系统开发人员及平台运营者可用于需求梳理、功能规划与开发排期参考。文档按交易中心、消费者界面、商品搜索、商品列表页、商品详情页、购物车、订单管理、会员中心、账户管理等模块展开详细罗列每项功能及子功能并补充后台商品管理、文章公告、友情链接等模块说明适合作为搭建或优化B2B2C平台时的功能对照清单。资源包为单个doc文件约559KB内容为完整的功能列表与模块说明便于离线查阅与团队协作使用。目前已有182人浏览学习适合正在设计或评审电商平台功能架构的读者快速获取结构化参考信息。1. B2B2C电商平台功能清单还没写代码就要先过审的那份文档一份B2B2C电商平台功能清单难点从来不在功能多而在你要同时管理两拨人商家和消费者、一摊钱货款、佣金、退款和三个不一样的后台平台运营端、商家端、用户端。B2B2C模式下平台自己不直接卖货货由商家发、价由商家定、售后大部分也由商家接所以平台方要建的是一套规则和一套市场而不是一套货架和仓库。这份doc能解决的是开工前的三件事把需求范围钉死让产品、研发、测试对“做哪些功能”没有歧义把版本边界划清让第一版只做能收钱的事把责任角色挂到每行功能上谁发起、谁审批、谁执行一目了然。它不是PRD不是原型图更像一份带着权限和状态的定义表。适合读这篇的人包括正在从0搭平台的团队负责人、被要求“两周出方案”的产品经理以及做电商软件外包时被客户一句“功能就是别人有的我都要”逼疯的需求分析师。下面的章节从怎么拆清单讲到怎么用它排期验收按我的习惯顺序走一遍。2. 拆功能清单的三个维度角色权限、主链路和状态机我第一次做B2B2C平台时按传统B2C的模块表去列功能结果商家后台那部分全是空白。B2C是一个角色平台服务一类用户B2B2C是平台服务和赋能另一类商业用户。所以清单必须先从角色拆再用链路串最后用状态机校准。这三步顺序不能反。2.1 角色维度平台、商家、用户三张桌子各放什么先按角色把功能分成三大块。平台运营端负责招商、入驻审核、类目管理、商品审核、活动配置、仲裁处理、数据看板商家端负责店铺管理、商品发布、订单发货、售后处理、结算对账、经营报表用户端负责浏览搜索、下单支付、订单查询、售后申请。三块之外还有公共能力包括支付、短信、消息中心、风控、文件存储这些不属于任何角色但谁都依赖。表格里先按角色把模块名放好再往下拆功能点角色核心诉求功能模块平台运营端招商、管商家、管交易规则商家入驻审核、类目管理、商品审核、活动管理、仲裁后台、结算复核、数据看板商家端开店、卖货、收钱店铺管理、商品管理、订单处理、售后处理、结算中心、经营报表、客服用户端找商品、下单、收货搜索列表、商品详情、购物车、下单支付、订单中心、售后申请、评价角色拆完要马上检查数据隔离商家只能看到自己的商品和订单平台运营看全站数据但改商家数据要留痕。清单里每一行功能都要标“谁看、谁能改、谁能审”不标这三项后续做权限矩阵时全是吵架。提示商家端和用户端别共用电商品文案字段。商家端写“发货”用户端写“卖家发货”两边字段名和状态名不一致接口联调时全是误会。2.2 链路维度商品、交易、结算三条主线怎么串三个端口的菜单是按角色拆的但业务流程跨角色跨端所以第二步要把链路串起来。商品链路商家新建商品→平台审核→上架→修改再审核→下架交易链路用户下单→支付→商家发货→用户确认→完成或售后结算链路订单完成→生成结算单→商家核对→平台复核→打款。每条链路要在清单里标出四个要素发起角色、审批角色、超时动作、通知对象。以订单为例状态由谁触发超时动作通知对象待支付用户提交订单24小时未支付自动取消用户已支付/待发货支付回调商家48小时未发货提醒商家已发货商家点击发货15天用户未确认自动完成用户待收货物流签收签收后7天自动完成用户链路写完后要检查断点。比如订单完成后结算单由谁触发生成是定时任务还是人工操作又比如商家发货后用户一直不确认订单什么时候自动完成。这类边界值清单里不写开发就按默认0天处理上线就等着售后翻车。2.3 状态机维度清单里每类对象都要写清“下一步能变到什么”功能点的关键字段除了名称和是否必填还要包含状态集合。商品的状态至少有草稿、待审核、审核驳回、待上架、已上架、已下架、售罄、违规下架订单状态在2.2已经列过结算单还要有待确认、已确认、待打款、打款中、打款失败、已打款。如果清单里不写状态开发建表时就少了枚举字段后期补状态字段是最疼的返工之一。我的习惯是新增一个功能点时先问自己一句这个对象会不会有生命周期有就顺手把状态列出来。哪怕拿不准也先写“待定”让开发知道这里有个坑要一起填。清单里最怕的不是状态写错而是一个状态都不写让开发自己发明一套最后跟产品对不上。3. 核心模块功能点详拆商品、交易、结算与售后的可写参数维度拆完后要把功能点落到字段级这才算可执行的清单。商品、交易、结算、售后这四个模块是B2B2C平台的主干也是最容易写含糊的地方下面逐个拆。3.1 商品模块先分SPU和SKU再列字段平台的商品模型比自营复杂因为同一个商品是商家录入、平台审核、用户购买字段要分两层定义。SPU是抽象商品SKU是具体规格。清单里先分这两层再逐层列字段层级字段说明SPU商品标题、品牌、类目、图文详情、主图视频商家填写平台审核SPU审核状态待审/通过/驳回/违规下架SKU规格组合颜色/尺码等、价格、库存、SKU编码、条码、重量商家维护价格库存高频变动SKU改价阈值单次改价超过30%触发平台二次审核为什么必须拆两层商家要“批量改一个商品的颜色文案”操作挂SPU层要“按规格调库存”操作挂SKU层。不加区分开发就会把每个规格当成独立商品商家改起来逐个点后台体验直接废掉。审核流程也要在清单里写明商家提交SPU含全部SKU平台审类目和资质SKU日常改价走商家自己审核超过阈值才触发二次审核。3.2 交易链路订单字段与状态机写不到“取消”就是返工订单模块的“取消”要拆成至少四类用户未支付取消、超时自动取消、商家拒绝发货取消、平台仲裁取消四类对应的退款路径不同。清单里如果只有一个“订单取消”功能点开发就只能自己猜逻辑猜错就是资损。金额结构字段必须拆细商品总额、运费、商家优惠、平台优惠券、平台补贴、实付金额。为什么拆这么细因为结算时要分清每笔优惠的钱谁出。清单里别写“优惠”两个字了事写不到这层结算模块上线一定会吵架。订单还要强制加上“商品快照”字段。商家改SKU价格或删除SKU不能影响历史订单的金额和商品信息快照字段是硬需求不然后台一改价历史订单金额全变财务直接炸。3.3 结算模块佣金与退款分摊的公式要写在清单里结算模块是整个清单里最不能含糊的部分。常见做法是直接在清单里写清公式结算金额 订单实付金额 - 平台佣金 - 营销费用分摊 - 退款冲正 平台补贴。然后逐项解释佣金按类目比例还是固定抽成是否有保底佣金营销费用分平台券和商家券谁发券谁承担成本退款冲正指订单退款后已结算的佣金要原路扣回。结算流程按步骤写进清单步骤动作责任人1订单完成且售后期结束生成待确认结算单系统定时任务2商家核对结算单明细商家财务3平台复核确认佣金和分摊平台运营4发起打款记录打款流水系统5打款失败自动重试并通知系统结算周期也要在清单里定义T1、周结还是月结对商家的体验差异很大。这个字段要跟平台财务的节奏对齐功能清单阶段就把它定死别等开发完再改。3.4 售后与仲裁把“平台介入”拆成可执行步骤售后类型分三种仅退款、退货退款、换货。清单里分别列流程和时限比如仅退款是“用户发起→商家48小时处理→同意则自动退款→拒绝可申请平台介入→平台1个工作日内判定”。三种类型的差异点放在一张表里类型商家处理时限超时动作退款路径仅退款48小时超时自动同意原路退回退货退款72小时超时自动同意退货商家确认收货后退款换货72小时超时自动同意换货商家重新发货平台介入不能只写“平台介入”四个字要拆成五件事介入条件、判定权限、判定结果、资金动作、通知对象。介入条件是商家拒绝或超时判定权限是客服可判全额退超过5000元要主管复核判定结果分为全额退、部分退、拒绝退款资金动作包括原路退回、扣商家保证金、冻结订单通知对象是用户和商家双方。这五列写出来开发才能排期产品才能验收。4. 从功能清单到版本排期MVP判据、版本切分和估时策略清单写完了下一步是把它变成能排期的东西。功能清单的价值就在于它能直接转化为版本计划和估时依据而不是躺在网盘里的文档。4.1 MVP判据砍掉这一项生意还转不转每一行功能点后面放一个判据砍掉这个功能后商家还能不能开店卖货用户还能不能下单付款平台还能不能分清钱并抽到佣三个回答都是“是”就可以砍。入驻审核、商品发布、下单支付、订单处理、商家发货、基础售后、结算这些是骨架砍了平台不成立商家店铺装修、营销工具、数据报表、积分体系、拼团秒杀第一批全部后置。我给过不少项目的建议是MVP不是功能最少的版本而是“钱能走通”的版本。钱走通的标准是用户付款后平台知道该扣多少佣金商家知道该收多少钱两边对账能对上。对不上账的MVP只是Demo。4.2 版本切分顺序先交易闭环再结算后营销版本切分按依赖关系走不要按模块好不好做走。常见做法是这样排版本范围交付目标V0.5账户与权限、商家入驻、商品管理SPU/SKU商家能开店并上架商品V1.0用户端、购物车、订单、支付、商家订单处理、用户售后、基础结算完成交易闭环和资金闭环V1.5平台仲裁、营销活动、优惠券、结算单对账导出平台具备运营和仲裁能力V2.0数据报表、店铺装修、消息Push、商家精细化工具增长和体验优化交易准确性优先营销是放大器。营销放大了准确交易才是增长放大了错误交易就是事故加倍。V1.0里不碰营销因为优惠分摊会直接影响结算公式两件事一起上出了问题都分不清是交易bug还是营销bug。4.3 工作量预估给每一行功能点打上T恤码每个功能点打一个T恤码S、M、L、XL对应标准人天尺码参考人天典型功能S1-2人天单个枚举字段、简单列表页M3-5人天单个CRUD接口加页面、普通表单L2周内订单状态机、结算规则、带审核流程的功能XL1个月起支付渠道接入、活动引擎、报表系统打码规则我一般是定死的同一个评估人统一打码避免两个人对“M”的理解差一倍带审核流程的功能至少算两个角色的工作量开发联调涉及支付和结算的模块最少打L。估时是最接近玄学的事但可以让它少一点玄单人估时乘以1.3作缓冲有外部依赖的乘以1.5。这两个系数别让客户看到属于团队内部的血泪经验。5. 功能清单落地避坑五条踩过坑和解决方式功能清单写没写到位上线后都会现形。下面五条我基本都踩过一遍每条按现象、原因、解决写清楚照着排查能省下一轮返工。5.1 结算只写一句话上线第一天对账不齐现象第一版结算上线对账平台怎么都对不上差了十几笔退款订单的佣金。原因结算清单里只写了“订单完成平台扣佣金后打款”没写退款订单如何冲正、优惠分摊怎么回滚。退款订单的佣金被原样算进了结算单商家多扣了钱。解决把结算模块拆成四块来写结算基数实付金额、分摊规则优惠谁出、扣款项佣金与退款冲正、打款状态待付、已付、打款失败重试。每张结算单保留原始订单号关联退款发生时能反向找到对应结算单做冲正。5.2 权限只写“可见”不写“可操作”商家误入后台乱改现象商家账号能进平台运营后台的部分页面运营账号误改了商家的商品价格。原因权限清单只写到菜单级“可见”没写到操作级。开发默认给了同一个角色组合的读写全开权限商家和运营的按钮全亮着。解决清单里每个模块加五档操作权限列增、删、改、查、审分平台、商家、客服三套矩阵。商家在自己的店铺域内可写跨店铺一律只读审核权限单独给平台运营。5.3 营销叠加顺序留白周年庆客诉瞬间爆表现象周年庆活动上线满减、平台券、商家券同时作用用户结算页看到的金额和平台对账单对不上客诉量直接爆表。原因营销模块清单里只列了“优惠券、满减”两个功能点没定义活动叠加顺序。促销引擎不知道先算哪个各个优惠的实摊金额就对不上。解决在功能清单里写死叠加规则平台级优惠优先于商家级优惠单品折扣最后计算同一个订单里同一类型优惠只取力度最大的一项。结算公式里的优惠字段必须能拆分到每一笔来源平台一张表、商家一张表。5.4 SPU和SKU混成一个词商家改规格全靠逐个改现象商家反馈后台改一个商品的颜色文案要进到每个规格里逐个改两个规格改一下午。原因商品清单里只有“商品”一个字段没拆SPU和SKU。商家和开发都把每个规格当成了独立商品批量修改无从谈起。解决商品模块按SPU标题、详情、主图加SKU规格、价格、库存、编码拆分所有涉及批量修改的需求挂在SPU层价格库存挂在SKU层。后台每个列表页都标清楚当前操作的是SPU还是SKU。5.5 提现账户不做校验财务合规过不了审现象商家绑定结算账户时填了个对公账户提现审核过不了项目卡在财务侧上线前。原因结算账户功能在清单里只有“绑定银行卡”一行字没写账户类型限制和实名校验平台财务不接受无校验的账户绑定。解决清单里补四列账户类型对公、对私、开户名校验、实名认证、打款失败重试机制。商家提现流程前加审核状态机账户绑定审核通过后才能发起提现。6. 把功能清单当成验收工具走查、回归与复盘功能清单不只在开工前有用它还能变成验收工具。这里说一个我一直在用的方法。6.1 角色扮演走查按用户旅程过一遍清单不写代码、不开页面一个人当用户一个人当商家一个人当平台客服按订单全流程走一遍清单。用户下单商家发货平台抽佣用户退款商家拒绝平台介入。每走一步对着表格问一句这一行写清楚了没有状态能不能从当前流转到下一步。发现断点当场补这种走查成本极低半天能过完整个主链路比上线后造数据测Bug省得多。6.2 迭代后对清单打勾分“未做、做偏、做多”三类每个迭代结束拿着最初的doc版本逐行打勾。未做标注砍掉的理由做偏核对是需求变更还是实现偏差是偏差就立刻纠正做多检查开发私自加的功能评估是隐藏需求还是多余设计。这样清单就变成了活文档是下一轮评审的基线而不是躺在网盘里的死文件。我吃过一次亏清单里把售后仲裁只写了“平台介入”四个字开发阶段才发现这四个字背后是订单冻结、保证金扣减、人工客服、通知联动四件事3天排期硬生生拖成了两周。从那以后我养成了一个习惯每写完一行功能问自己一句这行字够不够让一个陌生开发一次写完不返工。不够就拆写着费劲说明还没想明白。B2B2C的功能清单不怕厚怕的是每行都含糊。希望帮到你。本文还有配套的精品资源点击获取