销售团队真正稀缺的资源不是数据，而是销售人员的时间。Amazon Quick 所描绘的 agentic AI 队友，重点不只是生成邮件，而是贯穿销售周期：找出优先级最高的潜在客户、准备触达内容、推进交易、协助成交，并在客户关系成熟过程中持续更新 CRM。
这种工作方式的价值在于把多个孤立动作组织成一条可执行链路。不过，企业要把这一思路落地，仍需明确数据来源、审批边界和写回规则，避免让自动化变成新的数据风险。
把销售周期拆成可执行任务
一个端到端的销售智能体可以围绕四类任务工作：
- 机会识别：结合客户规模、意向信号、最近互动和预计合同价值，为线索排序。
- 客户触达：读取账户背景与历史沟通，起草针对性的邮件、会议议程或跟进信息。
- 交易推进：汇总异议、待办事项和关键决策人，提示下一步动作与时间窗口。
- CRM 维护：将会议结论、交易阶段、下一次行动和负责人写回业务系统。
这里的关键不是一次生成多少文本，而是每一步都产生结构化结果。例如，会议总结至少应拆出 summary、next_action、owner、due_date 和 crm_fields，这样才能进入后续审批与系统写回流程。
对于高风险动作，应保留人工确认。例如，智能体可以起草报价邮件，但折扣、合同承诺和最终发送动作仍由销售负责人批准。低风险的会议摘要和待办提取，则可以在校验后自动写入 CRM。
先解决优先级，而不是批量生成邮件
如果销售每天面对数百条线索，最有价值的起点通常是回答一个问题：今天应该先联系谁？
可以将评分过程分为三层：
- 确定性规则：地区是否覆盖、行业是否匹配、客户规模是否达到门槛。
- 行为信号：是否请求演示、近期访问频率、邮件回复和会议参与情况。
- 业务上下文：预计合同价值、销售阶段停留时间、续约或扩展机会。
分数并不等同于事实。模型给出的优先级需要附带原因和证据时间，销售人员才能判断信号是否过期。例如，“过去 7 天请求演示”比“六个月前下载过白皮书”更值得进入当天任务列表。
可以这样实践：构建一个最小线索排序器
下面的示例不代表 Amazon Quick 的官方 API，而是一个可直接运行的、供应商无关的最小原型。它读取 JSON 线索，按照业务信号计算优先级，并生成可交给智能体或 CRM 适配器处理的任务对象。
将以下代码保存为 prioritize_leads.py，使用 Python 3.10 或更高版本运行，无需安装第三方依赖：
from __future__ import annotations
import json
from datetime import datetime, timezone
LEADS = [
{
"id": "lead-101",
"company": "Northwind Labs",
"fit_score": 82,
"intent_score": 91,
"estimated_value": 120000,
"days_since_contact": 2,
"requested_demo": True,
},
{
"id": "lead-102",
"company": "Contoso Retail",
"fit_score": 95,
"intent_score": 48,
"estimated_value": 80000,
"days_since_contact": 21,
"requested_demo": False,
},
{
"id": "lead-103",
"company": "Fabrikam Health",
"fit_score": 75,
"intent_score": 76,
"estimated_value": 200000,
"days_since_contact": 8,
"requested_demo": True,
},
]
def priority_score(lead: dict) -> float:
value_score = min(lead["estimated_value"] / 2000, 100)
freshness_score = max(0, 100 - lead["days_since_contact"] * 4)
demo_bonus = 15 if lead["requested_demo"] else 0
return round(
lead["fit_score"] * 0.30
+ lead["intent_score"] * 0.35
+ value_score * 0.20
+ freshness_score * 0.15
+ demo_bonus,
1,
)
def build_task(lead: dict) -> dict:
reasons = [
f"fit={lead['fit_score']}",
f"intent={lead['intent_score']}",
f"estimated_value={lead['estimated_value']}",
]
if lead["requested_demo"]:
reasons.append("demo_requested")
return {
"task_type": "review_and_contact",
"lead_id": lead["id"],
"company": lead["company"],
"priority": priority_score(lead),
"reasons": reasons,
"requires_human_approval": True,
"created_at": datetime.now(timezone.utc).isoformat(),
}
tasks = sorted(
(build_task(lead) for lead in LEADS),
key=lambda item: item["priority"],
reverse=True,
)
print(json.dumps(tasks, indent=2, ensure_ascii=False))
运行：
python prioritize_leads.py
接入真实环境时，应将示例中的 LEADS 替换为经过授权的数据查询，并将权重放入可审计的配置，而不是硬编码在脚本里。还要记录输入信号、评分版本和执行时间，便于销售运营团队解释为什么某条线索被排在前面。
让智能体输出可校验的 CRM 更新
自由文本摘要适合阅读，却不适合直接写回 CRM。可以要求智能体只生成约定字段，并让服务端完成字段白名单、类型和权限校验。下面是一个可改造的任务输入示例，同样属于实践建议，不是 Amazon Quick 的官方请求格式：
{
"account_id": "acct-2048",
"task": "summarize_meeting_and_propose_crm_update",
"meeting_notes": "Customer wants a security review next week. Maya owns the review. Budget approval is expected by 2025-05-30.",
"allowed_fields": [
"meeting_summary",
"next_action",
"next_action_owner",
"next_action_due_date",
"deal_stage"
],
"constraints": {
"do_not_invent_missing_values": true,
"require_approval_for_deal_stage_change": true
}
}
写回服务至少需要执行四项检查：账户是否匹配、字段是否在白名单内、日期与枚举是否合法、当前操作者是否有更新权限。对于交易阶段、金额、折扣和合同条款等敏感字段，应采用“建议变更”而不是“直接变更”。
落地时关注边界与可观测性
引入销售智能体时，可以从一个窄场景开始，例如每日线索排序或会后待办提取。验证节省的时间、建议采纳率和 CRM 字段准确率后，再连接邮件发送或交易阶段更新等高影响动作。
上线前建议检查：
- 每个结论是否能追溯到具体 CRM 字段、会议记录或行为信号。
- 是否对外发消息、报价、折扣和阶段变更设置人工审批。
- 是否限制智能体只能读取和修改当前用户有权访问的账户。
- 是否记录提示词版本、输入摘要、工具调用、审批人与最终写入结果。
- 是否处理重复任务、接口重试和部分写入，避免 CRM 出现冲突记录。
- 是否定期评估排序结果对地区、行业和客户规模的系统性偏差。
Amazon Quick 展示的方向，是让 agentic AI 从单点内容生成走向销售流程协作。真正决定成效的并不是自动化步骤越多越好，而是能否把销售判断、结构化数据、人工授权和系统写回组织成一条可追踪、可暂停、可纠正的链路。