先给结论
AI 处理询盘的正确终点不是自动回复，而是让每封询盘进入同一套可追踪流程：抽取事实、标记缺口、计算可解释的优先级、建立下一步任务、生成待审草稿，再由业务员确认报价、交期、认证、付款条件和发送动作。HubSpot 的评分能力可以基于明确的记录属性和行为，工作流也可以按指定条件触发任务；Gmail 则把创建草稿与发送设计为两个独立动作。这正好构成一条“机器整理、人类承诺”的安全链路。
输入字段
每条询盘至少保存原始邮件、发件人、公司与域名、国家或地区、产品、数量、用途、目标交期、认证要求、贸易条款、付款偏好和来源渠道。缺失就是缺失，Agent 不得根据语气、姓名或邮箱后缀补造采购规模与真实意向。
分层规则
1. 业务匹配：产品、市场、数量和用途是否落在可服务范围。
2. 身份证据：公司网站、企业主体、联系人角色和邮件域名能否相互对应。
3. 采购信号：是否给出具体规格、数量、时间、交付地或已有项目背景。
4. 风险信号：是否要求异常付款、绕过合同、发送敏感资料，或主体与收货路径冲突。
5. 信息缺口：还缺哪些内容才能报价，而不是用一个黑箱总分掩盖缺失事实。
评分只能引用已经存在的字段或行为。每一次加分、减分都要能显示规则与原始证据，业务负责人可以修改权重，也可以直接否决结果。
工作流状态
新询盘先进入“待抽取”，完成字段整理后进入“待核验”；身份和需求达到最低条件时建立负责人任务，状态变为“待追问”或“待报价”。高风险命中进入“人工复核”，信息不足进入“待补充”，明确不匹配才进入“关闭”。任何状态变化都要记录时间、触发条件、负责人和下一步截止日。
邮件草稿而不是自动发送
Agent 根据原文和缺失字段生成一封 Gmail 草稿：先复述已确认需求，再提出最多三个关键问题，最后给出明确的下一步。Gmail API 创建草稿与发送草稿是分开的操作，因此系统只调用草稿创建，把发送留给业务员。草稿中不得出现未经确认的最终价格、交期、库存、认证结论、独家承诺或付款安排。
今日行动
抽取最近十封真实询盘，建立统一字段表。先由业务员手工给出真实优先级和下一步，再让 Agent 运行一遍；逐条比较字段准确率、遗漏项、错误推断、任务分配与草稿修改量。只有连续样本稳定，才把规则接到自动建任务和自动起草。
生意验收
交付一个可用工作台：十条询盘记录、每条证据来源、可解释评分、状态、负责人任务、截止日和待审邮件草稿。至少记录首轮整理时间、有效回复率、进入报价率、人工修改率和高风险拦截数。成功不是生成了多少字，而是业务员更快完成正确的下一步，同时没有发生未经批准的商业承诺。
停止条件
客户主体无法核验、需求和数量不清、成本或产能数据缺失、风险规则命中、CRM 字段含义不统一，或草稿涉及价格、交期、认证、付款与合同承诺时，停止自动推进并转业务负责人。评分规则、触发条件或邮件模板发生变化后，必须重新抽样验收。
官方来源
生意影响
询盘处理的损失不只是回复慢，还包括需求事实丢失、无法解释的优先级、无主任务和未审批承诺。统一工作台的价值是把每条询盘变成可追踪的责任链，让团队同时看到有效对话率、进入报价率、人工修改率和风险拦截数，而不是只统计 Agent 生成了多少封邮件。
询盘工作台记录
| 字段 | 必须内容 | 证据/状态 | 下一个负责人 |
| --- | --- | --- | --- |
| 买家与场景 | 公司、国家、用途、采购角色 | 原始询盘与公开信息 | 销售 |
| 需求与缺口 | 产品、数量、时间、规格、认证 | 已确认/待追问 | 产品/销售 |
| 风险与禁止承诺 | 价格、交期、合规、定制 | 绿/黄/红 | 审批人 |
| 下一步任务 | 问题、样品、会议、报价 | 截止时间与完成证据 | 明确到人 |
| 输出草稿 | 事实、待确认、下一步 | 人工审批后发送 | 销售 |
这张表是 Agent 的唯一上下文，不让模型从历史聊天中自由推断产品事实。任何新承诺必须回写字段、证据和审批人，不得只留在邮件草稿。
复盘问题
- Agent 节省的是整理时间，还是真正提高了合格询盘进入下一步的比例？
- 哪个待确认字段最常阻断报价，能否前置到表单？
- 邮件发出前，谁对价格、交期与合规承诺负最终责任？
你刚看完的是一篇真实交付，不是营销摘要。
QianX 年度会员继续解锁完整情报库、一页执行单、Agent 工作包与每周更新。
查看年度会员 · ¥333 / 年 →已经是会员？登录后继续阅读