从老板报价到长尾承接：FDE用AI打通工程租赁获客与报价

访谈资料整理：依据 Datawhale《FDE案例100》所收录访谈。案例叙述与成果均归属于原访谈，本站未进行独立项目审计。

原案例封面

为什么这个案例值得看？

工程租赁中小企业的获客、报价、调度和管理高度依赖老板，长尾订单又涉及车辆、操作员、油费、距离和作业类型等变量。项目重新串联获客、询价、报价、人工判断和调度，让系统为相对标准化的长尾需求计算报价区间，由 AI 沟通、老板处理高价值客户。

这个案例的价值不只在于采用了某种模型，而在于把数据、规则、系统和人工责任连接成可执行的业务链路。落地过程围绕问题识别、方案选择、交付路径、业务结果和关键难点展开。

一、企业与业务场景

项目实践表明做FDE，第一件事其实是先把老板真正想解决的问题搞清楚，再判断这里能不能用AI。

工程租赁就是一个很典型的例子。

项目团队接触到的客户，本身是一个比较典型的中小企业。

这个行业有一个很明显的特点：老板往往就是唯一的销售、唯一的调度，很多管理工作也都在老板身上。

这家企业的客户结构也很典型：营收3000万的时候，可能2500万来自几个大客户，剩下500万来自大量的小客户。

在业务上行的时候，这500万的长尾客户其实可以不管。

老板精力有限，大客户就已经够忙了，小客户丢了也就丢了。

但是到了下行周期，情况完全不一样。

原来觉得无所谓的500万，可能明天就真的没有了。

这时候老板就会发现，自己有客户，却没有能力把所有客户都接住。

所以项目团队真正要解决的，是一个更具体的问题：老板没办法服务的那些长尾客户，能不能被接住？

再往下拆，问题就更清楚了。

比如一个10万元左右的小订单，看起来金额不大，但真正报价的时候，远比简单的加减法复杂。

客户租什么车、要不要配操作员、油费怎么算、距离多远、运输成本是多少、具体干什么活，不同作业类型又会影响折价。

这些因素叠在一起，最后形成的是一个比较复杂的报价判断。

面对这种情况，FDE不会纠结方案“是不是纯AI”，因为真正解决问题的东西，本来就应该是混合的：一部分是模型和Prompt，一部分是传统的业务规则，还有一部分甚至是运筹学。

只要最后能解决老板的问题就行。

二、原有流程与核心问题

其实过去这种方式完全可以运行，而且在业务增长期甚至是比较合理的。

因为大客户的价值足够高，老板亲自谈、亲自报价，是最有效率的方式。

价格不透明、订单金额大、影响因素复杂，这些事情交给老板判断，反而比做一个复杂系统更靠谱。

真正的问题出现在长尾订单上。

一个小客户进来之后，老板同样要把需求、车型、运输成本、人员、油费这些因素都过一遍，再决定最终价格。

如果老板正在谈一个大客户，这个小订单就只能放掉。

所以过去的问题，是随着市场环境变化，原来合理的人工分工开始出现了瓶颈。

尤其进入下行期以后，企业开始重新重视那些过去没有被充分服务的小客户。

这个时候，原来的模式就出现了矛盾：老板最应该做高价值客户，却被大量低价值、但不能完全放弃的订单占用了精力。

这也是项目实践表明FDE很重要的地方。

如果只是站在技术视角，可能很容易得到一个“做智能报价系统”的结论。

但真正进入业务现场以后，可以看到，问题其实是老板的时间应该花在哪里，以及企业有没有能力把老板不应该亲自处理的事情接下来。

三、AI 解决方案与交付路径

项目团队的思路其实比较简单，但真正做起来，比单纯做一个AI报价机器人复杂得多。

第一步，是先把整个业务链路梳理出来。

项目团队先把客户怎么获客、客户从哪里进来、怎么询价、哪些订单老板必须亲自处理、哪些订单其实可以标准化这些问题看清楚，再考虑模型怎么选。

这里面项目团队甚至会把抖音、快手、小程序这些东西一起考虑进去。

