代理店オーナー会議のライフサイクル: 週 15 回の通話の準備からフォロースルーまで

オペレーター

5 人のチームで 8 つのアクティブなクライアント アカウントを運営している代理店オーナーは、空港の出発ボードのようなカレンダーを持っています。週に 15 件以上の電話 - ステータスレビュー、創造的なブリーフィング、四半期ごとの計画セッション、新規ビジネスに関する会話 - それぞれに異なる種類の準備が必要で、多くの場合、深さも異なります。チームは仕事を提供します。オーナーはほとんどすべてのクライアントとの電話に対応しており、歴史を知り、関係を維持し、部屋で意思決定を下すのが仕事です。

チームは、クライアントとのコミュニケーションと成果物の管理に、Gmail、Slack、共有 Google ドライブ フォルダーを組み合わせて使用​​しています。毎日、これら 8 つの関係にわたってスレッド、決定、コミットメントを生成する 5 人の人がいます。所有者はすべてのスレッドに存在するわけではありません。彼らはすべての電話に出ます。これら 2 つの事実の間にギャップがあると、問題が発生します。

限界点

準備ができていない状態でクライアントの電話を受けることは、抽象的なリスクではありません。それは毎週の出来事です。劇的に準備ができていないわけではありません。オーナーは、クライアントが誰であるか、プロジェクトが何であるか、物事がおおよそどの段階にあるかを知っています。しかし、実際に重要となる具体的な準備は、2 週間前に何が決定されたのかを知っていること、クライアントがどの未解決の項目について尋ねようとしているのかを知っていること、最初の 5 分で提出される成果物の納期を 3 日遅れているチームメンバーがいることを知っていることなどです。これには、めったに行われない準備セッションが必要です。週に 15 回の電話では、15 回の準備セッションを行う余地はありません。

フォローアップ問題は、準備問題の鏡像です。電話が終わった後、所有者は何が決定され、何が約束されたのかを頭の中でリスト化します。そのリストはすぐに蒸発し始めます。オーナーは、何かを書き留める前に次の電話に出てしまうことがよくあります。一日の終わりまでに、以前の呼び出しでの 2 つまたは 3 つのコミットメントはどのシステムにも痕跡がありません。チームは彼らの存在を知りません。クライアントはそれらを覚えています。代理店はそうではありません。

その結果、会議のライフサイクルは 2 つの破綻した終わりを伴うことになります。準備エンドではオーナーが不完全な全体像を持って到着し、フォロースルーエンドでは会議室で行われた約束がタスクボードにもクライアントの要約にも反映されません。真ん中の部分、つまり実際の会話は問題ありません。周囲のインフラはそうではありません。

セットアップ

代理店のオーナーは、チームがクライアントのスケジュール設定に使用する Gmail と共有 Google カレンダーを接続します。これらは Google ドライブに接続されており、チームはそこにクライアントの概要、クリエイティブ アセット、ステータス ドキュメントを保存します。 8 つのクライアントのそれぞれが Lodestar に独自の組織を持ち、それぞれの内部にアクティブなエンゲージメントに対応するプロジェクトがあります。つまり、ここではブランド更新プロジェクト、そこには有料メディア リテイナー、別の場所では Web サイトを構築しています。

5 人のチーム メンバーが関連する組織とプロジェクトに追加されるため、電子メール スレッドとアクション アイテムが共有画像に流れ込みます。代理店のオーナーは、チームが参加したことのないスレッドで行ったコミットメントを可視化できるようになりました。Lodestar によって抽出され、ソース引用にリンクされ、プロジェクト ビューに表示されます。彼らはすべてのメールを読むわけではありません。彼らはすべてから抽出された信号を確認します。

ワークフロー

会議のライフサイクルは 2 つのフェーズで実行されます。準備フェーズは通話の前に行われます。理想的には、いつでも利用できる数分前に行われます。フォロースルーフェーズはその直後に起こります。どちらも、他のアプリケーションを開くことなく、Lodestar MCP を介したクロードとの会話を通じて処理されます。

