一家3C批发商向经销商供手机，销售口头说“X1有货”，客户下单后却发现要的是黑色128GB，仓里只有黑色256GB和蓝色128GB。客服随后按“X1总库存”回复能交货，仓库只好临时换货；更麻烦的是，经销商原本有指定价，活动期间其中一个颜色又有促销价，订单金额和双方谈过的不一致。这里的核心问题不是商品页图片是否好看，而是型号、颜色、容量对应唯一可交易SKU，客户身份对应本次价格，订单逐行对应真实可发货物。这三件事没有同时成立，表面上越快下单，售后纠纷越容易放大。
下文用X1手机三个示例规格说明：黑色128GB、黑色256GB、蓝色128GB。经销商A订12台、8台、5台；仓库同规格可用量为10台、8台、5台。因此只有黑色128GB少2台，其他两行可以核准。所有型号、编码、价格与数量均是说明业务规则的演示数据，不代表真实产品、活动或系统预置价格。企业应以自己已启用的商品、客户政策和有效库存核对。
先建立不可混淆的SKU，而不是一个“X1手机”笼统商品
商品管理员要把品牌型号、颜色、容量、版本、包装和保修条件写成可识别的规格。黑色128GB与黑色256GB可以同属X1型号，但库存、订货和价格必须能按各自SKU区分；蓝色128GB也不能因为容量相同就合并到黑色。示例用X1-BK-128、X1-BK-256、X1-BL-128三个内部编号。编号不一定照这套命名，关键是同一编号不能在今天代表黑色128GB，下个月又被改成蓝色128GB。停售旧规格可以停止下新单，但历史订单仍要查得到原编号和当时的客户承诺。
图1：同型号的三种颜色容量组合分别有SKU和现存量；黑色128GB订12台、可用10台，缺的2台不能用另两款静默替代。
建档时先查重。若系统里同时出现“X1黑128”和“X1 128G黑色”，商品管理员要确认是否同款、是否同一版本，不能只凭名称相近就合并库存。若一个是国内版本、另一个是其他区域版本，保修、包装或认证不同，更应在规格中明确。3C行业还有序列号、批次与激活状态等商品特性；企业如果对客户承诺追溯，仓库出库时要把实际实物与订单规格对应，不能用SKU总数代替逐台实物核查。配件、赠品和延保也要有清楚的商品或服务承诺，不能只写在销售的个人聊天记录里。
“一台”“一箱”的单位关系需要依据真实包装建档，但本篇示例订单按台销售。假如供应商以十台一箱采购，仓库以台核库存，换算必须事先确认；箱价可能有渠道优惠，不可因十台一箱就把箱价机械设为单台价的十倍。旧箱规变更时，不要直接改历史SKU换算，先看未完采购与订单，再明确新箱规何时生效。把饮料瓶箱示例直接搬到手机SKU上，反而会掩盖本篇最重要的颜色容量区别。
渠道价格先看客户是谁，再看这款SKU是否命中更具体规则
经销商、零售门店和大客户可能看到不同商品范围及交易价。示例中黑色128GB基础销售价为2199元，经销商A对应的等级价1999元，A另有有效指定价1950元；某活动期内这款SKU满足促销条件，成交价为1899元。业务上可按已配置的优先顺序核促销价、客户指定价、客户类型等级价和销售价，但每一层都要检查适用客户、SKU、时间、门槛与是否可叠加。不能把黑色128GB的1899元活动价套到黑色256GB或蓝色128GB。若该活动已经结束，就要回到下一项仍生效的价格规则，而不是沿用客户上周看到的截图。
图2：图中只演示黑色128GB的四层价格与本次活动命中；实际结算以企业启用的规则和订单行最终成交价为准。
销售给客户报价或代客下单时，应切到该客户的身份核价。若员工自己的账号看到的是普通销售价，却用口头承诺经销价，客户提交后金额不符，往往不是订单金额计算错，而是客户归属、客户类型或指定价生效范围未维护正确。修改价格前先检查是否已有客户确认的报价和未完订单，避免活动取消后把历史订单也“改回”基础价。财务对账要以原单成交价、优惠及实际履约为准；采购成本和其他客户的价格不应出现在给经销商的单据里。企业可以用一位经销客户、一位零售客户、三个SKU做试单，逐行比对商城可见价、代客订单价与管理端订单明细，再放开全量客户。
手机商城下单要让客户看清“哪款、多少钱、能否按时交”
客户在手机商城选择X1时，商品页至少要能识别颜色、容量、当前可订单位和本客户生效价格。下单前，采购员不能只看商品主图；应在购物车逐行核黑色128GB十二台、黑色256GB八台、蓝色128GB五台，并核收货地址、发票或账期约定、交货日期。销售代客下单使用相同SKU资料，最终订单应给客户确认。若客户语音说“黑色二十台”，采购员要追问容量分别是多少，不得按自己经验拆成十二台128GB、八台256GB。这种拆分属于本文演示，只有客户确认后才成为真实订单。
为说明逐行金额，假设本次A客户黑色128GB命中1899元促销价，黑色256GB有效成交价2299元，蓝色128GB有效成交价1999元。订单三行金额分别为12×1899＝22788元、8×2299＝18392元、5×1999＝9995元，合计51175元。若第二行或第三行还有其自己的优惠，应在对应SKU行重新计算，不能沿用此演示金额。提交后管理端应核客户、具体规格、数量、单价、总额与承诺交期；系统记录的订单金额是复核结果，不是销售无需确认活动资格的理由。
图3：示例订单分别核12、8、5台的价格与行金额，总额51175元；活动只作用于符合条件的SKU。
客户如果通过微信提出改容量或改颜色，销售要把变化落到订单的具体行和客户确认记录，再检查价差、库存和交期。不能在原单仍写“黑色128GB”时，让仓库按聊天截图改发“黑色256GB”；也不能为了早日显示订单完成，把未到货的2台先算入出库。经销商店员与老板可能共用一家客户资料，但谁提交、谁确认变更、谁有权限接受价差仍应按企业账号和岗位规则留痕。客户可看见自己的交易记录，供货方则可按客户和SKU复盘销量与异常，而非只统计笼统的“X1卖了25台”。
仓库只按已确认SKU拣货，少2台必须进入客户承诺处理
仓库核库存时，黑色128GB订单12台、合格可用现货10台，差2台；黑色256GB八台对八台、蓝色128GB五台对五台。若仓库里另有二台黑色256GB，也不能拿来填黑色128GB的缺口。采购员先看同规格在途是否真实可在承诺日前到货；若能到，按原承诺交齐；若不能到，销售应把情况告诉客户，提供分批发10台后补2台、整行改期，或客户认可的替代三种选择。替代要明确容量、颜色、价差和交期，并得到客户确认，不能让仓库自行决定。
图4：缺2台时保留原单的已发与待交；等齐或替代都要重新确认承诺，不能把其他SKU库存算作这款现货。
若客户选择先收10台，本次出库写黑色128GB实发10台，原行还有待交2台；其余两个SKU可按实际拣货出库。客户签收后，订单视图应能分清已出库、已发货、已签收和待交，客服才能回答“还差的两台何时到”。如果客户改成黑色256GB，实际订单行、价格和拣货单都要按变更后的SKU核对，历史承诺与差额要能回查。商品若带序列号或批次管理要求，仓库在本次出库和售后退换中要保留对应关系；外箱数量与可发单机数量也不能混算。特殊赠品如充电器、保护壳或安装服务，要跟着相关订单行传给仓库与客服，避免销售承诺到了履约环节就消失。
退换与对账回到原SKU和原订单，不靠改商品名称消差
客户签收后发现一台黑色128GB外观受损，售后应核原订单、出库商品与该台实物，再决定换货、退货或退款。不能直接把库存从黑色128GB挪到蓝色128GB，让报表看起来“总台数没变”。更不能把受损退回的实物立即当成可售现货，提前对其他客户承诺。客户应收按原单成交金额、有效交付与退换结果核对；若那2台尚未交付，是否能收相应尾款要看双方约定，不能只看订单主状态。供货方采购结算则回到供应商实际到货型号和质量差异，客户销售金额与供方进货价分别保留。
老板看3C业务，除了“X1卖了多少台”，更要按SKU看缺货率、错发退货率、活动价毛利、渠道客户复购和待交数量。黑色128GB常缺而蓝色128GB积压，可能是采购结构偏离需求；促销让订单量升高但毛利过低，可能是折扣范围或客户价冲突；频繁因颜色错发退换，说明商品图与规格文字、仓库货位或拣货复核需要改进。每项判断都要能回到对应客户、SKU、订单和出库，而不是只凭销售的一句“这个型号很好卖”。
用三款SKU和两类客户先验证，再复制到整个3C货盘
试运行先选上面三款规格和两类渠道客户。让经销商A在手机商城查看各自价格并提交一笔包含三行的订单，再让销售用代客方式核同一客户是否看到一致的SKU与价格；零售客户用自己的账号看相同SKU，验证权限和等级价没有串。仓库模拟黑色128GB少2台，检查是否能明确待交行、客户变更确认和本次实际发货；售后再模拟一台损坏退回，检查商品与应收是否仍能对上原单。如果这五个环节都要靠微信群截图补解释，说明资料或流程尚未打通，不适宜一次上线几千个颜色容量组合。
上线后再按每日活跃SKU和主要渠道分批扩展，每新增一批先检查重复编码、停用规格、客户价格有效期和库存可用口径。系统能把已确认的商品规格、客户价、订单与履约关联起来；对版本差异、保修承诺、活动方案和替代授权，仍须商品、销售、仓库与客户共同确认。3C交易的效率来自“选中的就是要发的、展示的就是可成交的、承诺的就是能解释清的”，而不是把下单按钮做得更快。
下一步学习
要落地，可继续查看商品多规格与SKU档案、客户类型和指定价、促销价格、手机商城选规格下单、订单审核、仓库出库以及退换货的操作文章。先验证一笔正常订单和一笔缺货订单，再扩大到更多型号、颜色和渠道客户。