数据分析做了这么多年，大部分产出回答的是同一个问题：**发生了什么。**上个月成交多少，哪条航线涨了，哪个销售转化率低。
这些有用，但它们离一个决定还差一步。看完报表，人还得自己想：那现在该选哪个？选错了代价多大？
我现在更愿意把这件事分成两种：**Data Insight 回答「发生了什么」，Decision Insight 回答「现在选哪个、选错代价多大」。**后者才是业务真正缺的。
先建决策清单，不先建洞察平台
做「洞察」最常见的起手式，是先搭一个平台：接数据、做看板、加问答，然后等人来问问题。我之前写过，人一天没有那么多问题，这种平台最后多半在等。
反过来做：**先列出公司里到底有哪些决定要做，每个决定由谁做、多久做一次、依赖什么数据。**以私人航空的销售为例，一份初稿大概是这样：
| 频率 | 决定 | 依赖 | 谁做 |
|---|---|---|---|
| 每单 | 报多少毛利，什么时候让价 | 同线同机型成交价、价格敏感度 | 销售 |
| 每单 | 询价发给哪几家运营商 | 真实在飞的飞机、回复速度、拒单与换机记录 | 销售 |
| 每天 | 丢掉的单要不要追，怎么追 | 客户最后飞了谁、复购规律 | 销售主管 |
| 每周 | 哪些客户快要流失 | 客户飞行规律、全市场航班数据 | 销售主管 |
| 每季 | 哪些航线、机型值得提前锁运力 | 需求预判、空腿分布、毛利分层 | 管理层 |
| 每年 | 下一个开哪个市场 | 市占率、未被服务的需求 | 管理层 |
上半张表是战术决策：高频，决定每一单的打法。下半张是机会洞察：低频，决定方向。两者需要的数据、交付的节奏、出错的代价都不一样，不该塞进同一个看板。
清单写出来以后，不用全做。建议补全到十五到二十个决定，先做金额最大的三个。
每条建议交付四样东西
一条 Decision Insight，我要求它必须带齐四项：
- 建议：选哪个，一句话说完。
- 可信度：包括同类建议过去的命中率。不是模型自己报的置信度，是历史上真的对了多少次。
- 依据：引用的每一个事实都能追溯到来源。
- 推翻条件：什么情况下这条建议失效。
前三项大家都能想到，第四项最容易被省掉，也最重要。
一条不写推翻条件的建议，读者只能选择信或不信。写了推翻条件，读者就知道该去核对什么：「建议发给这三家，但如果客户坚持要当天往返，第二家的宵禁会让它出局。」这句话的后半截，比前半截更像一个资深销售会说的话。
能说清自己在什么情况下是错的，才是一个可以被托付的判断。
让命中率自己长出来
第二项里的「历史命中率」，一开始是没有的。它得靠回写：每条建议，销售采纳了没有，最后结果如何，都记回去。
这和决策痕迹是同一件事。攒一段时间以后，管理层看到的就不再是「AI 说选这家」，而是比如「在这类问题上，AI 的建议过去八成是对的；在那类问题上，只有一半」。人对 AI 的信任，应该按问题类型分开给，而且应该由数据来给。
复盘的时候还要守一条规矩：只能用做决定那一刻已知的信息去评判建议。事后才知道的事，不能拿来说当时的建议对或错。
和控制点的关系
上一篇我写过，洞察接不到控制点，就只是一条通知。决策清单其实就是在找控制点：每一个决定，都是一个业务链路上真实存在、可以被改变的节点。
先有清单，洞察才知道该接到哪里；先有四项交付，接上去之后才配得上那个位置。
所以
下次有人说要做一个「智能洞察平台」，我会先问两个问题：
它要帮谁做哪一个决定？它给出的建议，会不会告诉你自己什么时候不成立？
答不上第一个，它是一个看板。答不上第二个，它是一个说得很笃定的看板。