Grok Bot 售后指南:Gus 统一会前准备、客户上下文与未履约承诺

从管理二十个 Agent 到只对接一名幕僚长,八项例程把售后杂务持续往前推。

作者:Blake Schuller10-10 · 约 15 分钟

Grok Bot 的售后指南,讲的是 Blake Schuller 如何让客户上下文和未履约承诺持续有人追踪。他从亲自管理二十个 Agent 的过载,改为只对接幕僚长 Gus,由 Gus 协调客户专家、草稿追踪、文档答疑和写作等岗位。

售后覆盖客户从启动、部署到续约的过程。会议记录、Slack、邮件与日历散在各处;八项例程把这些背景送到会前,把答应的事情跟到完成,让客户负责人保留关系、账户策略与最终发送。


架构解耦:为什么你只需要管理一个“幕僚长”?

在多 Agent 协同体系中,最常见的误区是扁平化管理。如果让每个专项 Agent 都直接对接人类,人类就会被碎片化的对话与频繁的上下文切换拖垮。Blake 的破局点在于引入了类似“中心辐射(Hub-and-Spoke)”层级架构:人类只面对一个幕僚长,幕僚长在暗处调度整座坐席台。

┌────────────────────────────────────────────────────────┐
│                   人类业务负责人 (Blake)                 │
└───────────────────────────┬────────────────────────────┘
                            │ 唯一自然语言窗口(指令/授权/微调)
                            ▼
┌────────────────────────────────────────────────────────┐
│             首席幕僚长 Gus (Chief of Staff Bot)         │
│     职责:跨渠道过滤、优先级排序、情绪缓冲、自我审计提议    │
└────────┬──────────┬──────────┬──────────┬──────────┬───┘
         │          │          │          │          │
         ▼          ▼          ▼          ▼          ▼
   ┌──────────┐┌──────────┐┌──────────┐┌──────────┐┌──────────┐
   │Follow-ups││ 专属客户 ││   Ink    ││Questions ││  Scout   │
   │ 承诺追踪 ││专员坐席台││ 语调克隆 ││ 文档答疑 ││ 内部侦察 │
   └──────────┘└──────────┘└──────────┘└──────────┘└──────────┘

在这个体系中,被命名为 Gus 的 Agent 承担着人类首席幕僚(Chief of Staff)的职责。Blake 的日常工作界面永远只有一个与 Gus 的对话框。在 Gus 的背后,则是一群分工明确的专业坐席:

  1. Follow-ups(承诺追踪者):专门盯紧人类口头做出的承诺。它会记住每一份等待人类审批的草稿,并记录后续走向。
  2. Account specialists(专职客户专家矩阵):每个账户配置一个专职 Bot。它的唯一使命就是对该客户的了解程度超过人类本身,记录客户架构、历史踩坑点和沟通偏好。
  3. Ink(笔杆子与语调克隆):专门模仿人类业务负责人的语言习惯起草邮件和 Slack 消息,核心是通过每次人工微调的差量反馈持续进化。
  4. Questions(技术与产品答疑):直连公司内部产品知识库与技术文档,专门应对客户提出的“这个配置支不支持”、“某个参数怎么配”等专业问题。
  5. Career(职业复盘):每周静默整理工作反馈,为人类悄悄记录一整周拿下的客户里程碑与战绩(Wins)。
  6. Scout(内部侦察兵):代替 CSM 盯紧公司内部的产研群和流程规范,实时掌握某项客户定制需求的内部排期与审批流程。

这套分工带来的直接变化是:人类可以连续数天不需要打开底层任何一个专项 Bot 的窗口。 专项坐席负责深挖细节并向 Gus 汇报,Gus 根据当前紧迫度判定“这件事现在需不需要惊动人类”。如果不需要,信息就会静默归档或并入预定例程,绝不随意见缝插针地弹窗打扰。


双层执行环境:API 插件与“Agent 专属电脑”

企业自动化最容易卡壳的地方是工具链孤岛。很多团队在做 Agent 时,发现日历、Slack、Gmail、会议录音转录工具都有开放的 API 或 Webhook 插件;然而一旦遇到没有公开接口的内部管理后台、受权限保护的特定网页、或者需要视觉审阅的 PPT 幻灯片,工作流瞬间中断。