因为如果前面没有获客入口，后面做一个很漂亮的报价工具，其实没有意义。

对于这类客户来说，让客户为了询价专门下载一个App也不现实，所以入口反而应该足够轻，比如直接通过小程序承接订单。

第二步，是把订单做分层。

大客户不能交给AI。

因为大客户的价格不透明，而且订单价值足够高，老板自己判断才是合理的。

所以项目团队的做法，是把大客户和长尾客户分开。

对于相对标准化的小订单，系统先收集需求，再根据车型、操作员、油费、距离、作业类型等因素计算一个合理的报价区间。

AI负责和客户沟通，判断订单能不能快速成交。

如果在这个区间里客户接受了，就可以继续往后走；如果不接受，或者判断这个订单比较复杂，就直接放弃，或者转人工。

甚至项目团队设想的节奏是：一个订单几分钟内完成判断，能成交的就快速进入调度，不能成交的就不要继续消耗老板的时间。

第三步，是把AI放进原来的业务流程，让客户沿用原来的工作方式。

这一点其实特别重要。

除了工厂租赁这个客户，项目团队面对的很多其他中小企业客户，一线员工可能是中年人，学历也不高，甚至不愿意使用小程序。

那如果为了技术上的“最优解”，要求他们换工具、改习惯，最后这个东西很可能根本没人用。

所以项目团队会围绕客户原来的使用习惯做适配。

必要的时候，前端做得足够简单，甚至加入语音或者微信Bot。

技术方案未必最优雅，但在真实业务里，它才能真正跑起来。

这也体现了FDE角色的一项定位：适配的方向，是把AI做成适合客户业务的人，有的时候让传统企业客户快速进行组织和流程变革反而会出现大问题。

四、项目结果与业务价值

这个项目目前还比较早，项目团队实际开始做这类业务只有一个多月。

但从已经落地的几个点来看，客户对效率提升的感受是比较明显的，他们也是认可这个结果之后，才愿意继续从这个点往下做。

工程租赁这个案例里，项目团队解决的核心价值，也远远超过“少用几个人”。

真正有价值的是，把原来老板没有精力处理的长尾客户接住。

过去一个小订单进来，老板如果正在处理大客户，很可能直接放弃；现在可以先由系统完成信息收集、报价区间判断和初步沟通。

只有真正值得老板介入的客户，才把人的精力重新拉回来。

所以项目实践表明这里的价值应该从三个层面看。

第一，是效率。

原来一个小订单也要消耗老板的时间，现在很多判断可以由AI前置完成。

第二，是增收。

长尾订单被承接之后，本身就带来新增收入，这也是项目团队和客户谈合作时比较核心的价值。

第三，是人的工作方式发生变化。

AI在这里的作用，是把人的带宽释放出来。

老板可以把更多时间放在真正高价值的客户和决策上，而企业也有可能承接更多订单。

项目团队和这个客户讨论的，除了按年走的系统维护费，还有增收分成的合作方式。

不过增收分成的方式在其他客户那里也并不是很好得到泛化，因为增收分成在实际谈判里比较难量化，所以最后怎么设计更好的商业模式，还在探索。

五、关键落地难点

真正落地以后，FDE发现最大的挑战，很多时候在AI之外。

第一个挑战，是需求看起来很简单，但真正做起来很复杂。

比如客户说“业务人员要一个内部数据库，再做一个基于数据的搜索”，听起来好像很简单。

但真正进去之后，可以看到数据库到底怎么搭、数据怎么清、数据量多大、检索怎么做，这些成本都很难提前估算。

有些项目最后真正难的地方，其实是数据库和业务数据的整理，跟AI模型本身没太大关系。

所以项目团队后来会特别注意一个问题：不能因为客户说得简单，就默认交付也简单。

第二个挑战，是客户的接受程度。

中小企业老板通常不会因为项目团队告诉他“这是一套先进的AI技术”就愿意大规模改造企业。

相反，大刀阔斧地改内部流程，对他们来说风险很高。

