代理业主
代理机构所有者的会议生命周期:从准备到跟进每周 15 个电话
每周 15 个客户电话只有在每个电话都以正确的背景开始并以跟踪的每一项承诺结束时才会有回报——会议本身是最容易的部分。
操作员
一家机构所有者与一个五人团队管理着八个活跃客户帐户,其日历看起来像机场出发板。每周 15 个或更多电话——状态审查、创意简报、季度计划会议、新业务对话——每个电话都需要不同类型和深度的准备。团队交付工作;几乎每次与客户打交道时,业主都会参与其中,他的工作就是了解历史、维持关系并在房间里做出决定。
该团队混合使用 Gmail、Slack 和共享 Google Drive 文件夹来进行客户通信和可交付成果管理。每天有五个人在这八种关系中产生线索、决策和承诺。所有者并不在每个线程上。他们接听每一个电话。这两个事实之间的差距就是出问题的地方。
突破点
毫无准备地接到客户电话并不是一个抽象的风险;这是每周都会发生的事情。并非完全没有准备——业主知道客户是谁、项目是什么、事情大致处于什么阶段。但真正重要的具体准备类型——知道两周前决定了什么,知道客户将询问哪个未解决的项目,知道有一个团队成员在前五分钟内交付的成果已经逾期三天——这需要很少发生的准备会议。每周十五次电话并没有为十五次准备会议留下空间。
后续问题是准备问题的镜像。通话结束后,业主心里会列出已决定的内容和承诺的内容。该清单立即开始消失。业主经常在有机会写下任何内容之前就进入下一个通话。到一天结束时,先前调用的两到三个承诺在任何系统中都没有踪迹。该团队不知道它们的存在。客户记得他们;该机构没有。
结果是会议生命周期有两个断端:准备端,业主带着不完整的图片到达;以及后续端,在房间里做出的承诺永远不会出现在任务板上或客户回顾中。中间部分——实际的对话——很好。它周围的基础设施不是。
设置
代理机构所有者将其 Gmail 和其团队用于客户安排的共享 Google 日历连接起来。他们连接 Google Drive,团队在那里保存客户简介、创意资产和状态文档。八个客户中的每一个都在 Lodestar 中拥有自己的组织,每个组织内部的项目都映射到积极的参与:这里是品牌更新项目,那里是付费媒体保留者,其他地方建立网站。
五名团队成员被添加到相关组织和项目中,以便他们的电子邮件线程和操作项目流入共享图片中。机构所有者现在可以了解他们的团队在他们从未参与过的线程中所做的承诺 - 由 Lodestar 提取,链接到源引用,并显示在项目视图中。他们不会阅读每封电子邮件;他们看到从所有人身上提取的信号。
工作流程
会议生命周期分为两个阶段。准备阶段发生在通话之前——最好是在通话前几分钟,这是所有可用的时间。后续阶段紧随其后发生。两者均通过 Lodestar MCP 与 Claude 对话来处理,无需打开任何其他应用程序。
- ·之前——业主要求克劳德为下一次通话做好准备,并指定了客户的名字。 Claude 调用“calendar_retrieve”来确认会议详细信息和与会者,然后调用“emails_content”来确认过去两周与这些与会者的对话。
- ·之前 — Claude 调用“knowledge_search”来显示相关的 Drive 文档:当前的项目简介、最后的状态报告、任何未完成的提案。它调用“contacts_retrieve”和“knowledge_org_charts”来确认谁在房间里——包括最近线程中出现的任何新的利益相关者。
- ·之前 — Claude 调用“action_items_list”,其范围是打开该客户项目上的项目,标记任何逾期或由所有者个人承诺的项目。准备简报回来了:会议议程背景、最后的决定、可能出现的未决项目、出席人员以及他们最近的沟通语气。
- ·之前——业主阅读简报。这是一页。他们在接到电话时确切地知道客户可能会提出什么,团队还欠他们什么,以及上次见面时决定了什么。
- ·之后 - 所有者将通话中的笔记输入到同一个 Claude 对话中 - 做出的决定、提交的可交付成果、谁拥有什么、提到的任何日期。克劳德从原始笔记中提取结构化的行动项目。
- ·之后 — Claude 为每个承诺调用“action_items_create”,将每个承诺分配给 Lodestar 中的正确项目。如果团队成员被指定为所有者,则该项目将分配给他们。如果规定了截止日期,那么它就被设定了。如果任何里程碑受到调用决策的影响,Claude 会调用“milestones_partial_update”。
- ·之后 — Claude 调用“timeline_events_create”根据客户的项目时间表记录会议本身。然后,它调用“emails_reply_link”为客户起草通话后回顾:对已决定的内容和下一步的内容进行清晰的总结,以供所有者查看和发送。
- ·之后 - 所有者阅读摘要草稿,进行任何调整,然后单击“发送”。循环是封闭的:客户有书面记录,团队在 Lodestar 中分配任务,项目时间表反映了会议情况。
有什么变化
准备问题在以前实际上无法解决的时刻得到了解决——在电话会议前几分钟,在繁忙的日历上。业主不再需要为每次会议准备专用的准备模块,因为简报是根据 Lodestar 中的实时数据自行组装的。这并不是一次完美的深入研究;它是可靠准确的一页,涵盖了客户通话的前十分钟内实际出现的情况。
承诺不再消失。业主的通话后笔记无论多么简短,都会在通话结束后几分钟内变成结构化的行动项目。团队成员可以在 Lodestar 中查看他们的分配,无需所有者发送 Slack 消息。客户会收到一封重述电子邮件,该电子邮件是根据真实的对话记录起草的,而不是根据逐渐消失的记忆重建的。
团队共享的客户状态图保持最新。由于操作项是从线程和呼叫中提取的,因此在所有者不在的电子邮件线程中生成承诺的团队成员在客户的项目中仍然可见。所有者可以在任何通话之前查看每次参与的完整状态,而无需要求团队向他们通报情况。
带来的变化
- ·每次会议都以一页的摘要开始,该摘要由真实的线程历史记录、未解决的项目和组织结构图上下文构建而成,只需几秒钟即可组装,而不是从内存中重建。
- ·通话后承诺是从原始笔记中捕获的,并在所有者下一次通话开始之前转化为分配的、可跟踪的行动项目。
- ·客户回顾电子邮件是根据实际会议记录起草的,无需单独的撰写步骤即可发送。
- ·在所有者不在的线程中做出的团队承诺在客户项目中仍然可见 - 共享图片是完整的,不限于所有者自己的收件箱。
- ·会议生命周期——准备、决策、跟进、回顾——是一个闭环,而不是一个有两端的过程。