一句定义
原文保留 = 把客户在订单提交时填入的原始字符串 1:1 留底，连同修正记录、工厂确认回执，构成一条从「客户表达」到「工厂生产」的完整证据链。
在 Amazon A-to-z claim、PayPal 争议、信用卡 chargeback 三类售后场景里，平台仲裁的核心就是「卖家是否能证明生产物与客户原始指令一致」——证据链断在哪里，款就赔在哪里。
适用场景
Amazon A-to-z claim：客户申诉「商品与描述不符」「未按要求定制」时，卖家有 5-7 天内提交证据，平台不接受口述只接受书面记录。
PayPal 争议 / Significantly Not as Described：PayPal 仲裁周期 10-20 天，能证明客户原始指令的卖家胜诉率超过 80%。
信用卡 chargeback：发卡行通常给 60-120 天回应窗口；定制类商品「customized to buyer specifications」属于不可退条款，前提是有完整原始指令记录。
直接售后协商：哪怕没走平台仲裁，运营回复客户「您当时填的是 X，我们生产的是 X」也能让 60% 的争议直接化解。
输入输出示例
举证三段式模板
| 段 | 字段 | 内容（示例） | 证据来源 |
|---|---|---|---|
| 一 · 客户原文 | 订单号 | 102-7345891-2233445 | Amazon 订单页 |
| 提交时间 | 2026-04-12 14:32:08 UTC | Amazon 订单时间戳 | |
| Customization 原始 JSON | surfaces[0].areas[0].text = 「Sliver」 | Amazon Customization ZIP | |
| 客户备注原文 | 「Please engrave Sliver on the back」 | Amazon 订单备注 | |
| 二 · 修正记录 | 系统识别 | 自动标记「拼写疑似错误：Sliver」 | Koru 审核日志 |
| 运营处理 | 2026-04-12 16:05 运营张某进入审核 → 选择「按原文生产」 → 备注「客户原文如此，未联系修正」 | Koru 修正记录 | |
| 是否联系客户 | 否（运营未发起客服跟单） | Koru 跟单日志 | |
| 三 · 工厂确认 | 生产指令下发 | 2026-04-13 09:12 已下发工厂 A，刻字内容 = Sliver | Koru 导出日志 |
| 工厂确认回执 | 工厂 A 收到回执 2026-04-13 10:30，确认按 Sliver 刻 | 工厂端 IM / 邮件截图 | |
| 出货前质检照片 | 出货前拍照存档，可见刻字 Sliver 与订单一致 | 工厂质检相册 |
整条证据链的关键点
- 客户原文必须是「客户提交时的原始字符串」而不是清洗后的结构化字段值；
- 修正记录要带时间戳和处理人，运营改没改、为什么改、改成什么，全可追溯；
- 工厂确认必须是工厂端书面回执，而不是「我们发了就当工厂收了」；
- 出货前质检照片是最后一道保险，能挡住「工厂收到正确指令但做错了」的责任划分。
针对刻错字争议，三段式模板的实际胜诉表现
| 证据完整度 | 平台仲裁胜诉率（估算） | 备注 |
|---|---|---|
| 三段齐全 | 75-85% | A-to-z claim 通常直接驳回 |
| 缺工厂确认 | 50-60% | 平台可能判赔部分 |
| 仅有客户原文 | 25-35% | 容易被「未尽核对义务」反驳 |
| 无原文，只有结构化字段 | < 10% | 卖家通常全额赔付 |
数据口径：基于 Koru 试点阶段 12 家卖家 2026 年 1-4 月 A-to-z claim / PayPal 争议复盘 + 4 位资深账户经理访谈估算。具体胜诉率因品类、平台政策、买家信誉等因素浮动。
常见误区
误区一：把客户原文「修正」后丢掉。客户写 Sliver，系统「智能修正」为 Silver 入库——出客诉时既不能证明客户原意是 Silver，也不能证明你按原文生产。
误区二：修正记录只记结果不记过程。「字段被运营改了」但没记「改前是什么 / 改后是什么 / 为什么改」——平台不认可缺失上下文的记录。
误区三：依赖口头确认工厂收到指令。微信电话沟通好，但没留书面回执——仲裁时拿不出证据。
误区四：出货后才发现没拍质检照。订单发走 30 天才被投诉，再去找质检照已经没了。出货前拍照入库是常规动作。
误区五：把举证当成「客诉来了再去翻」。每次都临时翻日志拼证据，平台 5-7 天窗口期太赶——证据链应该订单完成时就自动归档好。
Koru 如何处理
原文与结构化字段双轨存储。每条订单的客户原始 Customization JSON、备注原文、上传图原 UUID、MD5 都永久留底，结构化字段只是工厂用的视图，不会替换原文。
修正记录全字段日志。运营每一次改字段都自动记录「改前值 / 改后值 / 处理人 / 时间戳 / 备注」五件套，无法绕过、无法事后篡改。
工厂确认与导出绑定。每次 Excel 导出都生成不可变的导出包（含订单号 / 时间戳 / 字段值 / 上传图目录），工厂回执也回写到订单档案，形成闭环。
一键导出争议包。A-to-z claim 来了，工作台点「导出争议包」即可生成「原文 + 修正日志 + 工厂回执 + 质检照」PDF，5 分钟内提交平台，不再临时翻日志。
行动建议
1. 立刻停止自动修正客户原文：哪怕看起来是拼写错误（Sliver / Silvr），原文必须保留，是否修正交给人工审核 + 客服跟单。
2. 强制记录修正日志：让每一次字段修改都带「改前 / 改后 / 处理人 / 原因」四要素，缺一不可。
3. 工厂端确认改成书面回执：用 IM 截图、邮件、订单系统签收任何一种均可，但「电话说好了」不行。
4. 出货前质检照固化为标准流程：每个出货订单留 1-2 张能看清刻字 / 印花 / 尺寸的照片，按订单号入库存档 90 天。