Tome 转向 Lightfield：让 AI 读懂客户，先重做 CRM

原始资料：《Why the Next Generation of Enterprise Software Looks Nothing Like Salesforce》

节目：a16z Podcast。嘉宾：Lightfield 联合创始人兼 CEO Keith Peiris。主持人：Joe Schmidt、Alex Rampell。YouTube 视频发布于 2026-09-16，时长 00:52:04。

a16z 于 2026-09-09 宣布领投 Lightfield 四千七百万美元的 A 轮融资，也是本期节目的发布方。本文依据访谈及官方资料整理；产品效果、客户案例和内部经营数据，均保留受访者的陈述边界。

Tome 做到了约两千五百万用户，Keith Peiris 和团队却越来越难回答一个问题：这款产品，究竟能让谁离不开？

它能用 AI 生成演示文稿，也曾以每月约两百万新增用户的速度增长。但 Peiris 回忆，团队始终看不到一条清晰的路，能让对内容要求很高的专业人士，把它变成日常工作的必需品。

后来，他们把公司收缩，转向客户关系管理软件，也就是 CRM。新产品叫 Lightfield。

这次转向保留了一个老问题：AI 到底知道多少背景？做演示文稿，需要理解讲述者、听众和双方关系；做销售、判断续约、决定开发什么产品，同样需要理解客户以及事情发生的前因后果。

Lightfield 把客户关系的完整记录放在产品中心，再让 AI 基于这些记录工作。 这也逐渐改变了它的界面、收费方式和团队组织。

用户很多，仍然要找到离不开产品的人

在回顾 Tome 的转向时，Peiris 没有把原因简单归结为模型还不够强。

团队考虑过缩小规模，等待下一代模型。但一份专业演示文稿的好坏，依赖大量没有写在提示词里的背景：讲述者知道什么，听众关心什么，双方已经沟通过什么。单纯提高通用推理能力，并不会自动补齐这些信息。

他们开始从原有用户中寻找企业场景，找到销售和营销团队，做了 12 个试点。最初的承诺是帮忙做销售演示和方案，客户很快提出更多要求：研究公司、判断线索质量、寻找扩大合作的机会。

为了做这些工作，团队接入 CRM、通话记录和数据仓库，随后发现，最难的部分是把记录拼起来。会议里说的是一种情况，CRM 里填的是另一种情况，有些重要背景还根本没有留下来。

他们先做了一个销售工作助手。按 Peiris 的说法，客户每天使用，却很难愿意为它支付足够的钱。数据和核心记录仍掌握在别的系统里，同类助手又很多，团队缺乏定价能力。

接下来，他们收缩团队，用约 4 个月重做 CRM。没人愿意轻易采用一个刚做出来的客户管理系统，办公室的空位反而成了获客工具：愿意使用产品的创业公司，可以免费来办公。

最初来了 10 家。产品缺功能、速度慢，用户仍然每天打开，还会大约每隔 2 小时在 Slack 里反馈问题。Peiris 把这种持续使用和不断催促，视为与 Tome 很不一样的信号。

增长证明有人愿意试，持续依赖才让团队看见了产品的位置。

先保存关系发生的经过，再生成字段

Lightfield 的起点是一条客户关系时间线。

Peiris 说，5 名创始成员中有 3 人来自 Facebook。他们借鉴了时间线的思路，先记录一家公司与另一家公司怎样建立关系：什么时候首次联系，说了什么，开了哪些会，交换了哪些文件，后来怎样使用产品、怎样付款。

这份按时间排列的活动记录，成为系统的基础。传统 CRM 里的字段、交易阶段和任务，可以从这些记录中更新出来。

这样一来，团队后来想增加一个字段，或者重新定义客户分类，系统还有机会回头读取历史，把相关信息补出来。信息采集不再完全取决于销售当时有没有想到填写某一栏。

Peiris 把这称为企业的 business world model，可以理解为一份持续更新的业务关系模型。它要保留客户是谁、发生过什么、状态为何变化，让人和 AI 都有共同的背景。

这里的免配置，也有具体边界。他们试过把数据完全不加结构地存下来，查询太慢，最终采用了半结构化方式：保留大量原始互动，同时组织客户、联系人和关系，方便检索与分析。

换句话说，用户可以晚一点决定字段，系统仍然需要认真组织数据。Peiris 用连接邮箱后等待约 5 分钟完成初始组装，描述他希望提供的使用体验；这段访谈没有给出不同数据规模下的实测保证。

