Why the Next Generation of Enterprise Software Looks Nothing Like Salesforce
a16z · 2026-09-17
Lightfield 用“活动日志+无结构数据”重做 CRM，客户用它一周内帮阿尔茨海默症患者找到前沿治疗，团队 40 人全员无岗位边界、每天动态排优先级。
最好的CRM不替人干活，先重建现实
Keith Paris 是 Lightfield 的 CEO。这家新 CRM（客户关系管理系统）公司刚完成由 a16z 领投的 4700 万美元 A 轮融资。更有意思的是它的前史：5 名创始成员里有 3 人来自 Facebook，团队做过 Instagram 和 Messenger 的产品；他们还曾把 AI 演示文稿产品 Tome 做到月活 200 万，却主动关掉它，转去啃企业软件里最难、也最脏的一块数据问题。这期访谈讲的不是“AI 怎么多写几封销售邮件”，而是：一家公司的客户事实，到底该由谁记录、如何校正，又能被推演到什么程度。
这期回答了 8 个问题：
- 一个月 200 万用户的产品，创始人为什么仍决定关掉它？
- 为什么 AI 不能只替销售写邮件，必须先重建公司的“客户现实”？
- CRM 为什么应该从“字段表格”变成一条关系时间线？
- 不预设数据模型，企业系统如何避免日后无法挽回的配置错误？
- 一个 CRM 怎么帮助阿尔茨海默症患者在数天内找到前沿治疗？
- AI 时代的软件定价，为什么按席位和纯按用量都会失效？
- 当所有人都能用 AI 做产品时，公司如何既保持高速又不失控？
- 一家新 CRM 如何防止客户最终还是迁回 Salesforce？
被问到为何在 Tome 增长迅猛后仍选择彻底转型时，Keith 给出的答案并不浪漫。Tome 在 ChatGPT 上线同期推出，曾达到每月 200 万用户；当时推理算力不够，用户甚至需要排队才能生成内容。按通常创业叙事，这已经是该加速扩张、融资、招人的时刻。但团队越做越确定：它始终做不出真正高质量的演示文稿，也看不到投行、咨询公司，或高标准的演示文稿制作者会把它当成不可替代工具。
问题不只是模型当时不够强。演示文稿质量取决于演讲者是谁、听众是谁、双方此前有什么关系、这场沟通要推进什么目标。通用模型可以写得流畅，却不知道一页材料该让谁放心、让谁行动。"No amount of general reasoning gets you past that."（再多的通用推理能力，也跨不过这个坎。）
这意味着，AI 产品的护城河不会随着模型升级自动出现。若产品拿不到决定任务成败的专属上下文，再高的使用量也可能只是一次性工具的热度。团队曾考虑缩小规模，等待 GPT 继续进步；但他们判断，等待只能改善文字和排版，补不上关系信息的缺口。一个月 200 万用户，仍不足以改变这个结构性判断。
被问到 Tome 转型后如何找到下一个问题时，Keith 回忆，他们先从约 2500 万用户中寻找 B2B 使用场景，发现销售和市场部门最活跃。团队找来周边约 50 万人规模公司的 12 个免费试点，最初承诺做新业务 deck 和提案。很快，客户的要求开始外溢：能否做客户研究、筛选线索、判断哪些公司有扩张机会？
为了完成这些任务，团队要求接入 CRM、通话记录器和数据仓库。接入后才发现，真正难的不是生成一封邮件，而是不同系统说的是不同版本的现实：CRM 里有一套销售记录，通话记录器里又有一套；两边都不完整，也常常互相矛盾。"The work required to reorganize it felt like the most important work."（重新组织这些信息所需的工作，感觉才是最重要的工作。）
此前他们做过 GTM 助手，销售人员每天都在用，却没人愿意为它付出足够高的价格。原因很直接：数据不属于他们，市场上还有约 10 家相似公司。这个经历说明，替销售做研究、写内容，能带来使用频率，却未必带来数据控制权。先统一客户事实，才可能让后面的提示词、自动化和智能判断有可靠地基，也才有定价权。
被问到 Lightfield 为何能做出不同于传统 CRM 的底层体验时，Keith 把答案追溯到团队的 Facebook 经历。5 名创始成员中有 3 人来自 Facebook，他们借鉴的不是传统销售软件，而是 Facebook Timeline 的思路：先记录关系如何按时间发生，再从这条记录中提取结构。
于是，Lightfield 最先构建的是活动日志。它记录何时首次联系、双方说过什么、开过哪些会、传过哪些文件；关系进入客户阶段后，还继续记录对方如何使用产品、如何付款。传统 CRM 熟悉的字段更新、销售阶段更新，不再是原始事实，而是由活动日志触发的派生结果。"You always have this like canonical log of relationship that everything's built on top of."（你始终拥有一条规范的关系日志，所有东西都构建在它之上。）
这意味着，CRM 的中心不再是要求销售手工维护一张静态表，而是让机器持续重建客户关系的演变过程。团队也试过完全非结构化存储，但查询速度太慢，像在海里找针。最终采用半结构化方案：保留邮件、通话、使用记录等大块非结构化信息，同时保留可查询的结构，让系统能从时间线中推断因果。自由不等于不设边界。
被问到不同规模的企业怎样完成初始配置时，Keith 提到团队专门访谈过 CRM 顾问。他们发现，顾问最关键的工作往往不是导入数据，而是替客户决定数据模型：销售阶段如何划分，字段保留哪些，哪些对象之间要建立关系。这些决定看似只是配置，实际上会决定公司往后几年如何看待自己的销售流程。
难点在于，一旦阶段和字段设错，销售人员几乎不会回头补齐历史数据。过去漏掉的信息就像没拍下来的监控，想重新建档时，证据已经散在旧邮件、旧会议和人的记忆里。Lightfield 因此采用近似无 schema 的设置。schema 就是预先规定“数据必须长成什么样”的模板；用户只需连接邮件、通话记录器和数据仓库，系统先自动拼装关系，之后再补字段。字段修改后，还能回溯活动日志重新填充。"Intelligence is greater than schema."（智能比 schema 更重要。）
产品把这一过程压缩成点击同步、等待约 5 分钟，并通过内置数据补全来源自动组装结果。这意味着，实施成本从一开始“猜对未来组织长什么样”，转向让 AI 从已有行为中持续归纳结构。传统 CRM 的配置错误难以挽回，正是这种设计要绕开的代价。
被问到客户正在用 Lightfield 做哪些旧系统做不到的事时，Keith 讲了 Power 的案例。Power 一端与药企合作，帮助寻找临床试验参与者；另一端聚合患有不同疾病和并发症、正在寻找前沿疗法的人。它不是一条“销售线索—成交—续费”的简单漏斗，而是一张同时包含患者、疾病、临床试验、药企和匹配状态的多方关系网。
Lightfield 支持任意 schema、自定义对象和自定义关系，因此 Power 能把 B2C 的患者侧和 B2B 的药企侧放进同一系统。他们还搭建自动化流程，抓取 FDA 和 clinicaltrials.gov 上的临床试验信息，再将患者情况与正在进行的试验、相应药企进行匹配。"Lightfield actually helped someone with Alzheimer's find frontier treatment within days."（Lightfield 实际上帮助一位阿尔茨海默症患者在数天内找到了前沿治疗。）
这意味着，一旦企业系统记录的不只是销售字段，而是可被推理的多方关系，CRM 的边界就会从内部营收管理向外延伸。它可以处理跨组织的复杂匹配：谁符合什么条件、哪一方下一步该联系谁、哪些信息正在改变判断。这里的重点不是 CRM 突然变成医疗产品，而是同一套关系建模能力，能够承载远比销售管道复杂的现实。
被问到 AI 时代 CRM 应怎样定价、能否按结果收费时，Lightfield 已经踩过两个极端。第一种是纯按席位收费，最符合 Salesforce 和 HubSpot 的旧习惯，客户也容易接受。但团队发现，头部重度用户的模型消耗量，是长尾轻度用户的 10000 倍。"The head was using 10,000x more than the tail."（头部用户的消耗量是长尾用户的 10000 倍。） 如果所有人同价，少数用户就可能吃掉大部分成本。
第二种是纯按用量，所有功能都用 credits 计费。结果更糟：用户注册后几乎不再操作。Keith 把那称为公司“最糟糕的三周”。原因不难理解：CRM 是每天都要打开的记录系统。若每次录会议、更新任务、查看信息都像打开出租车计价器，用户会先算账，再决定是否使用。
团队后来把工作分为四类：日常 CRM 记录、管道生成、工作流自动化、智能与预测。最终采用平台费加核心 CRM 席位费，覆盖可预算的日常记录；对能产生额外价值的线索生成、自动化及智能能力按用量收费。结果定价也不能简单照搬，因为给 OpenAI 做外呼，和给一家连网站都没有的种子公司做外呼，成果差异主要由客户自身的产品市场匹配度决定，而不全是软件功劳。
被问到 AI 如何改变研发和交付速度时，Keith 先反思 Tome 的组织问题。那时产品、市场、客户成功各自有“泳道”，甚至会抗拒别人对自己领域的反馈。部门边界像身体末端和大脑断了线：公司一旦需要转型，各部分都在按旧任务运转，整体就很难掉头。
Lightfield 约有 40 人，所有人每天参加同一场 standup，共同给最重要的问题排序。问题可以属于交付、工程或客户成功，谁有空谁接手；任务列表每天可变，每周重新评估。Lightfield、设计系统和 Linear 的连接又让不同角色更快补齐客户与项目背景，因此工程师、设计师、客户成功经理都能带项目。"Everyone owns product and everyone owns customer success."（每个人都负责产品，每个人都负责客户成功。）
这意味着，AI 削弱了“只有某个职能才能理解某类问题”的壁垒，但它没有取消质量控制。Lightfield 的项目启动门槛很低，发布门槛却很高，仍保留全公司 bug bash，产品要先获得内部认可才能交给客户。没有后一道门，“人人都是通才”只会变成人人都能开工、没人对成品负责。
被问到当前最担心什么时，Keith 没有先谈 Salesforce 的品牌、渠道或客户存量，而是谈速度。他读过一份关于 11 Labs 的报告：这家公司曾使用一款创业公司 CRM，但需要的仪表盘四个月都无法交付。团队厌倦了反复等待，最终迁回 Salesforce。产品是否更现代，在这种时刻并不重要；客户要的是明天能用的能力。
这正是系统级产品的残酷之处。CRM 一旦成为核心记录系统，企业会把销售、客户成功、财务识别收入等日常动作都压在上面。选错系统的心理成本很高，换系统的迁移成本也高，但如果关键能力长期缺失，客户仍会回到熟悉的旧系统。"We just have to build everything."（我们就是得把一切都做出来。）
这句话不是说一家公司真能无差别复制所有功能，而是说它必须覆盖客户经营中足够完整的能力面。一个锋利的 AI 功能可以赢得试用，却不一定能承接企业的日常。Keith 明确承认，这仍是 Lightfield 尚未解决的风险：任何一个长期没有补上的关键仪表盘、流程或管理视图，都可能让客户重新产生“还是 Salesforce 更稳”的念头。
被问到未来最兴奋的方向时，Keith 描述的已经不是更自动地录入会议，或更快地更新销售阶段。他希望用户直接问 Lightfield：该招多少销售？下一个产品该做什么？公司应该往哪里走？这类问题过去通常要靠运营团队拉数据、写 SQL、做报表，再由管理层和外部顾问反复讨论。
他举了一个客户的例子。这家公司主要销售给企业客户，却通过 Lightfield 发现自己需要推出一款面向中端市场的产品。这个判断没有停在一页分析里，而是促成了一整条新产品线。"I'm stoked about Lifefield becoming your sort of crystal ball for scenario planning."（我非常期待 Lifefield 成为你用于情景规划的某种水晶球。）
这里的“水晶球”不是承诺预测永远正确，而是改变决策的输入方式：公司不必先把零散数据手工拼成报告，再讨论下一步；可以围绕持续更新的客户关系、产品使用和业务活动，直接进行情景规划。有人可以用一个下午或一个周末与系统对话，形成推进计划。但这个能力的前提没有变：底层关系必须足够准确。若客户现实本身是错的，推演得再聪明，也只是在错误地图上规划路线。
从“爆发式增长救不了一个创始人自己都不爱用的产品”，到“AI CRM 的原子单位不该是字段，而该是客户关系的时间线”，Lightfield 的路线其实一直指向同一件事：AI 不该只是代替人按按钮，而要先拥有一份持续更新、可追溯、能校正冲突的业务现实。
这也解释了为什么他们放弃了只写邮件、做研究的 GTM 助手，转去重做 CRM；为什么他们强调“先定死数据模型的 CRM，往往在第一天就埋下失败种子”；又为什么最后想让 CRM 参与“该招多少销售、该做什么产品”的决策。没有关系时间线，所谓预测只是从残缺字段里猜答案；没有可回溯的事实，自动化越多，错误扩散得越快。
对读者所在的团队也是一样。先别急着问 AI 能替你完成多少任务。更该问的是：客户信息散在哪些系统里？谁在维护它？邮件、会议、使用行为和成交记录是否讲着同一个故事？如果这些事实仍互相打架，那么最该优先重建的，不是又一个助手，而是公司理解现实的方式。
