知道客户为什么还没买车，与知道明天该怎么跟进，之间还有一段距离。

销售经理看到一批试驾后尚未下订的购车机会，决定让团队加强跟进。顾问面对的情况却可能各不相同：有的家庭仍在比较车型，有的用车人满意、购买人尚未参与沟通，有的已经约好回访。把它们放进一张「尽快联系」的名单，未必能推动成交，还可能造成重复打扰。

本体为团队提供共同的业务理解，行动定义明确怎样推进业务，Agent 则把查询、判断与执行组织成具体任务。 三者围绕同一次购车机会配合，才能从「发现尚未下订」走到「准备下一次有效跟进」。本文先定义一个回访动作，再解释 Agent 怎样准备跟进简报，以及如何核对工作结果。

如果希望了解业务语义如何用于实际任务，可以先查看 WinNexo 产品概览，本文随后解释一次销售跟进怎样组织。

从「尚未下订」到下一步，先找到待解决的问题

前面的文章已经定义了家庭、个人、购车机会、体验与订单，并解释这些定义怎样落到数据和知识中。团队能够知道哪次需求已完成体验、是否满足下订条件。但相同的业务状态，仍可能需要不同的下一步。

购买人尚未参与车型讨论，可以先确认是否需要一次共同沟通；车型顾虑尚未解决，可以准备适用的产品资料；已经约好回访，则应核对安排。行动要针对当前问题，不能只根据「尚未下订」给出统一话术。

找到问题，首先要把资料放回同一次机会。客户单元采用家庭，实际沟通则落实到个人。同一位家庭成员在不同购买需求中，可能承担不同角色；同一家人的多次试驾，也可能属于同一个机会。顾问需要知道本次准备联系谁、对方参与过什么，以及讨论的是哪一次购买。

还要检查问题是否仍然存在。试驾录音中的「想比较另一款车」可以提示顾虑，但后续沟通可能已经解决。沟通时间、发言人和后续记录共同影响当前判断，不能把一次表达直接当成未成交的原因。

这样，洞察才带出了可以检查的决定：对这次机会，准备解决什么，依据是什么，希望下一步改变什么。证据不足时，可以先核实需求；已有明确依据时，再准备回应或协同事项。

把回访定义清楚，人才知道确认什么，工具才知道执行什么

先选一个足够小的动作，例如为购车机会确认一次回访安排。它只负责把安排登记清楚，实际沟通及购买结果随后分别记录。

联系人不能简单等同于「客户姓名」。确认使用体验，可能应联系实际用车人；讨论购买决策，可能需要购买人参与。角色应从本次机会的关系和沟通记录核对，不能根据家庭成员身份推断谁拥有最终决定权。

顾问确认的也应是一份具体方案：对哪个机会，联系哪位个人，什么时候，解决什么问题。只让人点击「同意加强跟进」，仍然把关键判断留给后续执行者。

延续 01 篇对 Action Type 的介绍——围绕业务意图定义操作，让不同应用使用一致的行动含义——企业可以将这样的定义落实到相应业务服务或流程，供人员与 Agent 使用。

图：回访安排的行为关系——方案经业务前提与执行授权核对后，进入源端业务服务登记并回读完成证据；安排登记完成后，实际联系和客户反馈仍需分别记录。

把任务组织方式对应到界面和配置时，应核对岗位、知识与技能需要准备哪些资源。

Agent 准备跟进简报，需要语义、知识和工作方法共同配合

行动明确之后，可以把「准备试驾后的跟进简报」交给 Agent。

先定义交付范围。简报以当前顾问负责的购车机会为单位，检查已完成体验、截至查询时点尚未满足下订条件、且购买需求仍有效的机会。体验时间范围由团队约定；同一机会重复试驾时，应避免名单重复。

每项结果提供当前进度、相关个人角色、仍需核对的问题和下一步建议，并保留依据。已存在回访安排的机会，应呈现已有安排，帮助顾问决定复用、调整还是追加工作。

为了完成这项交付，Agent 要使用不同类型的信息：

语义中心通过对象图谱、业务逻辑与分析视图组织业务定义，经团队确认发布后，岗位可以使用共同口径查询和分析。按机会查看最后一次已完成体验及当前订单状态，与按手机号统计试驾次数，服务的是不同问题；任务需要选择合适的解释。

知识则帮助补足下一步判断。某位家庭成员提出后排空间顾虑，Agent 可以检索适用车型资料及沟通原文。明确表达的顾虑可以列为准备事项，根据材料推测的疑问则应交给顾问核实。内容相似的资料，也要检查车型和版本是否适用。