这种记录方式服务于很实际的问题。例如，判断哪些客户适合扩大合作，系统需要把往来沟通、支持工单、产品使用情况放在一起看，再比较不同客户。只有一个客户名称和一个销售阶段，远远不够。

同一套关系模型，也能连接临床试验与患者

访谈中的Power 案例，展示了自定义关系的用途。

按 Peiris 的描述，Power 一端帮助制药公司寻找临床试验参与者，另一端连接寻找治疗机会的人群。它在 Lightfield 里同时组织企业端和个人端的关系，并结合 FDA、ClinicalTrials.gov 的试验信息进行匹配。

这里要管理的对象，已经超出了常见的公司、联系人和销售机会。试验、参与者、制药公司，以及它们之间的条件与联系，都需要被表达出来。

Peiris 还说，这套流程曾在几天内帮助一位阿尔茨海默病患者找到前沿治疗机会。访谈没有提供入组记录、治疗结果或疗效证据，因此这个例子能说明寻找与匹配信息的用途，不能据此判断治疗是否有效。

对产品设计更有参考价值的是：同一个业务模型，应该容得下客户真实存在的关系，而不必让每家公司都把业务硬塞进同样几张表里。

新公司容易开始，老习惯仍会回来

Lightfield 最初选择争取新成立的公司。它们还没有被多年积累的旧系统绑住，替换成本相对小。

Peiris 承认，团队一开始并没有想清楚怎样说服已经使用成熟 CRM 的公司迁移。他和同事自己找创业公司、联系 YC 团队，先争取成为一家新公司的客户管理系统，再从使用中寻找下一步。

他提到，有客户加入时销售人员还是 0，后来增长到 100 人。团队花了约 6 个月观察这类快速成长的公司，逐渐发现，仅仅自动发邮件、做线索评分，很难构成长期的替换理由。帮助公司理解客户、判断方向，可能更有价值。这是他的观察，不能把客户自身的增长归因于 Lightfield。

不过，新公司也会雇来习惯旧软件的销售负责人。创始人愿意试新产品，新来的销售主管却可能坚持换回 Salesforce。

Lightfield 的一个应对办法，是在由销售团队洽谈的方案中，让公司其他同事也能使用产品，无需每个人都额外购买席位。工程团队可以了解客户，财务团队可以查看与收入确认有关的信息，客户成功团队可以评估账户。

这既增加了系统能理解的背景，也让它进入更多人的工作。迁移决定于是需要考虑整个公司的使用方式。Peiris 认为，这给了团队更多机会，去向新来的销售主管证明产品的价值。

表格继续保留，自动化可以重新写

AI 产品要怎样让用户工作，Peiris 的选择很务实。

他自己仍然用表格视图开销售会议，也认为很多人习惯每天看同一张仪表盘。因此，Lightfield 保留表格和看板，同时提供自然语言操作与命令行入口。

变化更明显的是销售自动化。过去，设置一组跟进邮件，需要把触发条件、变量和分支连成流程图。在他描述的新工作方式中，用户先与智能体讨论，智能体结合业务记录写出执行方案，再按方案运行。

稳定的查看方式可以保留，繁琐的配置过程则有机会缩短。 两者并不需要同时被推翻。

Lightfield 也允许客户通过 MCP 或命令行接口，把数据交给自建智能体使用。Peiris 强调，数据属于客户，产品需要持续证明自己的价值。

他的观察是，有客户尝试自己搭建智能体运行环境，过一段时间又回来，原因包括客户与联系人识别、检索准确性、信息找全的能力和响应速度。他也提到，有较大的公司试着自建企业知识系统，最后发现，理解客户关系本身就是一项很难的工作。

这些属于厂商的客户经验，访谈没有提供对照测试。不过，它提出了一个具体的成本问题：能够调用模型以后，谁来长期维护同步、数据质量、关系识别和执行流程？演示能跑起来，只覆盖了其中一部分。

定价走过两个极端，最后拆成四类工作

Lightfield 先试了纯席位收费。客户容易理解，因为已有软件就是这样卖的。

但 Peiris 说，重度用户与轻度用户的消耗量可以相差约 10,000 倍。这个数字描述的是使用消耗，无法换算为收入或生产力差距。只按人数收费，很难覆盖这种差异。

团队又试过所有操作都扣点数。结果客户几乎什么都不敢碰。Peiris 把那约 3 周描述为公司非常难熬的一段时间：有注册，缺使用。

他们随后与客户讨论，在定价设计中区分四类工作：

