在供应商会议中提出自己的问题
在供应商会议上，最有效的事情就是拿起键盘。将你自己的业务文档——一份混乱的合同、一个支持线程有三个人在交谈，或者来自格式最差的供应商的发票——交给系统进行实时处理，他们没有准备好。
观察会发生什么变化。响应时间、回避、格式、答案自信度。一个在未经排练的情况下能保持形状的系统至少已经接触过现实世界一次。
如果供应商拒绝，问清楚原因。“你的数据没有加载到沙盒中”是一个合理的答案。接受它，然后将测试写入合同作为签署前的条件，并附上你的文件和你对通过的标准定义。
询问错误时的处理方式
暂时忽略准确率百分比，问问剩余的8%是什么样子，从用户角度看。只有三种可能：系统表示不知道、升级到人工处理或者给出一个自信但错误的答案。
失败得响亮便宜运行，而失败得安静则昂贵，因为成本落在了根据错误信息采取行动的客户和花一周时间解开麻烦的员工身上。
然后要求看到一个系统拒绝回答的例子。拥有可工作产品的团队通常会自豪地展示这些，因为克制是难以实现的。
询问答案来源
与你自己的材料（政策、价格、合同、产品规格）相关的一切都应引用其来源。要求提供引用，然后打开它。问题不是链接是否出现过。关键在于引用的文档是否确实包含答案所声称的内容。
做这个两次。两份检查比一个小时的幻灯片展示告诉你更多关于系统的情况。
询问数据更改后的第二天
演示基于一个冻结的快照。但你的业务并非如此。这些问题能区分产品和原型：
- 新或更正信息如何进入，多久一次，以及谁负责？
- 当文档被删除或替换时，系统停止使用它需要多长时间？
- 系统是否尊重你现有的权限，还是每个人都会得到相同的答案，无论角色如何？
- 基础模型发生变化时，你能提前测试吗？
- 周一晚上九点系统出错时，谁在值班，响应时间是多少？
模糊的回答在这里是你会得到的最强烈的信号。一个在生产环境中运行过产品的团队已经经历了所有五个问题。
要求提供一些需要费用的数字
幻灯片中的百分比免费。要求提供具有形状的数字——用户数量、持续几个月、与什么基线比较，以及谁进行了测量。"解决60%的一级票据"在没有了解重定向其他40%的成本之前意味着很少东西，而这个数字来自一个只有十人的试点项目，还是来自一年有千人的项目。
优秀的供应商会提供具体且谨慎的答案。已经交付过真实系统的团队对压力点了如指掌，并且会在没有被推动的情况下明确地说出来。
询问系统无法处理的情况
要求供应商描述其系统不适合的使用案例。一个自信的团队会准备好这个答案，通常非常准确：长篇扫描文档、超出评估集的语言、任何需要法律风险判断的案例。
一个声称能处理一切的团队告诉你他们还没有在足够艰难的环境下测试系统，所以你会在合同签署后发现边缘情况。
最后一个问题
离开前，要求看到一个现有客户在普通二天的视角。不是演示：仪表板、日志、升级案例队列、周五早上阅读的报告。真实系统会积累这种无聊但重要的家具，因为有人必须操作它们。排练好的演示没有周二。
我们经常坐在买方座位上，模式保持不变：能够通过这些问题的系统很少在演示中看起来很出色。它们看起来单调、具体且有监控功能。这是工作的外观。