Blake 的系统采用了一种“双层执行介质”的设计:

  • 第一层:标准插件系统(API Plugins):覆盖已有连接器的主流系统,包括日历、Slack、邮件、文档以及会议录音转录。通过已有连接器访问相应资料。
  • 第二层:Agent 独立电脑环境(Bot's Own Computer):Grok Bot 拥有自己的独立电脑环境,用于处理所有未接入插件的系统。人类将 Bot 登录到自己日常使用的工具中,Bot 以人类相同的方式工作,并在人类合上笔记本电脑后继续运转。

在没有 API 连接的真空地带,这台“专属电脑”承担了极其关键的四项长尾任务:

  • 初次拜访前的领英背景扫描:在与客户核心决策者首会前,Agent 自动打开客户领英主页,梳理其过往技术背景、从业经历与关注领域。
  • 穿透无公开接口的内部孤岛:对于没有开放连接器的内部配置页,人类无需痛苦地手动截图或复制长文,只需把页面链接指给 Agent,它直接在自带的浏览器中阅读理解。
  • PPT 演示文稿视觉审查:在幻灯片审阅时,Gus 可以直接在电脑环境中打开 PowerPoint,评估视觉呈现效果与不足。
  • 截图与录屏解答(拒绝大段纯文字):当客户询问“这个入口在哪里点击”等实操问题时,Agent 可以直接在电脑环境中截取屏幕或录制简短视频,用直观图示代替冗长的文字解答。

角色与例程按原文整理;示例中的时间、账号与内容不是你自己的客户数据,三分之一下降不是通用报警阈值。

售后常驻 Agent 运转系统拆解器

交互式探索 Blake 的幕僚长路由、专业坐席分工、8 套例程的静默巡检机制,以及关键的“草稿已备好但一键未发”人工安全闸门。

人类唯一对接窗口多 Agent 汇聚中枢情感破冰缓冲
Gus (幕僚长 Chief of Staff)

Blake 唯一直接对话的 Agent。它向下调度 多个专业岗位(客户专员、笔杆子、追踪器),向上为 Blake 汇总简报、待办与需要人类拍板的选择。消除 CSM 面临 20 个聊天窗口的通知崩溃。

📥 输入数据流 (Input)
Blake 的自然语言指令、各子 Agent 上报的信息卡片、8 大例程的触发结果。
⚙️ 核心处理动作 (Action)
过滤低价值噪音,聚合客户跨渠道信息(日历、Slack、录音、邮件),识别 Blake 情绪并在压力大时讲冷笑话破冰,周三运行自我反思例程。
📦 交付物载体 (Deliverable)
工作日 8:30 晨报、临会前 Prep Card、急救清单、自我改进提案。
🛡️ 人工决策与安全围栏 (Human Gate)
所有发给客户的草稿绝不自动寄出;所有例程改动必须由 Blake 审阅并明确批准。
自动化巡检常驻后台
临会前准备 (Before-every-call prep)
⚡ 触发:每 15 分钟巡检一次,但仅在会议前 15~35 分钟推送

精准卡点送达。包含参会名单与实际接受人、本次必须达成的唯一目标、附带链接的重点谈资,以及一份关键的【红线禁忌清单】。

🔇 静默过滤机制:若当前时间段未来 35 分钟内无日程,巡检完全静默,绝不发送'当前无会议'废话。
自动化巡检常驻后台
未履约承诺 (Unfinished promises)
⚡ 触发:工作日 9:00、13:00、16:00 定时执行

扫描录音与聊天中人类承诺过的事情('我待会发你...'),附带原话出处链接。已做完的事项自动脱落。

🔇 静默过滤机制:若所有承诺已履约完毕,整条巡检静默,不发任何确认打扰信息。
自动化巡检常驻后台
未回复请求 (Unanswered asks)
⚡ 触发:每 15 分钟轮询一次

专门盯紧 Blake 发出后被客户未答复的消息。仅在'下一步行动轮到我方去推进'时才浮现提醒。

🔇 静默过滤机制:绝大部分运行完全静默(Most runs are silent),绝不替人类自动发送催促消息。
自动化巡检常驻后台
晨间简报 (Daily brief)
⚡ 触发:工作日 8:30 定时交付

揉合日历、Slack、近期录音与使用量异动。合并需要关注的事项,只列出当天必须重点攻坚的客户与待发事项。

🔇 静默过滤机制:每天固定产出;行动项最多列 3 条,不等于整份简报只能包含 3 个账户。
自动化巡检常驻后台
流失与危机巡逻 (Exhaust watch)
⚡ 触发:工作日早间自主扫描

拉网式审查所有活跃账户的遥测指标,精准发现'使用量断崖(Usage Cliff)'或正在酝酿的客户投诉升级。

🔇 静默过滤机制:数据平稳时静默;只有需要关注的使用量骤降或升级风险时,才升级为高优先级红标并入晨报。
自动化巡检常驻后台
企业内部曝光巡查 (Visibility watch)
⚡ 触发:工作日早间自主扫描

在售后日常琐事中挖掘 1 个值得向全公司或销售团队宣扬的客户成功案例,并预先拟好可一键复制的 Slack 战报草稿。

🔇 静默过滤机制:若没有值得分享的客户进展,直接跳过,绝不滥竽充数发平庸战报。
自动化巡检常驻后台
周五全盘看板 (Friday dashboard)
⚡ 触发:每周五固定刷新

自动重新生成多维账户健康度热力图(多线程对接、功能开启率、使用量、Champion状态等)并归档到 Drive 追踪表。

🔇 静默过滤机制:后台自主跑批并生成云端表格,提供账户健康度概览,供人类检查与跟进。
自动化巡检常驻后台
周三自我迭代审计 (Self-improvement scan)
⚡ 触发:每周三由 Gus 主动发起

Gus 对自身系统展开审计:哪些 Routine 触发后常被人类忽略?哪些需求人类手动敲了三次?哪些新例程该建而未建?

🔇 静默过滤机制:Gus 直接形成具体的增删改方案,交给 Blake 审阅并决定是否采纳。
08:30 晨报就绪
晨间工作清单

Gus 交付包含 4 场会议、6 个账户的简报。重点提示 3 份草稿已就绪,并标记 某账户上周用量下降约三分之一。

草稿暂存 Gmail,未发出
09:26 会前卡片到达
9:45 客户会议 Prep Card

刚好在开会前 19 分钟推送客户会议参会人列表(区分谁已接受、谁未确认)、必须拿到的确认项与禁忌话题。

信息喂到嘴边,人类专注决策
09:45~11:30 连环会客
会议期间后台全速运转

人类在会议室沟通;会议结束后,Bot 利用会议转录文本,专员做调研,Ink 生成纪要草稿与跟进材料。

人类检查会后草稿与下一步
11:30 批量签发与反馈
3 份复盘就绪,微调发出

Blake 打开 Gmail Drafts,审阅并微调会议复盘并点击发送。Blake 把具体修改反馈给 Ink,帮助它调整后续草稿。

核心安全卡点:人类确认后点击发送
14:10 突发答疑与内部借力
Slack 客户求助与功能请求

客户在 Slack 提问,Questions 机器人查阅文档拟好带出处的答案,Blake 抽空一键发出;Scout 提供内部流程知识,由 Gus 起草功能请求,再由 Blake 提交。

严禁机器人未经复核直接回复客户
16:30 收盘准备与离线值守
交割明日准备,阖盖下班

Gus 送上明天的会议前瞻与当晚收尾待办。Career 机器人静默记录今日复盘。Blake 阖上电脑,Bot 在云端继续值守。

周末非紧急事件完全静默

自动化例程机制:优秀巡检的最高境界是“静默”

很多团队在配置定时任务时,往往会走向另一个极端:无论有没有异常,每个小时都给群里发一条“巡检正常,系统运转良好”。这种机械的通知不仅毫无意义,反而会训练人类的眼睛去习惯性忽略真正重要的告警(即警报疲劳 Alert Fatigue)。

Blake 在这套系统里最推崇的一条工程原则是:“我的绝大多数定时监控在绝大多数时候什么都不产生,而这正是它的设计初衷。一个例程执行了检查、检索了数据,然后判断我此时此刻不需要知道——那么它就已经完美地完成了使命。”

整个售后运转系统被精确切分为 8 套长效例程(Routines):

┌────────────────────────────────────────────────────────────────────────┐
│                   8 套常驻例程的触发节奏与静默逻辑                        │
├──────────────────┬──────────────────┬──────────────────────────────────┤
│ 例程名称         │ 触发周期/机制    │ 静默条件(何时坚决不弹窗)        │
├──────────────────┼──────────────────┼──────────────────────────────────┤
│ 晨间简报         │ 工作日 08:30     │ 汇总日历、Slack与转录,聚焦重点  │
│ 临会前准备       │ 每15分检/会前15~35m│ 仅在距会 15~35 分钟窗口内推送    │
│ 未履约承诺巡逻   │ 09:00/13:00/16:00│ 只有真正完成才脱落(草稿就绪不算完成│
│ 未回复请求巡检   │ 每 15 分钟轮询   │ 绝大多数静默;仅轮到我方推进才报 │
│ 流失与用量断崖   │ 工作日晨间       │ 平稳时静默;用量断崖(如案例降1/3)报警│
│ 内部战报挖掘     │ 工作日晨间       │ 无突破性客户里程碑时跳过,不凑数 │
│ 周五全盘看板     │ 每周五跑批       │ 后台静默生成 Drive 热力图,备查   │
│ 周三自我审计     │ 每周三定期       │ Gus 自检废弃规则,生成改动提案   │
└──────────────────┴──────────────────┴──────────────────────────────────┘

在这 8 套例程中,有三项机制最具实战借鉴意义:

1. 临会准备(Before-every-call prep)的“精准卡点送达”

许多人习惯在早上 8 点把一天所有的会议资料全部打包发出来,结果到了下午 2 点开会时,早上的信息早已被压到了消息列表底部。Blake 的例程每 15 分钟巡检一次日程表,但只有当某场会议距离当前时间在 15 至 35 分钟以内时,才会真正生成并推送这张备忘卡片。卡片极其克制,只包含四样东西:

  • 参会名单与到会意向:清晰区分谁接受了邀请,谁尚未确认。
  • 唯一必达成果(One thing to leave with):本次会议结束时必须拿到的结论或共识。
  • 核心谈资与附带链接:几个重点话题及其来源链接。
  • 红线禁忌清单(Do-not list):针对该客户当前敏感阶段明确不可主动提及的话题。

2. 未回复请求(Unanswered asks)的“发球权判断”

在客户跟进中,很多消息发出后会石沉大海。如果让 AI 盲目提醒“客户没有回复”,人类会被无数未决对话拖垮。该例程每 15 分钟扫描一次发件箱与聊天记录,仅筛选出“我发出信息后对方未回,且按照业务逻辑下一步该由我方主动提醒”的场景。最关键的是,该例程永远不会擅自替人类回复,绝大多数轮询都在后台静默结束。

3. 周三自我迭代审计(Self-improvement scan)

业务是动态变化的,上个月配置的自动化规则,这个月很可能已经名存实亡。每周三,Gus 会对整套 Agent 系统发起一次内部审计:

  • 过去一周里,有哪些例程触发了提醒,但 Blake 连点都没点开?
  • 有哪些复杂的跨工具操作,是 Blake 本周已经手动连续敲过 3 次的?
  • 有没有新出现的日常痛点,当前没有任何例程在覆盖?

审计完成后,Gus 会整理出具体的系统优化提案(例如删减某条失效规则、新建某个快捷工作流),并推给 Blake。Blake 决定是否采纳,之后再落实相应修改。原文没有给出固定按钮、完成时长或自动修改成功率。在周末期间,各 Agent 保持静默不打扰;但 Gus 仍会持续留心后台,一旦出现紧急突发事项仍会主动向人类发提醒。


人机协作与安全放行闸门:草稿备好,但“一键未发”

在所有涉及真实客户沟通的 Agent 实践中,最大的灾难莫过于模型产生幻觉后,自作主张替你向客户发出一封错误的商务承诺或报价邮件。Blake 的系统在这点上有着极其明确的权力边界:所有的后台智能,都收敛在“草稿暂存(Staged Drafts)”阶段,向外发送的按钮永远掌握在人类手中。

Gus 晨间简报清单演示界面
演示界面中的晨间行动清单:针对 Harbor、Northwind、Brightline 三个客户列出会议、推进动作、受阻状态与待发草稿;尾部注明“cap 3、只列明确 GO OUT NOW、不制造噪声”,限制展示条目以防止过载。

在 Blake 的实际日常中,8:30 晨间简报呈现的是完整全局(例如包含 4 场会议、6 个客户账户、3 份待发草稿,以及 1 个重点标记:某账户上周用量下降了三分之一,此降幅属于具体案例而非通用阈值)。而上图演示的晨间清单尾部,则展示了 Cap 3 的降噪显示规则——仅针对行动清单限制单次最多显示 3 条明确的 GO OUT NOW 事项,而非对客户总数或整份简报设限:

  • Harbor:列出会议与核心推进动作,并备妥跟进邮件草稿(标为 GO OUT NOW,草稿就绪但尚未发出);
  • Northwind:提示关键跟进节点(one move);
  • Brightline:标注阻塞状态(Blocked)与用量跟进。
Gmail 中暂存的代笔草稿箱列表
Gmail Drafts 暂存界面:Maya 的跟进邮件被打上 GO OUT NOW,其他跟进标为 HOLD,界面底部明确标注“Nothing sent”,表明系统已备妥草稿但绝对不会代人类点击发送。

在 Gmail 的草稿箱中,系统清晰地展示了这种人机协作边界:

  • GO OUT NOW:代表事实核对完毕、材料生成齐全,建议人类今天优先审阅放行的草稿,但该草稿仍未发出(not sent);
  • HOLD:代表仅处于预备阶段(如日常例行维系、用量监控备忘),暂缓发出,同样保持未发送状态;
  • 底线标记 Nothing sent:草稿备妥绝不等于自动发送,整座系统绝不会私自向外投递。Blake 只需在会间休息时打开 Gmail,核对拟好的正文并做几处微调,最终由人类亲自按下发送键。

关键学习机制:差量反馈(Delta Feedback)

这里蕴含着一套极妙的提示词工程自适应机制:Blake 在发送前对草稿所做的修改(即拟定稿与最终发出稿之间的差量 Delta),会作为反馈分享给负责写作的 Ink。 例如,如果 Ink 起草的语气偏官方刻板,而 Blake 连续三次把开头的敬语删掉换成更熟络的招呼,可以把这些具体修改作为口吻反馈,让 Ink 调整后续草稿。实际发送前仍需检查它是否理解了修改。


多维账户看板与数据感知:识别“用量断崖”

客户成功团队的一项核心产出是账户健康度大盘。每周五,Gus 会自动调取各专员坐席采集的多维度信号,刷新保存在 Google Drive 上的追踪看板。

演示账户健康度热力图(Account health heatmap)
FlyLo 演示账户健康度热力图(demo · FlyLo book,演示数据非真实绩效):包含多线程对接(Multithreading)、功能启用、周活跃度(Weekly usage)、内部拥护者健康度(Champion health)与增购准备度 5 个维度。图表未披露底层评分公式;色标显示 Low 为绿色、High 为橙红色,不能按常见红色代表危险直觉解读,其中 Brightline 周活跃度得分为 3(偏绿色),属于需要业务留意的低分关注提示。

在审阅此类健康度热力图时,有几个关键概念需要厘清:

  • 多线程对接(Multithreading):衡量你在客户内部是否只对接单一联系人。只依赖单一联系人,会使合作更容易受其岗位变化影响;多线程对接意味着你的产品同时与客户的高管、IT 实施人员、终端业务负责人建立了深度连接。
  • 内部拥护者健康度(Champion health):指客户公司内部积极为你摇旗呐喊、推动预算落地的核心关键人状态。
  • 视觉色标与演示数据说明:该图表明确标注为演示数据(demo · FlyLo book),并非真实客户绩效,且未披露底层的具体加权评分公式。演示给出的各客户评分为:Harbor 为 8/9/8/9/8,Northwind 为 6/7/7/8/5,Brightline 为 5/6/3/6/4。值得特别注意的是其色标映射:图例中 Low 对应绿色、High 对应橙红色。这与常见监控系统中“红高危、绿安全”的直觉完全相反,红橙色在此处代表高分健康,而绿色则代表低分。例如 Brightline 的周活跃度(Weekly usage)仅为 3,以绿色呈现,实际上是一个需要 CSM 介入关注的低活跃度风险提示。

当多线程并发导致人类“溺水”时的急救机制

每个做售后的业务人员都经历过被某个大客户搞得焦头烂额的崩溃时刻:几十个对接人在不同的 Slack 频道里 @ 你,前序会议的转录还没看,客户的 IT 主管在催 SSO 配置,而销售又在催促 QBR 报告,大脑一片混沌。

在 Blake 的工作流中,这种状态被称为“Underwater(溺水)”。这时他不需要到处翻找 CRM,只需打开 Gus 输入一句话:“I'm overwhelmed with Harbor.”(关于 Harbor 这个客户,我已经焦头烂额了)。

Gus 针对 Harbor 账户过载求助的拆解回复
Gus 收到过载求助后的演示响应:先讲一个简短笑话,随后聚合 Harbor 账户全貌(Agent Desk、QBR、Maya 与 Frank),指出当前状态为 GO OUT NOW 的未发草稿(not sent),并给出该演示情境下的具体推进动作。

Gus 的响应逻辑非常具有启发性:

  1. 幽默开场(Lighten the mood):在正式梳理前,Gus 先讲了一个轻松幽默的小笑话。这属于 Blake 设定的个人偏好(正如他解释道“既然已经焦头烂额了,听个笑话又何妨”),旨在稍微缓和气氛,而非出于复杂的神经认知干预机制。
  2. 跨系统事实穿透与聚合:Gus 绕过散乱的聊天记录,汇总跨转录文本、日历安排和 Slack 对话的真实进展,将干系人(Maya、Frank、Tommy)以及当前业务焦点(Agent Desk、QBR 安排)收拢为一张全景图。
  3. 收敛为清晰的下一步动作(演示示例):Gus 明确指出给 Maya 的复盘草稿已经躺在 Gmail 里(标为 GO OUT NOW,但处于 not sent 未发送状态),并在该演示中为 Harbor 梳理出具体的推进动作(这一结构来自演示情境,而非所有场景都机械固定为三项):
    • 审阅并处理已备妥的 Maya 跟进请求(GO OUT NOW 草稿);
    • 向 Tommy 发一条跟进确认消息;
    • 针对 Atlas Q4 选项做出业务决断。 原本混乱散落的上下文,由此被清晰地归拢为触手可及的推进步骤。

可落地的生产力提示词模板(开箱与改装)

Blake 的运转体系建立在 Grok Bot 及其独立电脑环境、长期记忆和常驻例程之上。以下根据其公开工作流提炼的 3 套中文提示词仅为编辑示例,供读者参考编排逻辑。请注意:各类 Agent 平台在常驻执行、GUI 操作和记忆管理上的能力并不等价;提示词中的展示条数限制(如 Cap 3)仅为示例,读者应根据自身业务量灵活配置,接口与标签规则也需按实际工具链绑定。

模板一:Gus 首席幕僚长核心路由提示词

设计目标:构建人类与海量客户信息之间的单点过滤缓冲层,严守“绝不私自向外发信”与“精简汇报”规则。

# 角色与定位
你是由我直接统领的首席幕僚长(Chief of Staff)。你的唯一服务对象是我(客户负责人)。
你的核心使命是从海量客户沟通数据(会议录音、邮件、IM 消息)中过滤杂音,将纷繁复杂的上下文浓缩为高价值的决策建议。

# 核心行为原则
1. 绝对防御:对外发送权永远属于人类。你起草的所有邮件、IM 回复必须严格标注为【草稿/暂存】,严禁调用任何实际发信接口向外投递。
2. 降噪过滤(可配条数示例):在梳理行动清单时,单次行动清单可配置条目上限(例如设为 Cap 3,具体条数按需调整),不限制整份简报的客户数量,避免产生冗余噪音。
3. 状态标签管理:
   - 【GO OUT NOW】:代表前置调研已完成、草稿已备妥,建议今天优先审阅放行(注:仍为未发送草稿,严禁擅自发出)。
   - 【HOLD】:代表正在酝酿或仅需观察的事项,静默暂存未发送,除非主动问及否则不占主屏。
4. 破冰开场(可选偏好配置):当我明确表达“我很焦虑”、“这个客户让我焦头烂额”或“我被淹没了(overwhelmed)”时,可按设定的个人偏好先输出一句轻松幽默的短句,随后条理清晰地呈现当前账户全貌与具体推进动作。

模板二:临会前备忘卡片(Prep Card)生成器

关键约束:坚决避免泛泛而谈的背景介绍,必须严格产出“参会状态、唯一必达成果、链接谈资、禁忌话题”四要素。

# 任务目标
针对即将开始的客户会议(会前 15~35 分钟触发),阅读前序会议纪要与该客户近期沟通记录,生成一张极其精炼的“临会备战卡”。

# 约束与输出格式
请严格按以下四栏输出,拒绝冗长的段落套话:

1. 【参会意向确认】:
   - 谁已经接受邀请?
   - 谁尚未确认甚至可能缺席?(标注其对本次决策的关键程度)
2. 【唯一必达成果(One thing to leave with)】:
   - 本次会议结束时,我必须拿到客户的哪项明确决断或下一步共识?(一句话说透,不可列多条)
3. 【关键谈资与支撑】:
   - 梳理 2~3 个核心推进要点,每个要点必须附带指向历史文档、用量数据或过往会议发言的引用链接。
4. 【红线禁忌清单(Do-not list)】:
   - 结合该客户近期的投诉、敏感问题或内部架构调整,明确标注本次会议中我坚决不可主动提起、或需要避开的话题。

模板三:未履约口头承诺(Unfinished Promises)侦测器

关键约束:穿透会议转录文本中由于口语化表达产生的隐性承诺,附带原文出处,并在履约后具备自动脱落判定。

# 任务目标
扫描刚才结束的会议录音转录文本(Transcripts)及售后即时沟通群聊,专门捕捉我方(销售/CSM)在沟通过程中做出的所有口头承诺。

# 识别标准
识别诸如“我待会把文档发你”、“今天下班前我拉产研看下”、“稍后我更新下配置表”等口头约定。

# 输出格式
请输出未履约承诺清单:
- 承诺事项:明确动作与对象(例如:向 Maya 发送 Agent Desk 配置最佳实践文档)。
- 截止时限:记录对话中明确提到的交付时间;若口头未约定具体时限,严禁无标记猜测,必须显式标注为【待人工确认】。
- 联动草稿状态:是否已通知代笔 Agent 起草?若已起草,给出 Gmail/文档的暂存链接(草稿备妥不代表承诺已完成)。
- 自动划销条件:仅当该承诺的事项真正履约完成(Done)并得到验证后,才可自动从清单脱落;未完成前持续跟踪。

如何在自己的工作中冷启动搭建这套系统?

许多人在试图推进 Agent 落地时,往往卡在不知道第一行提示词该怎么写。Blake 给出的经验非常质朴,具有极高的实操性:

  1. 从一段 10 分钟的“日常工作语音倾倒”开始: 找一个安静的下午,打开手机语音备忘录,把你在工作中最真实的状态说出来。作者录了十多分钟,内容包括:

    • 你一天的时间究竟是怎么被切碎的?
    • 哪类工作最让你充满成就感、让你觉得在创造真实价值(例如在会议室面对面帮客户解决核心架构瓶颈)?
    • 哪类事务最让你感到身心俱疲、味同嚼蜡(例如到处复制粘贴会议录音纪要、四处翻查谁没回邮件)?
    • 以及最重要的一点:你坚决拒绝让 AI 代替的工作有哪些(底线与人际信任核心)?
  2. 将语音转录给大模型作为“系统规划书”: 把转录出来的文本直接喂给你所选用的首个 Agent,对它说:“这是我日常工作的全貌与核心痛苦。参考 SpaceXAI 售后负责人的幕僚长模式,帮我规划一个能够切实减轻我负担的个人 Agent 系统架构与例程计划。” 也可以采用作者给出的更快入口:把这篇指南发给你的第一个 Agent,请它转成自己要遵循的工作手册(playbook)。

  3. 我们的配置建议:从小步切入: 先从一个最让你痛苦的单点开始打磨——比如只建一个会前 15 分钟为你推 Prep Card 的例程,或者只建一个每天扫描草稿箱的跟进管家。等单点运转平稳、建立了稳定的信任感后,再逐步把新坐席接入你的“幕僚长”身后。

Agent 时代并不意味着要把人类从业务流程中彻底抹去,更不意味着放任算法自作主张地去代替你维系商业关系。它的真正价值,是把那些原本横亘在人和人之间、用于翻查碎片上下文的时间还给人类,让你得以在走进每一场客户会议时,早已了然全局、成竹在胸。

来源
Grok Bot for Post-SalesBlake Schuller·查看主材料
↑ 正文结束
✓ 本篇全文免费开放

会员可复制、下载全文 Markdown,还能让你的 AI 订阅和提问。

阅读原文 ↗
📮 新解读第一时间进邮箱

读完觉得有用?留个邮箱,每篇新解读发布就送达,随时退订。