• 日常 CRM 工作。记录会议、更新字段、整理任务。客户希望预算稳定，不愿每次查看或更新基本记录都计算成本。
• 开发销售机会。研究目标公司、补充资料、争取会议。客户更容易接受为额外完成的工作按量付费。
• 工作流自动化。例如，收到演示申请后，研究这家公司，再把线索分给合适的销售。工作内容相对明确。
• 分析与预测。把业务记录用于情境分析，讨论招聘、销售流程或未来方向。客户愿意为什么结果付费，还需要继续探索。

访谈时，他们采用的组合是：核心 CRM 收取平台费和席位费，其余工作按使用量收费。这是在讲当时形成的定价逻辑，具体方案仍应以产品当下的说明为准。

至于按成交结果收费，Peiris 的顾虑在于，结果同时取决于客户的产品竞争力和市场需求。同样一轮开发工作，替成熟产品找客户，与替一家尚未建立清晰定位的创业公司找客户，难度完全不同。

因此，Lightfield 当时选择为完成的工作收费，还无法稳定地把收费绑定到最终销售结果。

四十人一起排优先级，开始容易，上线严格

Peiris 对 Tome 还有一个反思：团队曾经太早地把自己组织成一间成熟公司。

产品、营销、客户成功各管一块，跨过职责边界提意见都不容易；计划又做得很远，需要转向时，整家公司很难一起移动。

他描述的 Lightfield 工作方式更直接。公司当时有 40 人，每天参加同一个站会，把最重要的问题放在一起排序。问题可能来自工程、交付，也可能来自客户成功，有空且能处理的人接过去。

计划持续调整，每周再检查优先级。工程师、设计师和客户成功人员都可能负责一个项目，专业能力仍然存在，只是不把职位当作不能跨越的边界。

这种协作依赖背景资料更容易获取。Lightfield 帮同事了解客户，模型工具可以操作 Figma 中的设计资源，与 Linear 的连接则帮助建立任务。

自由开始项目，也需要持续取舍。团队每周检查路线图，判断客户要求是否符合公司的方向；发布前仍然做全公司参与的集中试用和找错。Peiris 的标准是，团队自己先认可，才交给客户。

降低开始一个项目的门槛，同时提高交付给客户的门槛，是他维持速度与一致性的方法。

产品必须跟上客户长大的速度

问到最担心什么，Peiris 的回答是速度。

一家公司刚成立时能用的 CRM，未必能支持它扩张后的管理需求。只要报表、流程或协作能力长期跟不上，客户就有理由迁回成熟系统。

Lightfield 因此把客户未来约 3 年的扩展价值放进优先级判断，更倾向于为增长最快的客户补齐能力。初次签约的金额可能不大，产品能否陪它长大，决定了后续关系。

硅谷客户还有另一层作用：帮助建立进入其他行业的可信案例。Peiris 提到，有客户已经融了两亿美元，负责销售与市场拓展的却只有 3 人。眼下的收入贡献有限，未来可能成为向同行展示的样本。

医疗健康是他举的一个方向。他说，这类交易可能涉及约 50 个相关方，处理复杂客户背景、较早投入安全建设，以及已有客户的推荐，都帮助了销售。这里反映的是他的经验，不能把访谈当作安全能力的认证。

购买业务核心系统时，公司还在判断一件事：类似自己的团队，是否已经长期用得起来。产品能力之外，同业案例也参与建立信任。

从记录发生过什么，走向讨论下一步

Peiris 最期待的用途，是让 Lightfield 帮助公司做情境规划：该雇多少销售，接下来做什么产品，进入哪个市场。

他在访谈末尾提到，一家原本面向大型企业的客户，通过分析业务记录，发现可以做一条面向中型企业的产品线，随后着手开发。这是一个未具名的客户案例，没有披露后续经营结果。

这个方向能否成立，仍然取决于前面的基础工作。记录是否完整，冲突是否被处理，客户关系是否被正确理解，都会影响后续判断。访谈也没有给出预测准确率。

Tome 到 Lightfield 的经历，把一项常被低估的工作摆到了台前：让机器持续理解一家公司的真实业务，需要长期积累和整理背景，生成能力只是其中一环。Lightfield 的产品定位，正建立在这个判断之上。

给正在转向的创始人，Peiris 最后的建议仍然很具体：找到客户的痛点，确信自己愿意解决它，然后把注意力放回客户。免费办公室里的那批用户，每天打开产品、不断催功能，曾经给过他比用户总数更清楚的方向。