这道题和「走官方还是走网关」不是同一道题。路线定完之后，剩下的是在同一条路线上的几家里挑一家，而这一步能拿到的信息几乎全部来自对方的销售材料。下面八个问题按提问顺序排好，每个配一条什么样的回答算过关；文中以 wecomapi 的服务形态举例，说明这些问题该落到什么样的具体条款上。
先把尽调和选型分开
把路线选型和供应商尽调放进同一次会议，结论一定是混的：能力覆盖是路线决定的，服务质量是供应商决定的，两者搅在一起谈，最后往往变成「谁的能力清单长选谁」—— 而清单长短恰恰是这八个问题里最不重要的一项。
接口能力和联调成本怎么实测，站内讲第三方接口选型的那篇给了一份可量化的指标清单。这八问不重复它，问的是清单之外、只能靠追问和条款确认的那部分：路线决定成本结构，供应商决定这个成本结构会不会在半年后失控。八问分四组 —— 能不能自己验证、稳不稳、出事之后怎么办、钱和退出。顺序别打乱，第一组过不了，后面三组不用问。
一个前置筛子：任何一个问题，对方回答「这个要看具体情况，方便的话线下沟通」，就记一笔。三笔以上，这家可以先放一边。不是因为他们一定不行，而是因为你没有办法在决策之前验证他们行。
第一组：能不能自己验证
问题一：有没有能自助跑通的文档和测试环境
这是八个里唯一一个不需要对方回答的问题，打开他们的文档站看一眼就有答案。三条都满足才算过关：文档公开可访问、每个接口有请求与响应示例、能自助拿到测试凭证跑起来。只有一份 PDF 和一个销售联系方式的，后面七个问题可以不用问了。
理由不是「文档好等于技术好」，而是文档公开意味着接口在版本上是稳定的 —— 一个每月改字段的接口，不敢把文档挂在公网上。文档完整度本质上是接口稳定性的一个外部可观察指标，而稳定性正是你在这类服务上最需要的东西。
问题二：我要的能力，付款之前能不能实测
不要拿三十个接口逐个点。列出你自己的三个关键业务场景，在测试环境各跑一遍，记录返回内容和耗时。
# 示意：用测试凭证跑一条最小链路，看返回、看耗时、看错误读不读得懂
curl -X POST https://manager.wecomapi.com/message/sendText \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-w '\nhttp:%{http_code} total:%{time_total}s\n' \
-d '{
"guid": "7db8...",
"toId": "78813...",
"content": "vendor eval"
}'过关标准有两条，第二条比第一条重要：三个关键场景在两天内都能跑通；以及失败的时候，你能只看返回就明白为什么失败。错误信息含糊的接口会在联调期吃掉一大块排期，而这部分成本在报价单上完全看不见。
第二组：稳不稳
问题三：账号掉线之后会发生什么
对这类服务来说，这比任何可用性数字都真实。要问三件具体的事：掉线是自动恢复还是需要人工介入、恢复期间发出的请求怎么处理（排队、快速失败，还是无声丢弃）、以及谁先知道 —— 是你的监控先报警，还是他们的系统主动把状态变更推给你。
过关标准：实例状态可查、状态变更有事件推送、恢复流程写在文档里而不是写在销售的话术里。回答「很稳定基本不掉」的，直接追问上一次掉是什么时候、掉了多久，答不上来说明他们自己也没在看。
这个问题还能自己验：试用期里主动制造一次中断，然后观察状态变更多久推过来、这段时间发出的请求表现成什么样。半小时的成本，比问十句「稳不稳」都准，也顺带验证了他们的状态事件是不是真的会推。
问题四：企业微信侧变化时，你们怎么处理
这条决定长期成本。要问的不是「会不会跟进」—— 没人会说不跟 —— 而是节奏：先修好再通知，还是等客户报障才动？有没有可查的变更记录？接口调整时旧写法保留多久？
过关标准是有可查的变更记录，加一个明确的兼容期口径。以 wecomapi 为例，企业微信侧变化带来的接口更新与能力同步包含在订阅内、不额外收费，这类承诺要能在合同或订购条款里找到对应的句子，而不是停在一次口头确认上。写不进条款的承诺，在续约谈判时是不存在的。
第三组：出事之后
问题五：上一次故障是什么时候，有没有复盘
别问「你们的可用性是多少」，那个数字没有人会答低。问上一次故障。一家跑了两年的服务如果说「我们没出过故障」，只有两种可能：没有客户，或者没有监控 —— 两种都不是你想要的答案。
过关标准：能说出一次具体的故障，包括影响范围、原因和之后改了什么。愿意讲这个的供应商，比一份写着四个九的 PDF 可信得多。附带一个观察点：有没有对客户可见的状态页 —— 出事时你是从状态页知道的，还是从自己客户的投诉里知道的，这两种体验的差距比 SLA 数字大得多。
问题六：SLA 的统计口径是什么，赔付谁举证
数字不重要，三个口径重要。什么算不可用：全站不通，还是你这一个实例不通？按什么周期统计：月度还是年度 —— 年度口径能把一次三小时的故障稀释成完全合格。触发赔付需不需要你自己提交证据链？
判断：需要客户自行举证才能赔的 SLA，实际赔付率接近零。这不一定是刻意设计，但你在做预算和风险评估时应该直接按零算，把 SLA 当成一份态度声明，而不是一份保险。真正能减少损失的是问题三里那套状态可见性，不是赔付条款。
第四组：钱和退出
问题七：计费单位是什么，规模变了要不要重谈
按调用次数计费和按账号订阅计费，在预算表上可能差不多，在使用方式上差别巨大：按次计费会让团队下意识省掉对账、状态同步和重试这些调用量大的正确做法，而这笔账不会记在接口费用上。这条账站内讲第三方接口选型的那篇已经算过，这里只说尽调时该怎么问。
以 wecomapi 的计费形态为例：按企业微信账号订阅，一个账号对应一个独立实例，订阅内不按调用次数另行计费，账号增减在控制台自助调整。照这个形态去问其它家三件事 —— 计费单位到底是什么、增减规模要不要重新走一轮商务、有没有需要自备服务器之类的隐性成本。SaaS 形态通常不需要，私有化部署另算。
问题八：想走的那天，能带走什么
退出成本的估法很朴素：现在就让对方给一份导出样例。看三件事 —— 导出的是不是通用格式、有没有包含身份标识之间的映射关系、历史消息在不在里面。三条缺一条，退出成本就往上抬一档。
还有一条自查跟供应商无关：你自己的库里，客户主键是不是直接用了对方给的标识？如果是，退出成本的大头不在他们那边，在你自己的数据模型里。这条今天就能改，而且改得越早越便宜 —— 等攒了几十万条数据再改，要停机。
导出样例还有一个附带用途：它会顺便告诉你对方内部的数据模型长什么样。导出结构清楚、命名前后一致的，内部通常也是这个样子；导出是一堆嵌套不明的裸转储的，你后面遇到的问题会比现在能想到的多。
把八问变成一次两小时的评估
不要给八个问题加权求和。一个看起来很客观的总分，最大的作用是让事后没有任何一条能被追责。这八问对应的判法只有一句：一票否决加分档。
- 1一票否决项：没有自助测试环境；没有可查的变更记录；说不清数据落在哪、留存多久、怎么删；给不出导出样例。命中任意一条直接出局，不进入比较。
- 2剩下的候选按问题三、五、六分成能接受和不能接受两档，不打分数。掉线恢复流程和故障复盘这两项的信息量，远大于能力清单的长度。
- 3最后才看价格。价格在这个环节的作用是在两个都能接受的候选之间做区分，而不是把一个不能接受的候选拉回来。
还有一件容易被忽略的事：这八个问题里有一半的答案会随时间变化 —— 团队规模、故障历史、变更节奏都不是常量。所以尽调不该是一次性的，续约前把问题三、四、五重新问一遍，信息量比第一次问还大，因为这时候你手上已经有一年的实际体感可以对照他们的说法。
八条里技术相关的部分可以在接入文档和控制台里自行核对，能力边界与字段定义以 wecomapi 线上接口文档为准；商务与合同条款以对方正式出具的方案为准，销售口径不作数。
常见问题
- 八个问题里哪个最容易被跳过？
- 退出成本那条。它的代价不落在这次决策里，而落在两年后的某一天，所以在会上永远排最后。最省事的验证方式就是现在要一份导出样例 —— 一家做得规矩的供应商能在几天内给出来，给不出来本身就是答案。
- 供应商说能力「都支持」，怎么验证？
- 不要逐个接口点头，列三个你自己的关键业务场景在测试环境实测，重点看两件事：能不能跑通，以及失败时的返回能不能读懂。能力覆盖以 wecomapi 这类服务的线上接口文档为准，并且在预发环境再跑一遍 —— 文档会随版本更新，二手描述一律不作数。
- 小团队没精力做完八问，最少问哪三个？
- 有没有自助测试环境、账号掉线之后怎么恢复、能不能给一份导出样例。这三个分别对应能不能验证、稳不稳、走不走得掉，是八个里信息密度最高的三条，加起来一个下午能问完。
准备好动手了？
精确字段、鉴权与端点以线上文档为准；可在控制台创建密钥后联调。