Cloudflare 销售运营的 AI 三支柱:让市场进入团队效率翻倍

Justin Joyce · Cloudflare 销售运营负责人 · 2026-09-26
听中文精华AI 合成朗读00:00
我见过完全不懂 SQL 的用户——过去他们的请求会卡在「找一个懂数据、能为复杂查询写 SQL 的人」这个瓶颈上——而现在他们能直接向数据提问并获得答案。
— Justin Joyce

关联

一个销售运营团队要同时服务高管的分析需求、领导层的指标需求和一线销售的客户信息需求,靠人肉在 Excel 里一周泡好几个小时,是撑不住的。这一集的演讲者是 Cloudflare 的首席销售运营与策略经理 Justin Joyce——他从销售起步,在 Grainger 做了约七年机器学习,六个月前回到销售运营,把两边技能合起来改造 Cloudflare 的市场进入(go-to-market,即产品从销售到触达客户的全流程)运营。他开场的判断很直接:传统的市场进入方式无法规模化。

问题出在哪

Joyce 把问题拆成两块。一块在后台运营侧:运营团队最差在 Excel/Sheets 里每周手工构建分析,项目一多工作量指数级增长;最好也就是做仪表板,满足大多数团队但不是所有团队的需求——团队需要信息的时候,不一定拿得到。

另一块在销售侧,有两个差距。第一个是上下文差距:销售一通电话在谈新客户,下一通在谈老客户的采用(adoption)对话,再下一通可能在处理客户满意度,他们必须不停切换上下文,而每次切换所需的背景信息都得自己在通话之间收集。第二个是他称之为专家差距的东西:专家级销售处理一个场景的方式——怎么跟潜在客户谈、怎么打采用电话、怎么应对拒绝——和一个刚上手的新销售之间落差很大;理想状态是所有人在同一个运营水平上执行,保持评估客户问题与产品匹配的表达一致性。

三支柱框架

Joyce 给出的解法是三支柱:规模化分析、规模化洞察、给市场进入团队自助服务能力。他强调,三者缺一,智能体系统就服务不好市场进入需求。

支柱一:规模化分析。 团队构建了特定角色的技能文件——把业务知识的上下文与数据关联起来、供 AI 使用的信息文件,技术和非技术用户都能用。

关键做法是:通过测试,把业务会向数据提出的各类问题预先嵌进技能文件,比如商机截止日期的变化、商机金额的变化,这样能覆盖 80% 以上的常见问题,剩下 20% 才是更复杂的战略问题。效果很实在:完全不懂 SQL 的用户,过去他们的请求会卡在「找一个会写 SQL 的人」这个瓶颈上,现在能直接向数据提问拿到答案;团队还用同样的技能文件快速构建了多个应用——这类活儿以前归 IT 且必然排队。腾出来的时间转向战略和赋能。

支柱二:规模化洞察。 核心理念是「数据里有一个故事,但人们不应该非得自己去搜它」。

团队每周自动发出一份摘要:业务进展、相对目标的节奏,以及趋势、亮点和需要关注的事项——就像打开手机看当天备忘一样,把故事推送给团队,而不是让他们去仪表板里挖。Joyce 承认仪表板有用武之地,但任何公司里 KPI 指标的采纳程度都是分层的:有人热爱仪表板,也有人永远不看,所以需要一个能覆盖全业务的脚手架。

实现方式有两层。数据层:按时间、业务逻辑切分(管理者、区域)和指标预处理数据,把「怎么筛选、怎么聚合」的业务逻辑全部前期工程化,让 AI 智能体能以一致、干净的方式分析,这能处理 80% 以上的请求。

编排层:一个**多智能体工作流**——第一个智能体取数并产出初稿(调用 MCP,即让模型调用外部工具/数据的接口),第二个审阅者智能体核查数据真实性,第三个「语气」智能体用多示例提示词撰写消息,同等突出风险与机会;每次运行对每个 LLM 调用都有可观测性(能看到每次模型调用的输入输出)。这套架构测试了两三个月、逐次检查每次运行哪里出错,才稳定下来。

