部分首席运营官

一位首席运营官如何让 12 名客户在不失败的情况下继续前进

从一个收件箱运行十几个客户关系是一个上下文管理问题,解决这个问题的唯一方法是停止依赖内存。

这是 Lodestar 构建的工作流程的说明性演练,而不是指定的客户故事。 Lodestar 是预发行产品。这里没有提供真实的公司名称、报价或测量结果。
12客户3收件箱18每周会议

操作员

一位负责管理 12 个活跃客户关系的首席运营官每月的工作时间在 150 到 500 小时之间,涉及电子商务运营、SaaS 规模扩张和专业服务公司等业务。每个客户都有自己的组织结构图、自己的项目节奏、自己的利益相关者群体以及自己的怪癖。部分首席运营官不是他们中任何一个的雇员——这意味着除了这个人自己头脑中的东西之外,没有任何机构记忆将任何东西结合在一起。

负载如下所示:三个收件箱(个人域、添加到的一个客户的 Microsoft 365 租赁以及共享操作别名)、每周 18 个常设呼叫、从这些呼叫中提取的一组循环操作项目,以及持续存在的后台恐惧,担心他们四天内没有查看过的帐户中的某些内容正在冷却。这项工作本身就是高价值的咨询。重建背景、追踪后续行动、发现关系偏差等开销则不然。

突破点

感觉到的问题很少会干净地显现出来。它在周二早上表现为一种模糊的感觉,即某个特定帐户出了问题——一个线程安静下来,一个可交付成果停止获取更新,一个冠军联系人的回复变得更短。当部分首席运营官在脑海中打开该帐户的文件夹并试图将过去几周的时间拉回来时,二十分钟已经过去了,他们仍然不确定自己错过了什么。

具体的恐惧是更新。由于十二个客户签订了滚动季度或年度合同,因此在保留周期的某个阶段总是有两到三种关系。一个在三周内没有被注意到的冷静账户并不感觉像是日常的疏忽——而是感觉很忙碌。回想起来,当客户选择不续订并说出电子邮件中一直清晰可见的原因时,这看起来像是疏忽。

更广泛的问题是上下文存在于六个不同的地方。 Gmail 有线程。 Google Drive 有 SOW 和状态平台。 Google 日历有会议历史记录。部分首席运营官的心理模型包含组织结构图、政治动态和先前的决策。这些都不互相交谈。当出现问题时,将它们整合在一起是手动的、缓慢的且不精确的——并且它发生在问题已经可见之后,而不是之前。

设置

部分 COO 将他们的个人 Gmail 帐户和他们与一位客户共享的 Microsoft 365 收件箱连接起来。它们连接 Google Drive 和 OneDrive,以便 Lodestar 可以提取 SOW、项目简介、状态表和共享工作文档。每个客户在 Lodestar 内都有自己的组织,每个积极的参与都会在其下获得一个项目 - 与他们已经对工作的看法保持一致,而不是与不熟悉的 CRM 分类法保持一致。

在摄取后的几个小时内,Lodestar 从最近的线程和会议回顾中提取了行动项目,显示了与他们互动最多的联系人的每个联系人的情绪趋势,并从线程中的电子邮件签名和抄送模式中组装了组织结构图草图。没有手动输入任何新内容。只存在于部分首席运营官头脑中的操作图现在具有可以查询的结构化并行图。

工作流程

工作流程遵循感知→决策→行动→闭环。早上通过 Lodestar MCP 服务器向 Claude 提出一个问题开始。从那里开始,会话无需切换应用程序即可运行。

  • ·Sense - Claude 调用“dashboard_needs_attention”和“dashboard_sentiment”来显示需要查看的内容。该回复指出,一个账户在过去两周内的情绪下降了 -0.3,并且有两个线程被标记为紧张。部分 COO 本身并未将任何一个线程注册为重要线程。
  • ·Sense — Claude 在这些线程上调用“emails_list”和“emails_content”,然后调用相关组织的“knowledge_org_charts”和“contacts_retrieve”。完整的画面回来了:主要的支持者已经被一个更加持怀疑态度的利益相关者所取代;两周前发送的可交付成果没有收到任何确认;部分首席运营官在心里记下的后续行动从未发送过。
  • ·决定——克劳德对所收集的背景进行推理:利益相关者是谁,积极参与的最后一点是什么,开放的行动项目是什么,以及合理的恢复举措是什么样的。它将失败的后续行动视为最具体的可解决的差距。
  • ·行动 — Claude 调用 `emails_reply_link` 来起草一封基于真实线程历史记录的恢复电子邮件 — 引用已交付的工作、承认沉默、提议进行简短的签到电话。草稿将在部分 COO 的撰写窗口中打开。他们阅读该内容,调整特定关系的语气,然后单击“发送”。
  • ·行动 — Claude 调用“action_items_create”两次:一项用于确认安排了签入电话,另一项用于跟踪利益相关者是否在五个工作日内做出响应。两者都链接到该帐户在 Lodestar 中的项目。
  • ·关闭 — Claude 调用“timeline_events_create”来根据帐户时间线记录恢复外展活动。该事件与原始可交付成果、情绪下降和新的后续行动一起出现在客户的项目中。现在,历史可以作为一个序列而不是分散的片段来阅读。

有什么变化

早上的简报变成了真正的分类,而不是滚动和猜测。部分首席运营官根据实际信号(情绪趋势、逾期的行动项目、已经安静的线程)而不是根据最近发送电子邮件的客户来排名,了解哪些帐户需要关注。健康的账户不会受到影响。在客户发现问题之前需要注意的问题就会浮现出来。

后续行动不再消失。从呼叫或线程中提取的每一项承诺都会被记录下来,分配一个到期日(如果有的话),并在逾期时出现在每日计划中。部分 COO 不再是向谁以及何时承诺的内容的唯一存储库。

更新对话变得更加容易。当季度审查到达时,可以在几秒钟内查询完整的帐户历史记录:做出的决策、交付的交付物、一段时间内的情绪、未清项目。过去考古工作需要一个小时的更新准备工作现在只需几分钟。部分首席运营官带着完整的图片而不是重建的近似值进入通话。

带来的变化

  • ·冷却关系更早地浮现出来——在续订电话之前发现了有风险的帐户,并根据真实的线程历史记录而不是从内存中起草了一封恢复电子邮件。
  • ·后续行动不再依赖于部分首席运营官自己的回忆——每项承诺都记录了其来源报价​​,并进行跟踪直至结束。
  • ·早上的背景重建被需要几分钟的排名简报所取代,而不是开放式的收件箱扫描。
  • ·续订准备利用完整的、可查询的帐户历史记录,而不是跨电子邮件、云端硬盘和日历进行手动组合。
  • ·每个客户的运营情况——组织结构图、情绪、未解决的项目、最近的决策——都存在于部分首席运营官的头脑之外,并且可以在任何呼叫之前立即访问。