所以项目团队的打法一直是从一个很小的点切进去。

先找一个客户能看见结果、试错成本比较低的问题，做一个POC（Proof of Concept，概念验证）。

POC跑通之后，客户觉得项目团队靠谱，再继续往下梳理路线图。

这条路是边做、边证明、边挖下一步需求，先让客户看到结果，再去谈更大的蓝图。

第三个挑战，是AI工具本身不能决定项目成败。

项目团队接触的几个案例，其实并没有简单套用一个通用AI工具。

能用现成工具解决当然最好，但解决不了的时候，项目团队会自己做工程化。

因为真实业务里，很多东西本来就是混合的，智能报价就是这样，光靠一个通用AI工具往往解决不了全部问题。

还有一个很现实的问题：使用率可能很低。

如果老板自己都不用，这个项目基本推不下去。

所以项目团队会把“一号位是否愿意采用”当成很重要的判断标准。

同时，不能指望客户员工突然学会一堆新工具，更实际的做法，是把入口做得足够简单，尽可能嵌入他们已经习惯的工作方式。

六、FDE 交付方法与企业启示

交付经验可以归纳为以下几点。

第一条，不要先找AI场景，要先找业务问题。

项目团队不会刻意要求自己每个项目都必须“AI味很重”。

如果一个问题用传统数字化就能解决，那就用传统数字化；如果AI能够让原来的流程效率提升，那就把AI放进去。

比如工程租赁这个项目，真正解决问题的其实是整个获客、询价、报价、调度链路，AI只是其中的一部分。

第二条，是先做小点，再进入大流程。

尤其对于没有品牌、没有咨询溢价的FDE团队来说，上来就告诉客户“企业帮业务人员做一次企业AI转型”，基本很难。

更现实的办法，是找到一个足够小、足够具体、又能让客户马上看到效果的问题。

先做出结果，再让客户相信企业的能力；有了信任，再去谈更大的路线图。

这个过程本身就是FDE的价值。

第三条，是不要把“标准化”理解成100%复制。

项目团队确实会沉淀一些东西。

比如销售Agent、非结构化数据检索、报价系统等，底层工程框架可以复用，代码和经验也可以沉淀下来，下一次遇到类似问题，交付速度就会更快。

但真正做到一个完全标准化、跨行业直接复制的产品，项目实践表明很难，且绝对的标准化产品往往竞争烈度也是极高的，且对真正想要做AI转型的企业客户来说不够深。

因为一旦进入客户真实业务，数据、流程和行业规则都会发生变化。

所以FDE更适合做的是：底层能力标准化，业务解决方案保持一定程度的定制化。

最后还有一点，项目实践表明重要：FDE团队需要既懂AI、又懂业务、能够理解企业经营的复合型人才，只会写代码或只懂咨询都还不够。

因为AI真正进入企业之后，价值远远超过“少三个人”，员工的工作方式、管理方式、评价体系，以及企业能够承接的业务规模都会发生变化。

要看到这些变化，就必须理解客户真正的生意。

所以从项目实践看，项目团队正在做的事情，是进入业务现场，找到企业原来做不到、做不好或者没精力做的那一小块，然后用AI和工程化能力，把这块真正跑通。

跑通以后，再一点点往外扩。

这可能才是AI从“技术能力”真正变成“业务能力”的过程。

七、可复用的交付资产

同类项目若要复制这条路径，可以优先沉淀以下交付物：

• 场景访谈记录与 As-Is／To-Be 流程图
• 业务对象、关键字段、角色责任和异常分支清单
• Agent 工作流定义、工具调用清单、提示词版本和任务评测集
• 系统集成图、字段映射、权限配置、失败重试与回写日志
• 覆盖普通、复杂和异常任务的验收样本与业务指标口径
• 人工审核、失败回退、上线巡检和持续迭代清单

来源与作者

Datawhale《FDE案例100》，受访者：赵云淞（崧望科技创始人）；PDF 第 229-236 页，书内页码 228-235。本文为访谈资料的第三人称整理，不是本站新采访。