支柱三:自助服务。 这是 Joyce 认为最大的一个支柱。

Cloudflare 内部有个叫 Cloudflare OS 的智能体工作区,跑在 Cloudflare 自家产品上:用 Cloudflare Workers 加 Durable Objects(一种持久化存储,类似 S3)为每个销售启动自己的计算和持久环境。销售进来就能拿到场景所需的专家级信息——左下角的技能仓库由市场进入团队和运营团队共同策划、集中审核,防止技能泛滥,保证每个层面都有专家级知识,覆盖任何客户情境。具体用例包括:预测简报、QBR(季度业务回顾)幻灯片、新客户已购内容的购买说明幻灯片、客户规划、数据查询、续约准备——比如查客户已经用了什么,决定怎么向上销售或推动更深采用。

心得与下一步

Joyce 总结三条心得。技能策划是一切智能体化劳动力的基础——把业务知识嵌进技能文件,才能让智能体系统以更可预测、更确定性的方式运行,全团队执行均匀。

反馈循环很重要——像对外卖产品一样对待内部工具,持续确认做的东西真有用、问题在哪。三支柱分层互补——有的团队喜欢来找你提问,有的靠推送,有的自助,三者交织才能覆盖所有需求。总效果:效率翻倍。

未来方向:一是与工作系统的深度集成——比如把 QBR 幻灯片和续约通话技能自动嵌入销售会议,不用手动拉取,以及从通话中自动获取会议记录;二是更硬的问题——报价、审批和直接更新 CRM,他们在用 Salesforce,正在构建用智能体系统更新它的连接,同样会用多智能体工作流保证正确性。最后一个观察很点题:现在用智能体系统处在「寒武纪阶段」,用 AI 解决一切问题的方法在爆发式增长;但随着走向完整集成和标准化,需要回头找一种战略性的方式让各团队使用智能体系统,保证唯一事实来源和所有系统对得齐。

本集带走

  • 三支柱缺一不可:规模化分析(运营团队提效)、推送洞察(数据故事主动送上门)、自助服务(销售随取随用),只做其一解决不了市场进入的低效。
  • 把高频问题预先工程化进技能文件:通过测试摸清业务会问什么(如商机日期/金额变化),嵌入筛选与聚合逻辑,覆盖 80% 以上的请求,AI 才能稳定输出。
  • 关键分析用多智能体把关:产出、审数、语气三个智能体分工,每次运行可观测,测试两三个月逐次纠错才上线——可靠性是编排出来的,不是天生的。
  • 技能仓库要集中策划审核:防止技能泛滥,保证每个场景都有专家级知识,这是缩小新老销售「专家差距」的核心手段。
  • 效率翻倍后把时间还给战略:让不懂 SQL 的人直接问数据、绕开 IT 瓶颈建应用,运营团队才能聚焦策略与赋能。
全部金句 2 条

我见过完全不懂 SQL 的用户——过去他们的请求会卡在「找一个懂数据、能为复杂查询写 SQL 的人」这个瓶颈上——而现在他们能直接向数据提问并获得答案。
So I’ve seen users who do not know any SQL, and essentially their requests in the past, we bottleneck to someone who knows data and can write SQL for complex queries, be able to just ask questions of the data and get answers.
—— Justin Joyce · [08:02]

另一件事是,我们在某种程度上已经到了使用智能体系统的寒武纪阶段——兴奋、技能以及用 AI 解决一切问题的方法正在爆发式增长。
And the second thing is we’re sort of reached the Cambrian stage of using agentic systems, which means there’s an explosion of excitement and skills and finding out ways to solve anything with AI.
—— Justin Joyce · [18:20]

接着看

顺着「智能体」挖下去

换个口味