我经手过一个家居类目的 ERP 选型项目，客户在 Amazon、Shopify、TikTok Shop、eBay 四个平台开着 9 个店铺，日均订单量在 2800 到 3500 单之间（数据做过脱敏和量级处理）。系统上线第一周，客服团队每天要手工补 120 到 180 单，原因不是 ERP 不支持这些平台，而是选型阶段的市场调研只问了“支持哪些平台”，没问“退款发起后库存什么时候回补”“平台取消订单后推仓单能不能撤回”。
这份方案在功能清单上是满分的，在业务现场是失分的。
这件事之后我形成了一个判断：ERP 跨境电商方案设计里，订单同步场景的市场调研，本质不是调研“功能有没有”，而是调研“边界在哪里”。边界包括同步什么、不同步什么、什么时候同步、出错了谁负责、成本由谁承担。这些边界不研究清楚，方案写得再厚也只是一份宣传册。
下面我把这几年在跨境电商 ERP 方案设计、市场调研和落地实施中积累的方法、踩过的坑、用过的工具和判断标准，按“结论，场景，误区，逻辑，案例，建议，取舍”的顺序完整写一遍。如果你正准备做订单同步场景的调研，这篇文章可以直接当作战地图用。
很多人对市场调研的理解还停留在“收集需求、整理功能、写进 PRD”。在订单同步这个场景下，这样做的结果通常是：方案看起来很全，上线后异常处理全靠人。
场景边界表回答的是“哪些订单状态属于本次方案范围”。它至少要区分三类：正向状态、逆向状态、异常状态。正向状态包括下单、支付、审核、拆单、合单、推仓、发货、签收、回传；逆向状态包括取消、退款、退货、换货；异常状态包括超卖、地址修改、物流丢件、接口失败、重复推送。
我见过最典型的问题是把“取消”当成正向流程的附属品。实际上在很多平台，取消是一个独立事件，触发时机、可取消窗口、取消后库存回补规则都和发货状态强相关。取消不是订单的终点，而是一条平行链路。
订单同步不是一个技术动作，它会同时影响运营、客服、仓储、财务、IT 五类角色。运营关心订单什么时候能推仓，客服关心能不能查到实时状态，仓储关心拣货单会不会被重复下发，财务关心对账口径和汇率取值时点，IT 关心接口限流和失败重试。
调研如果没有覆盖这些角色，最后一定会出现“系统做完了，没人用”的局面。我的经验是：订单同步项目失败，八成不是技术问题，而是角色没对齐。
假设清单是调研和方案之间的桥。它写成“如果……那么……”的形式，例如“如果平台的退款事件在支付后 24 小时内才推送，那么财务对账窗口必须设置为 T+1”“如果单店铺日订单峰值超过 5000 单，那么轮询式同步必然丢单”。
这些假设必须在 POC 阶段被验证或推翻。没有假设清单的调研，最后会变成一份谁都无法反驳的 PPT。
要设计订单同步方案，先得知道自己在同步什么。很多人对“订单同步”的想象是：平台有新订单，拉过来就行。真实的订单同步是一条带分支、带回环、带超时的链路。
我把一笔普通跨境订单的正向链路拆成九个节点：平台下单、支付成功、订单进入待审核、ERP 拉取订单、审核通过、库存预占、拆合单、推送仓储、发货回传、平台状态更新、签收、财务入账。实际项目中节点数是浮动的，取决于平台是否提供支付事件、是否支持部分发货、是否有中间服务商层。
这九个节点里，真正容易出问题的不是拉单，而是状态回传和库存预占。拉单失败可以重试，状态回传失败会导致平台侧订单状态和 ERP 侧不一致，进而引发客服投诉、超卖、重复发货。
逆向链路上有四个事件必须单独研究：买家取消、平台取消、退款（全额/部分）、退货入库。它们和正向链路的关键差异是，逆向事件往往不携带完整的订单上下文。
举个例子，某平台推送的退款事件里可能只有订单号、退款金额、退款原因，没有 SKU 明细。如果 ERP 在正向同步时没有把订单号到 SKU 的映射关系持久化，退款回来的时候就没法自动回补库存。这就是典型的“正向同步时偷懒，逆向同步时还债”。
我把异常分成四类：平台侧异常（接口限流、字段变更、服务不可用）、数据侧异常（重复订单、字段缺失、金额不一致）、业务侧异常（超卖、地址无效、库存不足）、系统侧异常（队列积压、任务超时、幂等失效）。
这四类异常的处理策略完全不同。平台侧异常靠重试和退避，数据侧异常靠校验和告警，业务侧异常靠人工介入和流程兜底，系统侧异常靠监控和容量规划。一份没有异常处理章节的订单同步方案，等于没写。
单店铺单币种场景下，订单同步的复杂度是可控的。一旦叠加四个变量，复杂度不是相加而是相乘。多店铺意味着同样的 SKU 在不同店铺可能有不同编码；多币种意味着金额、汇率、结算口径需要明确取值时点；多时区意味着“今天”的定义不一致，对账周期会错位；多仓意味着库存预占和分配策略要重新设计。
我做过一个粗略统计：在单店铺单仓场景下，订单同步模块的测试用例大约在 120 到 180 条；叠加到 5 个店铺、3 个币种、2 个时区、3 个仓之后，有效测试用例涨到 600 条以上。增长主要来自组合边界，而不是单点功能。
我复盘过十几个订单同步项目，发现调研阶段的失误高度集中在五个模式上。这五个误区不是能力问题，而是方法问题。
最常见的调研问卷长这样：“是否支持 Amazon？是否支持 Shopify？是否支持多店铺？是否支持自动拆单？”被调研方全部勾“支持”，调研就结束了。问题在于，“支持”是一个没有信息量的词。
正确的问法是：“在什么条件下支持？容量上限是多少？超过上限怎么办？失败后多久重试？重试几次？谁收到告警？”把封闭式问题换成边界式问题，调研质量会立刻上一个台阶。
管理层告诉你的是目标：希望订单处理效率提升 50%，希望减少人工。一线告诉你的是现实：每天下午三点到五点订单集中爆发，客服要同时开六个后台查状态，退款单要手工在 Excel 里核对。
这两类信息都重要，但只有后者能推导出具体的方案约束。我的习惯是：每个角色至少访谈两人，一人是主管，一人是执行者。执行者提供的是场景细节，主管提供的是优先级。
正向流程可以靠演示讲清楚，逆向和异常只能靠真实数据暴露。很多团队在调研阶段没有拿到历史异常数据，只能靠想象，最后方案里写的异常处理全是通用套路，一到具体平台就失效。
我的建议是：调研阶段一定要拿到至少三个月的历史订单数据，包含取消单、退款单、异常单，按平台、按类型做分布统计。没有数据就用抽样，不要用假设。
销售演示是包装过的正常路径，它不会主动展示接口超时、字段缺失、重复推送。我见过一个团队因为演示效果太好，直接签了合同，上线后发现对方在特定平台用的是非官方接口，稳定性完全不可控。
调研阶段必须要求对方提供三样东西：接口文档片段、异常处理说明、至少一个可运行沙箱环境。拿不到这三样，方案风险就是不可评估的。
平台的接口能力不是静态的。限流规则、字段变更、事件订阅机制、沙箱环境策略都会调整。调研时如果不把“接口政策变化的风险”写进方案，上线后每次平台改版都要重新返工。
我在方案里通常会加一条硬性要求：所有依赖平台接口的模块，必须有降级策略和人工兜底入口。这不是保守，而是跨境业务的现实。
调研不是把信息收回来就完了，关键是把信息转成决策。我习惯把订单同步调研拆成五个决策层，从下往上依次收敛。
这一层要回答的是：本次方案同步哪些对象。对象至少包括订单主单、订单明细、支付记录、退款记录、物流轨迹、库存变动、财务流水。每个对象都要标注：来源平台、同步方向（单向/双向）、是否可选、优先级。
我的经验是，第一版方案不要把对象铺太全。先把订单主单、明细、退款三个对象做扎实，再扩展物流和财务。铺得太全的项目，通常每个对象都做得很浅。
时效等级不是“越快越好”，而是“够用就好”。我通常把时效分成四档：实时（秒级，靠事件订阅）、准实时（分钟级，靠短轮询）、定时批量（小时级，靠定时任务）、人工触发（按需）。
不同对象适合不同档位。订单主单适合准实时，库存变动适合准实时或实时，物流轨迹适合定时批量，财务流水适合 T+1 批量。把所有对象都设成实时的方案，成本和稳定性都会出问题。
异常归属是调研里最容易被跳过、又最影响上线体验的一层。它要回答：当同步失败时，谁负责发现、谁负责处理、多久内处理、处理后如何回写。
如果这一层没定义清楚，上线后就会出现“系统报了警但没人看”“客服发现了但没人能改”的局面。我的做法是在方案里直接画一张 RACI 表，把每个异常类型的 Responsible、Accountable、Consulted、Informed 都标出来。
跨境业务里，同一笔订单在平台、ERP、财务系统里的金额可能不一致，原因是汇率取值时点、平台佣金扣减时点、退款时点不同。调研时必须确认：以哪个系统的数据为准？对账周期是 T+1 还是 T+7？差异超过多少触发人工核查？
这一层如果不定，财务永远不认系统的数据，最后还是要回到 Excel。系统能不能替代人工，取决于对账口径能不能被财务签字确认。
可观测性指的是：订单同步过程是否可监控、可追溯、可复盘。至少需要三个能力：同步延迟的实时监控、单笔订单的全链路追踪、异常类型的趋势分析。
很多方案在前四层都做得不错，唯独在可观测性上省事，结果出了问题只能靠猜。我在方案里会把可观测性当作一等公民，因为它决定了系统上线后能不能自我进化。
订单同步调研不能只用一种方法。我通常组合使用五种手段，按成本从低到高排列：桌面研究、竞品拆解、数据诊断、深度访谈、POC 验证。
桌面研究的目标是建立一份“平台能力档案”，每个平台一行，字段包括：订单事件类型、是否支持事件订阅、轮询频率限制、退款事件是否携带 SKU、是否支持部分发货、是否有沙箱环境、接口版本更新频率。
这份档案的更新成本很低，但价值极高。它能在访谈之前帮你识别哪些问题是“平台限制”，哪些问题是“方案选择”。不做桌面研究就去访谈，会把大量时间浪费在对方也无法回答的平台细节上。
竞品拆解最容易犯的错，是只看演示账号。演示账号展示的是正常路径，你需要看的是接口文档、异常处理说明、实施交付文档、客户案例里的“踩坑记录”。
我的拆解清单包括：对方在文档里如何描述失败重试策略、如何处理重复订单、是否提供幂等键、是否公开限流阈值、异常订单的后台入口在哪里。这些信息比功能列表更能反映产品的成熟度。
数据诊断是我最看重的一环。访谈会受记忆偏差影响，演示会受包装影响，只有历史数据不会说谎。数据诊断要看的指标包括：订单同步成功率、平均同步延迟、异常订单占比、人工干预笔数、对账差异率。
有了这些基线数据，调研就从“你觉得哪里有问题”变成了“数据显示这里有问题”。后者能显著降低沟通成本。
访谈对象要覆盖五类角色：运营、客服、仓储、财务、IT。每类角色问的问题不一样。以下是我常用的访谈提纲片段（按角色分组的结构化提纲）：
{
"运营": [
"订单从平台到仓库平均需要多久？最长的一次是多久？",
"大促期间订单峰值是多少？峰值时系统有哪些异常表现？",
"拆单和合单规则是谁定的？规则变更频率多高？"
],
"客服": [
"买家问订单状态时，你需要打开几个后台？",
"哪些订单必须人工处理？每天大概多少笔？",
"退款单你会先查 ERP 还是先查平台后台？为什么？"
],
"仓储": [
"拣货单会不会出现重复下发？发现了怎么处理？",
"库存预占什么时候释放？有没有出现过超卖？",
"部分发货的场景多吗？占比大概多少？"
],
"财务": [
"对账以哪个系统的数据为准？差异超过多少触发核查？",
"汇率取值时点是下单、发货还是结算？",
"退款金额与订单金额不一致时怎么处理？"
],
"IT": [
"现有的接口调用有没有被限流？频次是多少？",
"同步失败的告警现在发到哪里？谁在看？",
"如果平台接口改版，你们的响应周期是多久？"
]
}
这份提纲的关键在于：每个问题都指向一个具体的方案约束，而不是一个泛泛的感受。问完五类角色，你基本能拼出一张完整的约束地图。
POC 阶段不要用正常订单验收，要用异常订单验收。我通常准备一组固定的异常用例：重复推送的订单、金额为 0 的订单、SKU 不存在的订单、退款后再退货的订单、地址在推送后被修改的订单、接口连续失败 10 次的场景。
能通过这组用例的方案，才具备上线条件。只跑正常路径的 POC，本质上是一次加长版的销售演示。
前面讲了方法，这一节讲怎么把方法落到具体工具和指标上。因为调研最怕的就是“收集了一堆访谈记录，但没法量化”。
访谈有一个天然缺陷：人会记住最痛的场景，忘记最频繁的场景。客服可能反复强调某次超卖事故，但实际上他每天花时间最多的是查订单状态。如果先访谈再取数，你会被叙事带偏。
我的顺序是：桌面研究 → 数据诊断 → 深度访谈 → 竞品拆解 → POC。先让数据暴露问题分布，再用访谈解释原因。数据告诉你“哪里疼”，访谈告诉你“为什么疼”。
数据诊断的第一道门槛不是分析能力，而是数据能不能聚到一起。跨境卖家通常有多个平台后台、多个店铺、多套导出格式，Excel 手工合并一次要几个小时，而且每次口径都可能不一致。
我在项目里会先解决聚合问题，再谈分析。这一步如果不解决，后面的所有指标都是不可信的。实际操作中，我会用一个多平台数据聚合层，把各平台的订单、退款、物流数据归到统一的字段口径下，再做指标计算。数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）就是我在这一环节会考虑的工具之一，它的定位是跨境电商数据分析与订单数据聚合，适合用来快速建立调研阶段的订单基线看板。
我设计看板时会区分四组指标：
这四组指标合在一起，才能回答“订单同步到底健康不健康”。只看成功率是不够的，成功率 99% 但人工干预率 20%，说明系统的自动化程度其实很低。
数据诊断的价值不只是发现问题，更是生成访谈问题。比如数据看到某平台退款单的对账差异率是其他平台的三倍，访谈时就可以直接问财务：“这个平台的退款，你们是怎么核对的？”这种问题比泛泛的“你们对账有什么困难”有效得多。
我在实践中会维护一张“数据，问题”映射表，每发现一个异常指标，就生成两到三个针对性访谈问题。让数据驱动访谈，而不是让访谈收集数据。
# 数据到访谈问题的转化示例（YAML 结构）
异常指标: "平台A 退款对账差异率 8.7%，其他平台均值 2.1%"
关联访谈问题:
"平台A 的退款事件里，SKU 明细字段是否经常缺失？"
"这部分差异最后是怎么平掉的？手工还是系统？"
"差异处理平均需要几个人天？"
异常指标: "大促期间 P95 同步延迟从 45 秒升至 22 分钟"
关联访谈问题:
"延迟期间客服是通过什么方式获取订单状态的？"
"延迟超过多久会触发人工介入？谁来触发？"
"平台侧有没有给出限流阈值或容量说明？"
这张映射表最后会直接变成调研报告的核心章节。它把“问题描述”和“解决线索”绑在一起，让调研结果可以直接进入方案设计。
同样的方法论，落在不同角色身上，行动重点完全不同。以下是我按四类常见角色给出的具体建议。
你的首要任务是建立平台能力档案，并且把它做成可维护的内部资产。这份档案不需要很详细，但必须覆盖订单事件类型、限流规则、退款事件字段完整度、沙箱可用性这四个关键字段。
其次是建立异常场景库。每做一个项目，就把遇到的新异常补充进去。做满十个项目，你就有了一个别人抄不走的资产。ERP 方案的竞争力不在功能数量，而在异常覆盖度。
你最有价值的动作是提前准备数据，而不是提前准备需求清单。把过去三个月的订单、退款、异常数据按平台导出，做一次基线统计。这一步做完，你在和供应商沟通时的话语权会完全不同。
另外，强烈建议在合同里写清楚异常处理的服务级别：响应时间、处理时间、责任边界。订单同步的问题 90% 出现在上线后，而合同通常只约定上线前。
你的核心价值是识别“客户没说出口的约束”。客户说要自动同步，真正的约束可能是财务不认系统数据；客户说要实时，真正的约束可能是平台限流根本做不到实时。
我的做法是在方案汇报时，专门用一页讲“我们做不到什么、为什么做不到、替代方案是什么”。这页往往比功能清单更能建立信任。敢于讲边界的方案，比全能的方案更可信。
两周是一个现实约束。我的压缩方案是：第 1 到 2 天做桌面研究，建立平台能力档案；第 3 到 5 天做数据诊断，出基线指标；第 6 到 8 天完成五类角色访谈，每类至少两人；第 9 到 10 天做竞品拆解，重点看异常处理文档；第 11 到 12 天整理场景边界表和假设清单；第 13 到 14 天做一次小范围 POC，只验证最危险的两个假设。
这个节奏下，你不可能覆盖全部细节，但能覆盖全部决策层。调研的完整性不等于细节的完整性，而是决策要素的完整性。
调研的终点不是把所有需求都实现，而是在约束下做取舍。以下是订单同步场景里最常见的五组取舍。
实时同步的吸引力很大，但成本也高：需要事件订阅能力、需要处理乱序、需要更高的幂等要求、需要更复杂的监控。如果业务上订单处理本身就有小时级的操作节奏，实时同步的收益会被大幅稀释。
我的判断标准是：如果同步延迟从 15 分钟降到 1 分钟，不会改变任何角色的操作行为，那就不值得做实时。反过来，如果库存变动延迟会导致超卖，那就必须做实时。
新平台层出不穷，全平台覆盖听起来很美，但每个平台的异常处理逻辑都不一样。把它做浅，等于每个平台都会出问题。
我的建议是二八法则：把贡献 80% 订单量的平台做深，剩下 20% 用轻量适配 + 人工兜底。做深的标准是：能自动处理该平台 90% 以上的异常类型。
自研的诱惑是可控，成本是维护。跨境平台的接口政策变化频繁，自研团队需要长期投入才能跟上变化。采购的诱惑是快，成本是边界受限。
我的判断框架是看三点：订单量级是否支撑长期投入、业务是否有强差异化诉求、团队是否有稳定的技术迭代能力。三者都满足才考虑自研，否则采购 + 适度定制是更现实的选择。
异常全自动是目标，但不是起点的合理选择。很多异常类型的发生频次极低，为它们做全自动处理的投入产出比很差。
我的策略是分层：高频异常做全自动，中频异常做半自动（系统给建议，人工确认），低频异常只做告警和人工入口。把有限资源投在高频异常上，是订单同步方案最常见的性价比选择。
完整和实时经常冲突。举个例子，退款事件可能先推送一个只有金额的部分事件，几小时后才补全 SKU 明细。如果追求实时，你就要先落一个不完整的数据；如果追求完整，就要延迟处理。
我的处理方式是分层存储：实时层只保留事件本身和关键标识，完整层在做完字段补全后再写入。查询时按场景选择层次，而不是强行统一。
| 取舍维度 | 偏左选择的适用场景 | 偏右选择的适用场景 | 主要代价 |
|---|---|---|---|
| 实时 vs 准实时 | 库存敏感、超卖成本高、平台支持事件订阅 | 订单处理本身有小时级节奏、平台仅支持轮询 | 实时方案需承担限流、乱序、幂等等复杂度 |
| 全平台 vs 核心平台 | 平台数量少、每平台订单量均衡 | 订单集中在少数平台、长尾平台订单稀疏 | 全平台覆盖会摊薄每个平台的异常处理深度 |
| 自研 vs 采购 | 订单量级大、业务差异化强、技术团队稳定 | 订单量中等、需要快速上线、无长期技术储备 | 自研的长期维护成本常被低估 |
| 全自动 vs 人工兜底 | 异常频次高、规则稳定、可枚举 | 异常频次低、规则多变、需人工判断 | 全自动方案在规则变更时容易产生静默错误 |
| 数据完整 vs 数据实时 | 对账、结算、财务类场景 | 状态展示、客服查询类场景 | 强行统一会导致要么延迟高，要么数据不可信 |
我特别想强调一点：取舍的结论会随业务变化而过时，但取舍的理由不会。所以我在每个方案里都会写一份决策记录，格式是“背景，选项，选择，理由，失效条件”。
失效条件这一栏最有价值。它写的是“在什么情况下这个决策需要重新评估”。比如“当平台订单量增长三倍时，轮询方案需要重新评估”。有了这一栏，方案在两年后依然有生命力。
回到最开始那个项目。后来我们重新做了一轮调研，重点补了两块：一是拿到三个月的退款和取消数据做分布分析，二是访谈了客服和财务各两人。结果发现，真正影响效率的不是订单拉取，而是退款回补和对账口径。
调整方案后，人工补单从每天 150 单左右降到 30 单以内，财务对账周期从 5 天缩短到 2 天。这个改善不是来自更强大的功能，而是来自更准确的调研。
所以我对“订单同步场景的市场调研怎么做”的最终答案是：调研不是为了证明方案可行，而是为了找出方案在什么条件下不可行。把所有不可行的条件列出来，方案自然就清晰了。
如果你的下一步是启动这样一个项目，我建议按这个顺序推进：
做到这六步，你拿到的就不只是一份调研报告，而是一份能支撑长期演进的方案底稿。订单同步这件事没有终点，平台在变、业务在变、订单结构在变，唯一稳定的能力是持续把边界问清楚的能力。
我之前接手一个ERP项目，老板让我先做市场调研，我第一反应就是去搜竞品功能列表，结果列了满满几页纸，评审时被问‘这些功能解决的是谁的什么问题’，我一句都答不上来。后来才发现，调研的起点错了，后面全是白费。
先别碰功能清单，先把调研目标定义成五个决策问题：同步哪些对象（订单、退款、取消、物流、库存、财务）、同步到什么程度（实时、准实时还是定时批量）、异常怎么处理（超卖、部分发货、回传失败）、谁使用这些数据（运营、客服、仓储、财务、IT）、成功指标是什么（延迟、异常率、人工干预率、对账差异率）。
这五个问题回答清楚了，再去访谈和看竞品，才知道该看什么。判断依据很简单：如果一份调研报告只回答了“支持哪些平台”，说明还停留在功能罗列，没有进入方案设计。
我第一次做调研时只约了运营总监聊了两个小时，对方讲得头头是道，我以为信息够了。结果方案上线后客服天天投诉退款订单状态对不上，仓库说超卖没人管。我才明白，一线角色的问题根本不会出现在管理层视角里。
至少覆盖六类角色：运营（关心订单流转效率和平台规则）、客服（关心退款、取消、地址修改的状态回传）、仓储（关心推仓时机、拆合单、超卖回补）、财务（关心对账口径、币种、时区、手续费）、IT（关心API限流、失败重试、数据隐私）、实施顾问（关心不同客户的配置差异）。
每类角色问法不同，比如对客服要问‘哪种订单状态不符会让你必须人工介入’，对仓储要问‘推仓后平台取消订单，库存怎么回补’。判断调研是否充分的标准：你能不能画出每个角色在异常订单上的完整操作路径。
我之前做的调研只画了正向流程：下单、支付、推仓、发货、签收、回传，看起来很顺。结果客户上线第一周就遇到平台取消已推仓订单、部分发货后客户改地址、退款后库存没回补三个问题，方案里一个都没覆盖。那次之后我才知道，异常流程才是订单同步调研的真正重点。
建议按四类异常逐一拆解：逆向交易（取消、退款、退货、换货）、履约异常（超卖、部分发货、物流停滞、签收失败）、同步异常（接口超时、限流、数据格式变更、重复推送）、数据异常（多店铺订单归属错误、多币种金额换算、时区导致日期错位）。每个场景要写清三件事：触发条件、当前人工处理方式、期望系统处理方式。
判断依据：如果调研文档里异常场景数量少于正向场景，基本可以判定这份调研不完整，上线后人工补单量会远超预期。
我见过太多调研报告，几十页访谈记录和竞品截图，交上去之后没人看，产品经理还是不知道先做什么。我自己也写过这种报告，后来被leader说‘这是素材，不是调研输出’。从那以后我开始固定用一套输出结构，评审效率完全不一样。
建议输出四份东西：第一，场景-角色-平台矩阵，把每个订单同步场景对应到具体角色和具体平台；第二，需求优先级清单，用Must/Should/Could分类，每一条标注来源（哪个角色、哪个场景、哪个竞品验证）；第三，风险与合规清单，包括API限流、费用、数据跨境、税务要求，全部标注核实来源和日期；
第四，一页纸调研摘要，给管理层看结论，给产品看需求，给实施看风险。判断依据：如果一份调研输出不能直接回答‘第一版先做哪三个场景’，说明它还是素材，没有变成决策依据。调研的终点是可验证的方案假设和优先级，不是信息量的堆积。
读者评论
把“支持哪些平台”换成“超限怎么办”这句太真实了。我们去年选型也是功能清单打勾满分，上线后逆向退款回补全靠人工。场景边界表确实是复用率最高的产出，但项目组经常到测试阶段才补。建议加一条：调研结束前必须拿到三个月异常单分布。
角色影响图这点被低估了。订单同步失败八成不是技术问题，是运营、客服、仓储对“谁负责补单”没共识。我们做过一个多店铺项目，仓储和客服互相甩锅两周才定下异常归属。建议访谈执行者时直接问：上个月最花时间的三个异常是什么。
文章方法论很扎实，但环形图里11个项目、堆叠图9个项目的样本量偏小，结论当经验参考可以，当量化依据要谨慎。另外多时区对账错位这段值得单独展开，T+1的“T”在不同时区定义不同，财务口径不统一比接口失败更难查。
作为正在做选型的人，最有价值的是“拿不到接口文档、异常说明、沙箱就不签”这条。之前差点因为演示效果好就定了一家，后来要沙箱才发现对方在部分平台用非官方接口。假设清单写成“如果……那么……”也能直接拿去和供应商对质，比需求文档好用。