看店通：多平台商品库存默认共用

对比说明： 本文基于公开产品定位与看店通项目交付经验做场景化对比，不针对任何厂商做恶意贬低；各产品能力会随版本迭代变化，立项前请以官方资料与书面报价为准。看店通同时提供模板化与定制交付，更适合按「场景匹配」而非「绝对好坏」做决策。

按目标选平台

同时铺开微信、抖音、小红书、支付宝、百度等多端，最容易导致运营失焦与库存撕裂。建议默认策略：1 个主阵地 + 1 个辅阵地，先把交易、履约、售后与会员做稳，再用已验证爆品放大到第二端。下文给出按目标选平台、90 天验证步骤与系统优先级。

私域复购、社群优先微信小程序与企业微信，系统重心是会员、优惠券、SOP、标签。内容爆发、直播优先抖音小程序或快手小程序，系统重心是直播价、库存、售后 SLA。信任种草、搜索优先小红书，重心是笔记承接、详情一致、私域导入。支付与生活服务优先支付宝小程序。搜索意图、信息型可看百度智能小程序或微信搜一搜，重心是 SEO、落地页、转化组件。

决策四步：画出用户从认知到信任、首单、复购的路径，标注每一步所在平台。选主阵地并设定 90 天可量化指标（首单成本、退货率、复购率），而非只看粉丝数。系统先打通商品、订单、会员，再叠加复杂营销与分销。辅阵地只做「主阵地已验证 SKU」的放大，避免从零复制一套运营。

不同平台应当区分 KPI：抖音侧重内容产出与投放效率，微信侧重 LTV 与复购率，小红书侧重从种草到成交的转化率。同一个团队若把 KPI 混用，容易出现为了短期数字刷量、却损害长期品牌的情况。设定 KPI 时建议配一个「不看什么」的清单，明确哪些指标在该平台不作为考核依据，例如不用微信的复购率去要求抖音、也不用抖音的 ROAS 去要求小红书。同时为每个平台指定唯一负责人：内容排期、库存申请与客服话术都由他统一对外，避免一个平台三个人发声、供应链无所适从。

中台优先级与主数据治理

P0：统一 SKU、可售库存、价格体系、售后工单。P1：会员 ID 映射、券与积分规则、渠道报表。P2：全渠道分销、复杂结算、BI 自助分析。

落实 P0 时，下面五项主数据必须先有统一定义，否则每增加一个平台，误差都会被乘一次。SKU 编码规则与条码，含组合装、赠品、换新件的编码方式。可售库存的定义：在途、锁定、残次、门店自有库存分别如何计算。价格类型：零售价、会员价、渠道价、直播价，以及它们之间的优先级与互斥关系。会员 ID 与手机号的映射规则，含一人多号与手机号变更的处理方式。售后原因码与责任方划分，各平台必须共用同一套枚举值。未完成 P0 就急着增加新平台，结果通常是每一端都「有自己的一套表格」，最后哪个数字都不敢用。

最常见的三类错误是：库存尚未统一就开直播，导致超卖与临时取消订单；内容端的承诺与商品详情页不一致，退货率与差评同时上升；多平台客服话术不统一，同一个问题在两个渠道得到两种答复。这三件事的共同点是——它们都不是「平台选错了」，而是主数据与流程没有先对齐。还有一类隐蔽的错误：把辅阵地当成主阵地来投人力，却仍用主阵地的 KPI 考核它。辅阵地的任务是放大已验证的 SKU，不承担从零试错的职能；若给它设定和主阵地一样的增长目标，团队只能靠低价冲量，最终反噬主阵地的价格体系。

行业倾向仅供参考：美妆护肤常见主阵地是小红书加微信，辅阵地用抖音测爆品。休闲食品常见主阵地是抖音或快手，辅阵地做微信复购。家居大件常见主阵地是微信加内容，辅阵地是小红书场景笔记。本地生活常见主阵地是微信或支付宝，辅阵地是抖音本地推。

验证、供应链与扩张条件