岗位组织资源与职责。销售顾问关心自己下一次沟通，店长还需要发现长期缺少后续记录或需要协调的机会。岗位可以关联业务语义、知识库、技能和应用连接，使 Agent 按相应职责使用资源。

技能保存团队希望重复执行的方法。例如先查机会名单，再核对角色和已有安排，检索最近沟通及适用资料，最后生成带来源的简报。复杂方法可用技能说明文件、配套资料与脚本组织，经审核发布后复用；工具连接则提供实际查询或操作能力。

语义说明事情怎样理解，技能组织处理方法，工具提供实际能力。 修改下订口径，应检查语义定义；简报需要增加店长协调事项，应调整工作方法和输出；接口发生变化，则检查工具连接。职责分开，维护和排错才有明确位置。

图：岗位、技能和工具共同支持跟进准备任务——岗位说明指导行为，数据与操作授权仍需在实际调用处落实。

从生成方案到正式操作，每一步都要核对当时的条件

生成时的核对

Agent 的计划应随着工具返回的结果调整。查到机会后，可以继续检索沟通材料；机会与录音关联不明确，就留下待核对项；发现已有回访安排，则交给顾问检查。能确认尚未下订、却不能确定联系人时，仍可交付进度与材料，把角色核对留给人，不能为了简报完整而补一位联系人。

空结果也需要解释。没有查到体验记录，可能与关联缺失、查询范围或数据更新有关。在排除这些问题前，不能把它写成「该家庭没有试驾」。缺材料时，任务可以完成已有证据支持的部分，并明确剩余事项。

执行时的核对

需要登记正式安排时，再使用前面的行动定义。人判断方案是否适合客户和销售现场；相应业务服务校验执行时的状态、参数与调用身份。上午生成的方案，到下午可能遇到客户已下订、负责人已调整或已有同类待办，操作前应核对关键条件，不能把延迟同步的数据当成源端当前状态。

多人协作下，重复安排和版本检查应在相应业务服务中处理。岗位说明要求「只处理本人机会」，查询范围与资源权限也要按实际身份配置。自然语言指导不能代替系统授权。

如果调用超时，应先按请求标识或业务记录核对结果。系统可能已经创建活动，只是回执没有返回。需要重试时，由相应服务识别重复请求，避免重复安排——即幂等设计（同一操作重复提交，系统只执行一次），这也是资料来源中 AWS 幂等 API 设计所讨论的问题。

运行方式与触发

顾问可以临时发起一次准备，也可以将日常检查配置为自动化任务，明确岗位、范围、技能、计划和产出位置。任务支持手动、定时与外部通知等触发；采用业务事件时，应考虑周期检查和数据更新节奏。每天营业前生成简报，便于顾问检查当天安排；更及时的任务再按实际事件来源配置。

执行状态、日志和产出帮助团队查明哪些内容已经完成。需要推送到 IM 时，还应确认接收范围和内容权限，让结果进入销售人员实际使用的位置。

安排已登记、联系已完成、客户已下订，分别用不同证据验收

工具返回「成功」，要先看它说明哪件事。

任务本身也需要验收。用已知机会检查重复体验是否造成名单重复，沿个人角色核对顾虑归属，将已解决问题与简报比对，再从建议回到原始记录。报告流畅不能代替这些检查。

业务结果则沿第二篇的共同口径衡量。在内容完整性和准确性相当的前提下，准备时间缩短可以说明效率变化；试驾到下订是否改善，需要相同机会范围、观察窗口和可比较的业务证据。创建任务数、实际联系数与下订单数不能相互替代。

回访产生的新事实，也应关联到同一次机会。客户说「周末有空」不等于确认到店，顾问判断「意向较高」不等于满足下订条件。保留原始表达、实际活动及节点变化，下一位顾问和下一次任务才能继续使用。

本文介绍的语义中心、岗位、知识、技能、应用连接和自动化机制，可以在 WinNexo 中配置。它将业务定义与可用资源组织到数字员工的工作中。进一步了解产品，可阅读 WinNexo 产品概览。

图：WinNexo 真实任务配置界面——岗位、执行计划、上下文与产出位置分别配置；截图仅展示配置方式，未保存或执行汽车销售任务。

继续阅读：05 从本体语义到业务行动：Dataphin × WinNexo 的产品架构

回顾：02 本体与业务语义：怎样让团队对“卖了多少辆车”形成一致理解？

资料来源

Palantir Action Types 与提交条件：行动定义、参数与校验。
WinNexo 语义中心与岗位：业务定义与资源组织。
WinNexo 企业技能：工作方法的创建、审核与发布。
WinNexo 自动化任务与事件中心：触发计划与执行记录。