# 客户追问新用例时，FDE 该怎么接话

> 关键不是推销，而是回应但不承诺，再把信号交给负责扩展的人，而这个人各家公司并不相同。

原文: https://fdetimes.net/zh/guides/fde-customer-asks-new-use-case/

设想你正处在一次部署的第三周。发票抽取数据管道终于能在真实数据上稳定运行。客户的运营负责人看完演示，点点头，问道：“这个能读报关单吗？”

这个问题可能带来一份更大的合同，也可能变成一个公司里谁都没同意过的承诺。客户经理（AE）和客户成功经理（CSM）都不在这场演示里，所以前线部署工程师（FDE）得先开口。

这里需要的能力不是推销。你要识别出信号，回应但不承诺，再把信号送到正确的路径上。处理不好，AE 会丢掉机会，或者 CSM 觉得自己的工作被抢了，客户则从三个人那里听到三种说法。

## 扩展信号到底归谁？

老实说，要看公司。Firecrawl 的 FDE 招聘启事明确写道，客户扩展是 FDE 的职责：发现扩大用量、增加用例和扩大合同的机会。启事还说，FDE 不必等 CSM 来提示增购机会，因为在那里，FDE 被视为离客户最近的人。

客户成功领域的负责人 Chad Horenfeldt 描述的是相反的模式：续约和发现扩展机会的大部分工作属于 CSM。

在他看来，人越深入地去构建和设计解决方案，离收入就越远。他还对其中的摩擦提出了一个假设：也许销售觉得客户成功在侵入自己的地盘。

Underdog.io 把 FDE 定义为售后技术岗位，不负责签单，也不背业绩指标。FDE 的考核看三件事：客户是否真正在用产品，产品是否解决了业务问题，客户是否续约。

后两项几乎与客户成功的工作重合。于是，三个角色都会碰到同一个信号，但各自的考核标准不同。

**要点:** FDE 发现扩展信号；背业绩指标的人负责报价。

## 会上该怎么回答客户？

回到报关单的问题。好的回答分三步：肯定这个问题，进一步了解问题本身，再说清楚谁会回来讨论范围。示例话术：

“这个问题很有价值。我能多问几句吗：你们每月大概处理多少份报关单？现在由谁处理？通常在哪些环节出错？我们这周会发一份技术可行性说明给您。范围和合同方面，我们客户团队的 Lan 会跟您联系。”

这段话术刻意避开了三句很容易脱口而出的话：“当然，这很简单”“应该不用额外收费”和“我周末试试看”。第一句是在没看到任何数据前就作出的技术承诺。

第二句是价格承诺，这不该由 FDE 来做。第三句则把一次商业机会变成了范围之外的免费工作。

## 写信号记录：五行就够

当天写一份简短记录，发在这个客户的共享频道里，而不是私信给某一个人。以报关单为例，五行模板可以是这样：

```
谁提出的：运营负责人，X 日演示时
问题：报关单目前靠人工处理；数量由客户自行估算
现有证据：发票数据管道在真实数据上运行，运营团队每天都在用
技术可行性：需要报关单样本才能评估，尚未承诺任何事
已告知客户：AE 会就范围联系对方
```

“已告知客户”这一行最重要。它告诉 AE 和 CSM 客户正在等什么，下次通话时就不会有人无意中说出和你相矛盾的话。

## 交给 AE 还是 CSM？

如果公司没有明确规定，可以按信号性质分类，如文首图表所示。客户在同一用例内用得更多，或出现不续约的迹象，由 CSM 主导。

出现新部门或新买方，由 AE 主导。同一买方的新用例，则由两人共同商量。这是一种合理的分工，不是铁律，要和该客户的 AE 与 CSM 确认。

新买方的情况与 Firecrawl 的描述一致：FDE 与增长团队配合，向技术买方展示产品如何解决他们的问题。FDE 出现在商务对话中，但身份是提供证据的人，而不是敲定价格的人。

## 让 FDE 两头不讨好的错误

第一个错误是压着信号不报。设想一名 FDE 看出客户有更多需求，私下顺手做了个试用版本，AE 三周后才知道。到那时，客户已经习惯了免费拿到成果，合同谈起来就很尴尬。

第二个错误正好相反：把自己变成销售。Perspective AI 的实践手册提醒，当 FDE 向首席营收官（CRO）汇报时，薪酬、OKR 和市场进入（GTM）组织内部的政治因素，会推动他们在客户那里追求可计费工时，而不是构建产品中可复用的部分。

每个新需求都变成一次性项目，产品什么也学不到。

第三个错误是忘了自己终将离开。同一份手册建议，大多数 FDE 项目应在上线后 120 天内移交给客户成功和产品工程团队。你没记录下来的信号，会在你离开这个客户时随你一起消失，接手的 CSM 只能从零开始。

## 读职位描述，弄清你将进入哪种模式

KORE1 指出，有些公司把 FDE 放在 CRO 的组织下，因此汇报关系因公司而异。它还观察到，混用售前工程师、解决方案工程师和 FDE 这几个头衔的招聘启事，几乎都是由销售部门的人撰写职责范围的 FDE 岗位。

所以面试时要问三个问题：你向谁汇报，谁对扩展指标负责，FDE 发现的信号走哪个渠道。如果职位描述里有类似 Firecrawl 的“推动客户扩展”这类表述，就准备好一个具体的故事：讲讲你某次发现客户的新需求并交给商务一方的经历。

简历上不要写“支持销售”。要按顺序写：你发现了哪个用例，有什么证据，交给了谁，结果如何。招 FDE 的人想看到的是你懂得边界在哪里，而不只是你很积极。

下次客户问“这个能做 X 吗？”，你只有几秒钟来回答。把这几秒用来进一步了解问题，而不是作出承诺。

**本周动手试试:**

- 翻看过去两周与客户沟通的记录，找出至少一个类似“这个能做 X 吗？”的问题，把它写成一份信号记录
- 问问当前客户的 AE 和 CSM，他们各自希望收到哪类信号，通过哪个渠道
- 在简历上加一行，描述你某次发现新用例并带着证据交给商务一方的经历

## 信源

- [Forward Deployed Engineer, Firecrawl](https://scoutify.com/companies/firecrawl/jobs/735876/)

- [Forward deployed engineers as CSMs: It's a trap](https://chadhorenfeldt.substack.com/p/forward-deployed-engineers-as-csms)

- [What Is a Forward Deployed Engineer in 2026](https://underdog.io/blog/forward-deployed-engineer)

- [What Is a Forward Deployed Engineer? Role, Skills & Salary](https://www.kore1.com/forward-deployed-engineer/)

- [How to Build a Forward-Deployed Engineering Function: A 2026 Founder's Playbook](https://getperspective.ai/blog/how-to-build-forward-deployed-engineering-function-founder-playbook-2026)