# MatrixFlow 电商运营手册：完整资料 > 面向多店铺电商团队的操作手册：订单核对、商品上架、库存与超卖、退换货、每日检查与环境交接，强调字段完整和页面读回。 更新日期：2026-10-18 ## 订单只读核对：保留订单号与 SKU 的前导零 URL: https://commerce.matrixflow.cn/guides/orders-audit/ 摘要：订单核对的完成标准是得到指定范围内可复查的订单记录，而不是打开了订单页。订单号、SKU 和运单号都按文本保存，000031 不能变成 31；页面未加载完整时应报告缺口。 ### 核心结论 - 订单核对的完成标准是可复查的记录，不是打开订单页。 - 订单号、SKU、运单号按文本保存，000031 不能变成 31。 - 分页、重复项和缺失项要单独列出，不能把空列表当成没有订单。 ### 开始前写清范围与只读约束 任务单应包含店铺身份、目标环境、订单时间范围、状态筛选、所需字段及导出位置。把“检查订单”具体化为“读取 QA 店铺今天的待发货订单，保留订单号、SKU、金额、币种、状态，不修改订单”。日期需要同时明确店铺时区和统计截止时间。 进入后台后先核对店铺名称与当前账号，再检查筛选条件。只读任务无需点击发货、退款、取消或保存按钮；出现需要提交的弹窗，应退出该操作并记录原因。 ### 字段按原样读取，显示值与计算值分开 编号字段始终当作文本。示例订单应保存为“订单号 000031、SKU 00128、金额 129.90、币种 CNY、状态 待发货”，不能根据外观把编号转为数字。金额同时保留原始显示文本与用于合计的数值，避免丢失小数位或把不同币种相加。 同一订单有多件商品时，每件商品保留独立 SKU 和数量；订单总额不要在每一行重复计入合计。商品退款、部分履约与订单总体状态应使用不同字段表达。 ### 核对分页、重复项与缺失项 读取前记录页面总数与当前筛选；读取后用订单唯一标识去重，并核对已读取数量。若页面显示 38 条而只得到 20 条，结果必须写明还缺 18 条，继续检查分页或滚动加载，不能把第一页当作全部。 对空 SKU、缺失币种、无法识别的状态建立异常清单，保留页面链接与读取时间。登录失效、验证码或加载错误属于未完成范围，不应通过猜测补齐数据。 - 每条记录附店铺、筛选范围、读取时间和可回访的订单入口。 - 只对确认可重复的页面读取重试，不重放任何订单写入。 ### 交付表格，也交付核对结论 交付时同时说明原始条数、去重后条数、异常条数与未读取范围。导出后重新打开文件，确认 000031 和 00128 仍保留前导零；优先使用明确设置为文本的表格列，不能依赖使用者导入时自行猜测。 成功标准是目标身份正确、指定范围覆盖完整、字段原样保留、没有状态变更，并且文件可读。任一条件未满足，就标为部分完成并列出下一步，不能仅用“已核验”替代明细。 ### 对照平台导出结构和读取范围 不同平台订单导出列名、拆分方式和付款字段并不相同。以 Shopify 为例，官方订单 CSV 文档说明，一个订单包含多个商品时，额外行项目会以独立行展示，部分重复订单字段会留空。核对前要先确认当前平台导出说明，并区分“订单数”“行项目数”和“付款交易数”。 若平台支持按日期或当前筛选导出，把导出条件连同文件名、店铺、时区和生成时间记入记录。订单列表页的显示条数与 CSV 行数可能由于多商品、分页或导出任务未完成而不同，应先解释差异，再结论。 - 原始文件只读保留，分析列放在副本中。 - CSV 中逗号、双引号和换行按标准规则解析，不能简单按逗号拆行。 - 用唯一订单号与行项目 SKU/数量一起核对。 ### 用前导零样例做交付前验收 用虚构记录 `000031,00128,129.90,CNY,待发货` 测试整条导出、导入和保存路径。对比原 CSV 与交付表格里的订单号、SKU、金额字符；如果 000031 变成 31，说明表格软件把文本猜成数字。修复方式是导入时明确列类型为文本，或使用可保留原值的格式，而不是事后补零猜长度。 合计金额时先按币种分组，并说明是否含税、运费、退款或折扣。不能把 USD 与 CNY 汇总成一个“总金额”，也不能把缺失状态当成零。报告展示原始行数、唯一订单数、重复和异常数、未读页数。 - 示例数据为虚构演示，不代表真实订单或客户案例。 - 复核输出文件后再交付，并验证编码、列名和前导零。 ### 这份指南配套工具的本地测试范围 本站订单 CSV 检查器的解析与校验函数在 2026 年 10 月 16 日运行了 7 项相关回归测试，全部通过。测试覆盖 UTF-8 BOM、CRLF、带逗号和转义双引号的字段、字段内换行、空行与末尾空列、格式错误的引号、前导零和小数文本保留、重复订单号与 SKU、列数错误、金额与币种格式，以及多 SKU 订单。测试输入均为合成样例，不含真实客户订单。 复现命令：在项目目录运行 `node --test website-network/tests/tools.test.mjs`。这组测试验证本地 CSV 解析和字段检查函数，不会连接电商账号，也不会验证平台后台的真实订单、库存、支付或履约状态。线上实际数据仍需要对照店铺后台或平台导出独立核验。 - 已验证：文本格式解析、必填项、重复组合及部分异常输入。 - 未验证：各电商平台的私有导出格式和真实订单准确性。 - 示例数据是虚构数据，不是客户案例或商业结果。 ### 常见问题 **CSV 里的订单号为什么变成科学计数法？** 表格软件把长数字当数值。导入时设为文本，导出后用原始编号抽查。 **页面没加载完能导出吗？** 不能把不完整数据当全量。记录分页与缺失项，必要时重新读取并核对条数。 ### 参考资料 - Shopify：导出订单: https://help.shopify.com/en/manual/fulfillment/managing-orders/exporting-orders - RFC 4180：CSV 格式常见规范: https://www.rfc-editor.org/rfc/rfc4180 --- ## 商品上架前检查：规格、图片、库存与价格一起核对 URL: https://commerce.matrixflow.cn/guides/product-listing-audit/ 摘要：商品检查先确认具体店铺和商品集合，再核对标题、图片、规格、价格与库存的一致性。检查任务只输出问题和证据；只有用户明确授权修改后，才按字段与商品范围执行更新。 ### 核心结论 - 先锁定具体店铺和商品集合，再检查字段一致性。 - 按买家路径检查标题、图片、规格、价格和库存，不能只看列表页。 - 只有明确授权才修改；修改后要读回并保存验收记录。 ### 锁定商品集合与检查依据 先约定检查全部在售商品、某个分类还是指定商品编号。记录筛选条件、读取时间与后台显示数量，避免把搜索结果第一页当作全店。检查规则来自店铺真实资料、商品资料表以及当前平台页面的限制，不能套用其他平台的标题长度或图片规格。 例如“核对春季水杯系列的 12 个商品”应配上明确的商品编号清单。商品编号与 SKU 按文本保留，重复名称不意味着同一商品；以稳定编号和页面入口建立对应关系。 ### 按购买路径检查关联字段 标题、主图、规格与详情应描述同一件商品。若标题写 500 毫升而规格选项只有 350 毫升，应列为信息冲突，而非自动选择一个值。检查图片是否加载、规格图是否对应颜色，以及说明中是否存在没有资料支持的材质、认证或性能表述。 变体商品逐项核对 SKU、售价、币种、库存和启用状态。把标价、活动价与运费分列，避免将折扣提示当作实际成交价格；库存为空、不可售与库存为零也应分别记录。 ### 问题分级后再决定是否改动 问题表至少包含商品编号、字段、当前值、依据、建议值与风险。可将影响下单的问题优先处理，例如变体无法选择或价格缺失；文案风格建议单独列出，不能与确定错误混在一起。 批量修改前给出可审查的清单，例如“仅将 3 个指定 SKU 的库存更新为资料表数值”。未获得明确商品范围、字段及目标值时保留检查结果；页面身份不符、资料冲突或权限不足时停止提交。 - 同名商品不能靠名称直接合并，应核对商品编号。 - 发现错误不等于已授权修复；检查与提交分别记录。 ### 读回变更并保存验收记录 提交后重新进入对应商品页读回目标字段，必要时查看公开商品页。后台保存成功提示只能说明请求被接受，不能独立证明顾客端已经展示新值；缓存、审核和定时生效需要在记录中注明。 检查完成要求范围覆盖、每项问题有依据、未授权字段未改动。修改完成还要求目标字段独立读回一致。结果不明时先查看商品当前状态与操作记录，确认没有重复提交风险后再决定下一步。 ### 建立商品主数据与页面的逐字段映射 把商品资料表中的主键、标题、品牌、GTIN（如适用）、变体关系、图片地址、库存、价格和币种映射到后台及公开商品页。每项记录三个值：资料表目标值、后台当前值、顾客端实际展示值。跨境商品还要记录站点地区和币种；商品页价格、结构化数据和购物渠道数据可能需要一致，具体规则按目标渠道的最新规范核对。 变体应使用稳定父商品与变体 SKU 对应，核对颜色、尺寸、包装数量等选择项是否与图片和库存一致。多平台销售时，每个平台限制不同，检查表要标记规则来源及查阅日期，不要把某个平台的标题长度复制成全平台标准。 - 高优先级：顾客无法选择、价格/币种冲突、商品无法购买。 - 中优先级：图片错配、重要属性缺失、库存来源不清。 - 建议项：表达优化，需产品负责人审核事实。 ### 提交修改前后都留可比较记录 批量改价或库存前导出目标商品清单，明确 SKU、旧值、新值、适用渠道、生效时间和授权人。提交后重新读取后台，再从公开落地页检查实际展示；若页面缓存或商品仍在审核，记录“后台已保存、前台尚未确认”，不要报成顾客已可见。 Google Merchant Center 的商品数据规范要求准确提供价格和币种，并与落地页及结账价格匹配；它是该渠道的要求示例，不应被当作所有平台统一规则。每次使用外部规范时，链接原文并记录适用站点和版本时间。 - 发生资料表与后台冲突时，先交给商品负责人定目标值。 - 保存异常 SKU 清单和回滚所需的旧值。 ### 常见问题 **检查任务可以直接改价格吗？** 默认只读。价格、库存等写入需要明确授权、具体商品范围和修改前后记录。 **为什么规格和库存要一起看？** 库存通常挂在具体 SKU 上，规格错位会导致价格或库存对应到错误商品。 ### 参考资料 - Google Merchant Center：商品数据规范: https://support.google.com/merchants/answer/7052112?hl=zh-Hans --- ## 履约复核：把可自动检查的事实与人工决定分开 URL: https://commerce.matrixflow.cn/guides/fulfillment-review/ 摘要：履约任务必须先核对订单身份、商品数量和当前状态，再进入明确授权的操作。缺少物流信息、地址冲突或提交结果未知时，应保留待处理记录，不能靠重复点击把流程推下去。 ### 核心结论 - 履约先形成待处理清单，核对订单身份、商品数量和当前状态。 - 地址冲突、物流缺失和提交结果未知必须交给人工。 - 提交后读回状态，不能靠重复点击推进流程。 ### 先形成待履约清单 将店铺、订单号、商品 SKU、数量、支付状态、订单状态和物流方式列在同一条记录中。确认订单仍属于待处理范围，再进入详情页；退款中、已取消、已发货或存在争议的订单应分别标记，不能统一按待发货处理。 例如订单 000031 包含 SKU 00128 两件，仓库资料仅准备一件时，应记录数量不一致。订单编号的前导零与运单号中的字母都必须原样保留，不通过数值转换处理。 ### 设定必须交给人的检查点 收货地址变更、缺货替换、追加费用和退款判断需要明确的业务决定。先输出冲突事实、可选处理方式及受影响订单，由有权限的人给出目标状态；不能把界面默认选项当作用户已经同意。 个人信息仅在完成履约所需范围内使用。工作报告可以保留订单入口和异常原因，避免把完整地址、电话或证件信息复制到不必要的共享文档中。验证码或重新登录应交给账号所有者处理。 ### 提交前确认，提交后核验 写入前核对目标店铺、订单号、物流公司、运单号与本次操作范围。一个订单有多个包裹时，应明确每个包裹包含的商品，不把同一运单机械复制给全部订单。逐条执行时，上一条完成核验后再处理下一条。 提交后退出编辑状态，重新打开订单详情，核对履约状态与物流字段。若页面超时或反馈含糊，将结果标为未知，先读取当前状态或操作记录，禁止立即再按一次发货。 - 任何自动重试都必须知道上一轮是否产生外部变更。 - 只读失败可以重新读取；发货、退款与取消不能盲目重放。 ### 用可复查的清单交接结果 交接清单按已完成、需人工处理、结果未知与未开始分类。每条记录写明订单标识、最终读回状态、证据入口和时间；“按钮点击成功”不属于履约成功证据。 本轮成功标准是指定订单全部有明确结论，已提交订单的实际状态与授权目标一致，未知结果没有重复提交。若只完成部分订单，就交付剩余列表和阻塞原因，继续工作时从未完成阶段恢复。 ### 用订单状态机防止重复履约 将每个订单记录为待核验、可处理、处理中、已履约、需人工和结果未知。只有“可处理”状态进入写入；处理中不能被下一轮当成待发货重复提交。多仓或多商品订单需要按履约行项目核对数量和仓库，一个订单也可能分成多个包裹。 以 Shopify 文档为例，订单可由商家、第三方应用或履约服务处理；请求发给服务后，状态可能进入处理中，并在订单时间线记录接受或拒绝。第三方取消请求也不一定能自动停止仓库履约，必须确认服务方状态。其他平台的状态机和责任边界可能不同，需查对应官方说明。 - 付款与订单状态满足业务流程后才可处理。 - 运单号、承运商、商品数量与实际包裹逐项对应。 - 退款、取消、地址修改等例外转人工核准。 ### 把外部结果未知单独列出来 提交发货后如页面卡住，先进入订单详情或时间线读回履约状态、运单号和更新时间。状态已更新则记录该结果；仍显示处理中则等待服务回执；没有可读证据则暂停为未知。重复发送同一请求可能建立重复履约、通知或物流任务，必须由平台状态和人工确认决定。 交接报告应分别列出已完成数量、待发货数量、需人工数量和未知数量，并提供每条订单的脱敏标识与后台入口。只写“任务已处理 20 单”无法证明每一单是否已履约。 - 保护客户地址和联系电话，只保留完成工作所需信息。 - 测试用订单和真实订单严格区分，禁止用真实客户信息做试验。 ### 常见问题 **发货提交后显示成功就能结束吗？** 不能。要到订单详情或列表读回物流单号与状态，确认记录真实产生。 **哪些情况必须人工处理？** 地址异常、金额争议、库存不足、平台提示验证、提交结果未知等情况应暂停自动化。 ### 参考资料 - Shopify：订单履约: https://help.shopify.com/en/manual/fulfillment/fulfilling-orders - Shopify：使用履约服务应用处理订单: https://help.shopify.com/en/manual/fulfillment/fulfilling-orders/app-fulfillment --- ## 店铺环境交接：交接身份、权限和任务状态 URL: https://commerce.matrixflow.cn/guides/store-environment-handoff/ 摘要：店铺交接应包含环境与店铺的对应关系、操作权限、未完成任务和最近核验时间。打开了一个环境并不代表进入了正确店铺，接手人仍应从实际后台读回店铺与账号身份。 ### 核心结论 - 交接要包含环境与店铺对应、权限、未完成任务和最近核验时间。 - 打开环境不等于进入正确店铺，接手人要读回页面身份。 - 完成一次闭环交接：接手人实际执行一个只读任务并核对结果。 ### 建立可区分的环境目录 为每个店铺记录稳定环境标识、环境名称、业务负责人、平台入口和授权用途。列表序号可能随着排序改变，因此“第 12 个”不能作为长期交接的唯一标识；环境名称相近时，必须附稳定标识与实际店铺名称。 可采用“店铺简称／地区／岗位”的命名方式，例如“青禾店／国内／订单复核”。名称帮助识别，真正验收仍以后台显示身份为准；不要将账号密码、验证码或 API Key 放在名称和备注里。 ### 把权限与任务边界写清楚 交接表说明接手人能查看、编辑或提交哪些内容，以及哪些操作需要负责人决定。订单只读检查、商品资料更新与退款提交是不同权限，不能因为能够进入后台，就推定拥有全部业务授权。 优先使用平台提供的成员或子账号机制分配职责，具体权限以平台当前后台配置为准。环境不是权限系统的替代品；撤销协作者时，相关平台权限与任务访问范围也应一起复核。 ### 接手时验证身份与运行状态 接手人进入目标环境后核对店铺、当前账号、页面地址和登录状态。已有相同目标页面时优先复用标签，并在浏览器内部切换到目标标签；后台工作不应反复抢占操作系统前台。 同一环境正在运行写入任务时，先查看任务状态，避免两个人或两个自动化流程同时编辑一笔订单。登录过期、身份不匹配或出现验证页面时暂停写入，保留当前任务和待处理范围。 - 交接前记录正在运行、已排期与结果未知的任务。 - 没有读回确认的提交，不能直接当作失败重做。 ### 完成一次闭环交接 交接记录包含交出人、接手人、核验时间、环境标识、店铺身份与待办清单。用一次授权范围内的只读检查确认入口可用，例如读取一条指定订单；无需为了证明环境可用而发布内容或修改状态。 成功标准是接手人能识别正确店铺、理解权限边界、取得必要资料，并能定位每项未完成任务。若存在身份疑问或提交结果未知，应明确负责人和下一步核验方式，再结束交接。 ### 用最小权限和平台角色管理团队 环境目录解决“在哪里开”，平台权限解决“允许做什么”，两者必须分别管理。按岗位分配只读、商品编辑、履约或财务权限；不因为某人拥有某环境访问权就授予退款、付款或成员管理权限。人员离岗、店铺转交或业务暂停后，核对浏览器环境访问和平台成员权限两处是否都已更新。 以 Shopify 为例，官方角色和权限文档将岗位角色映射到具体管理区域；Facebook 页面也区分 Page access 与 task access。具体能力依平台版本与账号类型变化，交接时应在真实后台读回当前访问级别，而不是沿用旧截图。 - 每个环境指定业务负责人和权限审批人。 - 密码、API Key、Cookie 与验证码不出现在共享台账。 - 离岗交接同时撤销不再需要的平台访问权。 ### 交接包不包含秘密，但要包含可执行状态 交接包包含稳定环境 ID、店铺别名、用途、当前登录状态、上次只读核验、未完成任务 ID、失败原因、下一步和负责人。新接手人通过受控凭据渠道取得自己的授权，然后在页面核对店铺名与账号；不把前任的个人密码或二次验证码作为交接方式。 交接前可先执行一次只读验收：打开后台、核对账号角色、读取指定测试商品或非敏感订单状态。测试若触发安全校验或账号风险提示，暂停并由店铺所有者处理。 - 成功：接手人能确认环境、店铺、权限、待办和恢复点。 - 未完成：明确缺失的授权、资料或登录验证，不假报已交接。 ### 常见问题 **交接只需要给账号密码吗？** 不够。还要给环境清单、权限范围、任务状态、异常和回滚方式；密码应通过安全渠道传递。 **离职后删掉环境就算撤销权限了吗？** 不是。还要在平台侧移除成员权限，并检查已保存的会话与共享资料。 ### 参考资料 - Shopify：角色与权限: https://help.shopify.com/en/manual/your-account/users/roles/ - Facebook：分配或移除主页访问权限: https://www.facebook.com/help/187316341316631 --- ## 多店铺每日检查：20 分钟看完关键异常 URL: https://commerce.matrixflow.cn/guides/daily-store-checklist/ 摘要：多店铺日常运营最怕“每个后台都看一眼，却没看到异常”。每日检查应按风险排序：登录与权限、未发货超时、库存预警、退款纠纷、价格异常，最后才是流量与销售。每项都要有负责人和处理时限。 ### 核心结论 - 每日检查按风险排序，不要从流量和销售额开始。 - 每项异常都要有店铺、订单或商品标识、负责人和处理时限。 - 检查记录要能交接，不能只存在于个人记忆里。 ### 先定检查顺序 每天早上先看“会直接影响履约和账号状态”的项：能否正常登录、是否有未发货超时、库存是否低于安全线、是否有退款纠纷或平台通知。然后再看价格、评价和流量。顺序错了，容易把时间花在优化上，却漏掉即将超时的订单。 检查顺序应固定下来，形成一张所有店铺通用的清单。固定顺序能减少遗漏，也让交接更容易。 ### 20 分钟清单 每项只记录异常和需要行动的内容。正常项可以打勾，不必写长文。目标是用 20 分钟扫完，而不是做一份漂亮报表。 - 登录与权限：每个店铺能否正常进入，是否出现验证或权限提示。 - 未发货与超时：待发货数量、最早下单时间、是否有即将超时的订单。 - 库存预警：低于安全库存的 SKU、同步失败或数量异常的商品。 - 售后与纠纷：待处理退款、退货、投诉、平台介入。 - 价格与活动：价格是否被误改、活动是否按计划开始或结束。 - 账号通知：平台规则更新、资质到期、违规提醒。 - 流量与销售：昨日访客、订单、转化，仅作为趋势参考。 ### 异常怎么记录 一条异常记录至少包含：店铺、订单号或 SKU、异常类型、发现时间、页面证据、负责人和处理时限。例如：“店铺B，订单 000031，地址异常，09:20 发现，待运营确认，12:00 前处理。” 记录要放在团队能找到的地方，并与任务系统或交接表关联。只在聊天里说一句“有个订单有问题”，很快就会被淹没。 ### 不要被总量迷惑 “今天有 300 单待发货”本身不是异常，关键是其中有多少即将超时、有多少地址异常、有多少库存不足。总量适合看趋势，异常需要看明细。 如果页面数据缺失或加载失败，要标记为“未读取”，不能按零处理。缺失和零是两种完全不同的状态。 ### 交接与复盘 每日检查结束后，把未完成事项、异常清单和需要接班同事关注的点写进交接记录。每周回看一次：哪类异常重复出现、哪个店铺处理最慢、哪项检查经常被跳过。 复盘的目的不是追责，而是减少下一次异常。如果同一问题连续出现，应该修改流程、补自动化或调整负责人，而不是每天重复救火。 ### 常见问题 **店铺很多，20 分钟够吗？** 20 分钟是单店或小团队的检查目标。店铺多时可以用只读任务批量读取关键字段，再由人看异常清单；不要为了速度跳过登录和履约检查。 **每天必须检查流量数据吗？** 不必放在最前面。流量适合按日或按周看趋势；履约、库存和账号状态更容易直接影响业务，应优先。 **异常记录需要截图吗？** 关键异常建议保存脱敏截图或页面 URL，便于复核；普通提醒可以只记录文字和链接。 ### 参考资料 - Shopify Help：订单管理: https://help.shopify.com/en/manual/orders - Shopify Help：库存管理: https://help.shopify.com/en/manual/products/inventory - MatrixFlow 官方网站: https://matrixflow.cn/ --- ## 库存同步与超卖：先统一口径，再谈实时 URL: https://commerce.matrixflow.cn/guides/inventory-oversell/ 摘要：超卖通常不是单一系统故障，而是库存口径不一致、同步延迟、渠道并发和安全库存不足共同造成。先确定以哪个系统为权威库存，再设置同步频率、缓冲和安全库存，并为冲突订单保留人工复核。 ### 核心结论 - 先确定权威库存系统，再设计同步，不要多个系统互相覆盖。 - 同步有延迟，必须设置安全库存和异常处理，而不是假设实时。 - 超卖发生后先保履约与客户沟通，再回溯口径和同步问题。 ### 统一口径 库存至少有三种口径：实物库存、可售库存和已占用库存。实物库存是仓库里的数量，可售库存是页面允许下单的数量，已占用库存是订单或活动锁定但尚未出库的数量。不同平台和系统可能用不同定义。 先确定哪个系统是权威来源，其他渠道从它同步。没有权威来源，多个系统同时写入，库存就会来回覆盖，谁也说不清哪个数是对的。 ### 同步延迟 同步方式可能是定时拉取、Webhook 推送或人工导入，每种都有延迟和失败可能。要记录最后一次成功同步时间、失败次数和待同步变更，不能只看页面上显示的数字。 同步本身也应幂等：同一条变更重复到达时，不应把库存再次加减。对冲突变更，保留时间戳、来源和操作人，便于追溯。 ### 安全库存 安全库存是为了吸收补货周期、同步延迟和需求波动而预留的缓冲。它不是平台固定字段，而是团队自己的管理参数。不同 SKU 的缓冲可以不同，畅销品和长尾品不应使用同一个数。 设置安全库存时要考虑补货提前期、日均销量、同步频率和促销计划。它是经验与数据结合的结果，不是一个永远正确的公式。 ### 冲突处理 超卖处理的第一目标是履约与客户沟通，而不是先追责。保留订单、库存和同步记录，事后才能判断问题出在哪一层。 - 发现超卖：先确认订单是否真实、库存是否可补，再决定履约或联系买家。 - 多个渠道同时下单：按订单时间、付款状态和平台规则处理，避免只看哪个先同步。 - 同步失败：暂停相关渠道的可售数量更新，恢复后重新对账。 - 人工改库存：记录修改前后值、原因和操作人，避免覆盖自动同步。 ### 监控指标 不要只优化一个指标。过度压低库存会提高缺货率，过度提高安全库存会占用资金；要结合业务目标和实际数据调整。 - 同步延迟：最后一次成功同步距现在多久。 - 冲突数量：同一 SKU 在多个渠道的库存差异。 - 超卖订单数：已付款但无法按承诺履约的订单。 - 缺货率与库存周转：判断安全库存是否合理。 - 人工修改次数：频繁人工干预说明流程或系统有问题。 ### 常见问题 **库存同步能做到完全实时吗？** 很难保证。网络、平台接口、处理队列和并发下单都会带来延迟。更现实的做法是承认延迟，并用安全库存和异常流程吸收。 **安全库存设多少合适？** 取决于补货周期、销量波动、同步频率和促销计划。先用历史数据估算，再定期复盘，不要照搬统一数字。 **超卖后应该先改库存还是先联系买家？** 先确认订单与可履约数量，再尽快与买家沟通；同时暂停相关渠道的继续售卖，避免扩大影响。 ### 参考资料 - Shopify Help：库存管理: https://help.shopify.com/en/manual/products/inventory - GS1：GTIN 标准: https://www.gs1.org/standards/id-keys/gtin - MatrixFlow 官方网站: https://matrixflow.cn/ --- ## 退换货核对：金额、状态与凭证三件事 URL: https://commerce.matrixflow.cn/guides/returns-refunds/ 摘要：退换货处理包含平台状态、资金状态和物流状态三条线。核对时要看订单号、退款金额、当前节点、凭证和时限；金额正确但状态未完成，或状态完成但金额不一致，都不能算处理完毕。 ### 核心结论 - 售后状态、退款状态和物流状态是三条线，要分别核对。 - 金额正确但状态未完成，不能算处理完毕。 - 异常退款保留凭证并转人工，不要用重复操作推进。 ### 三条状态线 这三条线不一定同步。平台显示“同意退款”不代表钱已到账；物流显示“已签收”也不代表退款已完成。核对时要分别读取实际状态。 - 售后状态：买家申请、商家同意、平台介入、完成或关闭。 - 资金状态：退款申请、处理中、已退款、失败或部分退款。 - 物流状态：待寄回、运输中、已签收、拒收或丢失。 ### 金额核对 退款金额可能包含商品金额、运费、税费、折扣分摊和部分退款。先确认本次退的是哪几件商品、使用什么优惠、运费由谁承担，再对照页面与支付记录。 多币种订单要保留原币种与结算币种，不能直接把不同币种的金额相加。部分退款要检查剩余金额是否与订单一致。 ### 凭证与时限 退换货凭证包括买家上传的图片、物流单号、签收记录、平台聊天记录和售后原因。保存时要遮盖无关个人信息，并记录获取时间。 平台通常有申请、寄回、商家处理等时限。时限以平台当前规则为准，不要用过去的经验替代。临近时限的售后应优先处理并标记负责人。 ### 异常与升级 异常售后不应由自动化猜测处理。先停止重复操作，保留证据，再交给有权限的人决定。 - 金额不一致：核对折扣、运费、税费和部分退款，不要直接补差。 - 重复退款：检查是否同一订单多次提交，保留记录并转人工。 - 物流异常：签收未收到、退回丢失、拒收，需要平台与物流共同确认。 - 支付争议：保留订单、沟通和履约证据，按平台流程处理。 ### 复盘 按原因统计退换货：尺码、质量、描述不符、物流破损、发错货等。重复出现的原因应反馈到商品页、包装、质检或文案，而不是只在售后环节补救。 复盘还要看处理时长和重复联系率。退款完成不代表体验良好；如果买家多次询问，说明信息同步或沟通仍有问题。 ### 常见问题 **平台显示退款成功就结束了吗？** 还要核对金额、币种、订单和实际到账状态。平台状态与支付渠道状态可能不同步。 **部分退款怎么核对？** 确认退款商品、折扣分摊、运费和税费，比较剩余金额是否与订单一致，并保留计算依据。 **买家说没收到退款怎么办？** 先查平台退款状态和支付渠道处理时间，再提供可核对的凭证；不要仅凭聊天承诺重复退款。 ### 参考资料 - Shopify Help：退货与退款: https://help.shopify.com/en/manual/returns - Shopify Help：订单管理: https://help.shopify.com/en/manual/orders - MatrixFlow 官方网站: https://matrixflow.cn/ --- ## 商品文案本地化：别只翻译，要重写信息顺序 URL: https://commerce.matrixflow.cn/guides/localized-product-copy/ 摘要：商品文案本地化要保留事实，但重写信息顺序：当地用户先关心什么、哪些规格必须前置、哪些承诺不能出现、单位与尺寸如何表达。翻译工具可以辅助，最终仍需人工核对类目、合规与平台限制。 ### 核心结论 - 本地化保留事实，但重写信息顺序和表达方式。 - 单位、尺寸、材质、认证和售后信息要按目标市场重新核对。 - 翻译完成后必须人工检查类目、合规词和平台限制。 ### 先定目标与读者 同一件商品卖给不同市场，买家的第一问题可能不同：有人先看尺寸，有人先看材质，有人先看是否兼容本地电压或标准。先明确目标平台、国家或地区、主要使用场景，再决定文案顺序。 不要从原文逐句翻译开始。先列出买家最关心的五个问题，再检查原商品信息能否回答；回答不了的地方，应补资料而不是编文案。 ### 信息顺序 信息顺序不是固定模板。高客单价商品可能需要更详细的规格与证明，低客单价商品则需要更快说明核心用途。 - 标题：核心品类 + 关键规格 + 使用场景，避免堆砌无关关键词。 - 首屏：最重要的差异点与适用人群。 - 规格：尺寸、材质、容量、电压、兼容性，用目标市场常用单位。 - 证明：检测、认证、保修、真实素材；没有的不要编。 - 物流与售后：配送范围、时效、退换条件，以平台实际规则为准。 ### 单位与文化 尺寸、重量、温度、电压和日期格式都可能需要转换。转换后要复核，避免出现“厘米转英寸后数量级错误”或“电压不兼容”的问题。 习语、幽默和夸张表达往往难以直译。直译可能变得生硬，甚至产生误解。本地化应重写为当地读者能理解的表达，但不能改变事实或做出原文没有的承诺。 ### 合规与平台规则 不同平台和地区对绝对化用语、医疗功效、认证标识、价格比较和促销表述有不同限制。翻译工具不会自动知道这些规则，必须人工检查。 涉及食品、化妆品、儿童用品、电子设备等品类时，合规要求更复杂。应查阅目标平台当前规则和当地法规，必要时咨询专业人士。 ### 协作与验收 本地化不是一次性项目。平台规则、汇率、物流和商品版本都会变化，文案需要定期复核。 - 建立术语表：品牌名、材质、型号、单位统一译法。 - 指定母语或熟悉当地表达的复核人。 - 至少抽查一个完整 SKU，按买家路径检查标题、图片、规格和详情。 - 发布后读回页面，确认单位、价格、库存和类目没有错位。 - 记录修改版本与负责人，便于后续更新。 ### 常见问题 **机器翻译能直接用于商品上架吗？** 不建议直接使用。机器翻译可以辅助初稿，但需要人工核对术语、单位、合规和表达自然度。 **标题关键词越多越好吗？** 不是。堆砌关键词会降低可读性，也可能违反平台规则。标题应优先准确描述品类、核心规格和用途。 **不同国家可以用同一套文案吗？** 可以共享事实信息，但信息顺序、单位、合规和表达应本地化。直接复用可能造成理解困难或违规。 ### 参考资料 - Shopify Help：商品详情: https://help.shopify.com/en/manual/products/details - WIPO：版权: https://www.wipo.int/copyright/en/ - MatrixFlow 官方网站: https://matrixflow.cn/ --- ## 本站常见问题 **多店铺每天先看什么？** 先看异常而不是总量：未发货超时、库存预警、退款与纠纷、价格异常、登录失效。异常清单应能在 20 分钟内扫完，并标明负责人。 **订单号为什么会少零？** 表格软件把订单号当成数字时会删除前导零。导入导出时将订单号、SKU 设为文本，并在导出后抽查原始编号。 **库存同步怎样减少超卖？** 统一库存口径、设置安全库存、让同步延迟可见，并对跨渠道同时下单的异常订单人工复核。没有任何同步能保证绝对实时。 **商品上架前检查什么？** 标题、类目、规格、价格、库存、图片、合规信息和移动端预览。至少抽查一个完整 SKU，而不是只看列表页。 **自动导出订单要注意什么？** 确认时间范围、店铺与账号、字段完整性、实际行数，并保护买家隐私。导出成功不等于数据完整，需与页面条数抽查对照。 **退换货核对看什么？** 订单号、退款金额、当前状态、凭证、时限和平台规则。金额正确但状态未完成，仍然不能算处理完毕。 **多店铺怎样交接？** 准备环境、店铺、账号对应表，交清权限、未完成订单与售后、异常记录和回滚方式，并由接手人实际登录确认。 **这些流程能保证不违规吗？** 不能。平台规则、商品合规和税务要求需要按平台与法规执行。手册提供的是核对方法，不是合规承诺。