• ·Before — オーナーはクロードに、クライアントの名前を挙げて次の電話に備えるように依頼します。クロードは、`calendar_retrieve` を呼び出して会議の詳細と出席者を確認し、その後、それらの出席者との過去 2 週間のスレッドに関する `emails_content` を呼び出します。
• ·前 — クロードは「knowledge_search」を呼び出して、現在のプロジェクトの概要、最新のステータス資料、未解決の提案など、関連するドライブ ドキュメントを表示します。 `contacts_retrieve` と `knowledge_org_charts` を呼び出して、最近のスレッドに登場した新しい関係者を含む、ルームにいる人を確認します。
• ·Before — クロードは、クライアントのプロジェクトでアイテムを開くことをスコープとする `action_items_list` を呼び出し、期限を過ぎたアイテムや所有者が個人的にコミットしたアイテムにフラグを立てます。準備の概要が戻ってきます。会議の議題の内容、最後の決定事項、今後出てくる可能性のある未解決の項目、出席者、最近のコミュニケーションの調子などです。
• ·Before — 所有者が概要を読みます。 1ページです。彼らは、クライアントが調達する可能性が高い金額、チームがまだ負っている金額、前回会ったときに何が決まったかを正確に把握した上で電話に臨みます。
• ·後 — 所有者は、通話中のメモを同じクロードの会話に入力します。下された決定、約束された成果物、誰が何を所有するか、言及された日付などを記録します。クロードは、生のメモから構造化されたアクション アイテムを抽出します。
• ·後 — クロードはコミットメントごとに「action_items_create」を呼び出し、それぞれを Lodestar の適切なプロジェクトに割り当てます。チーム メンバーが所有者として指定されている場合、アイテムはそのメンバーに割り当てられます。期限が記載されている場合は、その期限が設定されます。呼び出しの決定によってマイルストーンが影響を受けた場合、Claude は `milestones_partial_update` を呼び出します。
• ·後 — クロードは「timeline_events_create」を呼び出して、クライアントのプロジェクト タイムラインに対して会議自体を記録します。次に、`emails_reply_link` を呼び出してクライアント向けに通話後の要約を作成します。これは、何が決定され、次に何が予定されるのかについての明確な要約であり、所有者が確認して送信できるように準備されています。
• ·後 — 所有者は要約ドラフトを読み、調整を行って、「送信」をクリックします。ループは閉じています。クライアントは書面による記録を持ち、チームは Lodestar に割り当てを持ち、プロジェクトのタイムラインには会議が反映されます。

何が変わるのか

準備の問題は、以前は解決するのが現実的ではなかった時点、つまり多忙なカレンダーの電話会議の数分前に解決されます。 Lodestar のライブ データからブリーフが自動的に組み立てられるため、オーナーは会議ごとに専用の準備ブロックを必要としなくなりました。これは完璧な詳細調査ではありません。これは、クライアントとの通話の最初の 10 分間に実際に起こったことを網羅した、信頼性の高い正確な 1 ページです。

コミットメントの蒸発が止まります。所有者の通話後のメモは、たとえ短くても、通話終了から数分以内に構造化されたアクションアイテムになります。チームメンバーは、オーナーからの Slack メッセージを必要とせずに、Lodestar で自分の割り当てを確認できます。顧客は、薄れつつある記憶から再構成されたものではなく、実際の会話記録から下書きされた要約メールを受け取ります。

チームが共有するクライアントのステータスの状況は最新のままです。アクション アイテムは通話だけでなくスレッドからも抽出されるため、所有者が参加していない電子メール スレッドでコミットメントを生成したチーム メンバーは、引き続きクライアントのプロジェクトに表示されます。オーナーは、チームに説明を求めることなく、通話前に各エンゲージメントの完全な状態を確認できます。