主阵地选定后，先把假设写成可证伪的句子，例如「30 日内私域首单获客成本低于某个金额」「首月退货率不超过某个比例」。每周复盘履约时效、退货率与客服满意度，达不到就调整货盘或暂停扩平台，而不是盲目再加一端。

验证表建议只填四列：假设、当前值、目标值、下一步动作。第 30 天做第一次中期检查，若三项假设中有两项明显偏离，直接调整货盘而不是加投放；第 60 天确认履约与客服能否承接当前单量；第 90 天做去留判断。每次复盘都要留下书面结论与负责人，否则三个月后没人说得清当初的目标是什么。

多平台扩张之前，如果 ERP 尚未上线、库存仍靠手工表格维护，应当先治理主数据。否则每增加一个平台，误差就被乘一次，财务对账迟早会拖垮运营。合理的顺序是：先上 ERP 或至少建立统一库存表，再开第二个前端平台，而不是同时开三个前端。否则每个平台都会要求「先卖了再说」，财务对账将长期停留在手工阶段，管理层也无法信任任何一张报表。换句话说，平台选择应当服从供应链的成熟度，而不是反过来倒逼供应链。

大促前不建议新开平台，也不建议大规模修改价格规则——两件高风险的事不要撞在一起。辅阵地的扩张应安排在淡季，并用 90 天验证表衡量是否值得保留。更严格一些，建议同时满足以下四个条件才开新平台：主阵地 90 天 KPI 达标、库存与售后 SLA 稳定、团队有人力冗余或已招到专人、新平台承担明确角色（获客或放大，而不是重复现有职能）。否则新平台只会分散素材与客服，GMV 不增反降。系统层面，开新端之前还要检查接口限流、商品同步延迟，以及退款规则是否与现有平台一致。支付宝小程序、百度智能小程序作为辅阵地时，往往服务特定人群或搜索场景，不应与微信简单复制同一套活动页。

每增加一个主级平台，通常意味着多一套内容节奏与一个客服峰值。请在预算表中单列「平台专属人力」，与软件费用并列，而不是混在一起看总数。若人力无法增加，应当缩小平台数量，而不是缩减软件预算。看店通这类系统可以复用同一个后台，但复用不了抖音的短视频脚本与微信的私域 SOP——这是组织成本，不是采购一份授权就能解决的。每新增一个平台，还应更新一次组织 RACI：谁对库存负责、谁对内容负责、谁对客服负责、谁有权改价。职责不清时，跨平台的库存与价格问题会在大促当天集中爆发。此外，主阵地负责人应在周会上拥有优先排期权，避免辅阵地活动挤占库存与客服资源，导致主阵地 KPI 下滑。中台项目与平台扩张也建议错峰推进，避免同时改流程又改组织。

常见问题里有两个几乎每次都会被问到：支付宝小程序和微信小程序都要做吗？取决于目标用户的支付习惯与平台补贴力度，不必默认全开；百度智能小程序有没有价值？当业务的搜索意图很强时，可以作为辅阵地承接搜索流量，但不适合作为从零冷启动的主阵地。每个季度建议问四个问题：主阵地 KPI 是否仍然领先；辅阵地带来的是增量还是分流；库存与客服有没有被新平台拖累；下个季度是否值得开第三端。若其中两个问题的答案为否，应当暂停扩张而不是加码投放——平台选择是动态决策，不是一次招标定终身。新平台试点也要设明确的退出标准：90 天未达成假设就归档经验、停止投入，而不是无限延期；试点结论写入知识库，供下次选型直接引用。

结论其实很朴素：少即是多，主阵地做深，辅阵地做放大，系统与中台的投入优先级都应服务于这条原则。平台选择没有「满分答案」，只有「当前资源下的最优解」；主阵地策略不是不扩张，而是把扩张时机与验证数据绑定。建议把「暂不做的平台」与理由一并写下来，并注明当时的数据假设，既能防止组织内反复争论已被否决的选项，也便于半年后在新数据下重新讨论，而不是因人事变动重复踩坑。系统与中台的投资应当领先平台扩张半步，而不是滞后半年去补救。

新闻来源：https://www.kandiantong.com/compare/platform-selection.html