顧客成功チームにすでに各クライアントを知っているAIを提供する
すべての新しいクライアントとのエンゲージメントは、AIがあなたの会社の業務内容を尋ねることから始まるべきではありません。MemoryLakeは、クライアントコンテキスト、オンボーディングワークフロー、およびアカウント履歴を持続的に保存します。これにより、新しいクライアントとの最初のセッションは、すでに正しい背景が読み込まれた状態で始まります。
記憶の問題
顧客成功およびプロフェッショナルサービスチームは、すべてのエンゲージメントの開始時に同じコンテキスト設定を繰り返します。彼らは自社のサービスモデルを説明し、クライアントの背景を貼り付け、アカウント履歴についてAIに再説明し、前回のセッションからワークフローを再構築します。10または20のアクティブアカウントを管理しているチームにとって、このオーバーヘッドは重要であり、AIは設定に10分を費やした後にのみ役立つことを意味します。
MemoryLakeの異なる点
最初のメッセージの前にクライアントのアイデンティティが読み込まれる
Background Memoryは、各クライアントに関する読み取り専用のコンテキストを保存します — 業界、アカウント設定、主要な連絡先、製品使用状況、および明示された好みです。そのクライアントのすべてのAIセッションは、このコンテキストがすでに整っている状態で始まり、手動での再説明は不要です。
毎回同じ方法で実行されるオンボーディングワークフロー
Skill Memoryは、オンボーディングプロセスのステップ、キックオフフレームワーク、およびチェックリスト構造を保存します。どのチームメンバーがどのクライアントのオンボーディングを実行しても、同じ実績のあるワークフローを引き出します — アドホックな再構築は不要で、ステップの欠落もありません。
完全なアカウント履歴が永久にアクセス可能
Conversation Memoryは、各クライアントアカウントのすべてのAIセッションを保存します。アカウントに参加する新しいCSMは、完全なエンゲージメント履歴を照会できます — 何が議論されたか、何が約束されたか、何がエスカレーションされたか — 常に不完全な引き継ぎノートに依存することなく。
永続無料 · クレジットカード不要
仕組み
- 接続 — Google Workspace、Office 365、MySQL、PostgreSQL、またはREST APIを介してクライアントデータを取り込みます。CRMデータ、アカウント記録、および以前のエンゲージメントノートはすべてMemoryLakeにフィードされます。
- 構造化 — クライアントのアイデンティティはBackground Memoryに入ります。オンボーディングのステップとワークフローはSkill Memoryに入ります。アカウントのインタラクションはConversation Memoryに入ります。各記憶タイプは、クライアント関係において異なる機能を果たします。
- 再利用 — アカウントに関わるすべてのチームメンバー — CSM、ソリューションエンジニア、アカウントエグゼクティブ — は、同じ持続的なクライアント記憶から引き出し、役割に基づく権限が各役割がアクセスまたは変更できる内容を制御します。
ビフォー & アフター
| Without MemoryLake | With MemoryLake | |
|---|---|---|
| Starting a new client session | Manually re-brief AI on client background | Background Memory loads client context automatically |
| Running the onboarding process | Reconstruct steps from memory or documentation | Skill Memory executes the same workflow every time |
| CSM handoff or escalation | Incomplete notes; context loss guaranteed | Full account history queryable by any authorized team member |
| Multi-client team management | Context juggled manually across accounts | Each account has isolated, persistent memory |
対象
MemoryLakeは、複数のクライアント関係を同時に管理し、コミュニケーション、文書化、およびワークフローの実行を支援するためにAIに依存する顧客成功マネージャー、アカウントマネージャー、およびプロフェッショナルサービスチームのために構築されています。クライアントの知識が引き継ぎ、役割の変更、そして制度的なアカウント知識を脆弱にする自然な turnover を生き延びる必要があるチームに特に役立ちます。
このユースケースを自分のアカウントで試す
MemoryRouter 上のオンボーディング・アシスタント。記憶は2種類：チーム共有のプレイブック（1週目 12 件、12か月目 293 件）と各クライアントの背景（Azure AD でなく Okta、フランクフルトのみ、XML のみ、API 経由の JSON、SSO なし、土曜のみ研修）。同じ 12 問を3つの構成で尋ねます。
見られるもの
- クライアントごとに両方を含む boundary を1つ（
boundary create --projects <プレイブック> --human-actor <クライアント>）：オンボーディングの質問はプレイブックの言葉で書かれるので、その記述が枠を取る。Copperline は CSV を求められ、9 回中 0 回正解。例外は小さいプレイブックで 72 中 60、大きいもので 53 - チェッカー（MemoryRouter が付けた記憶を Claude に書き出させる）が理由を示す：その質問では CSV に関するプレイブックの記述が付き、クライアントの行は付かなかった（14 回中 13 回）。クライアントの行が入っても並列の1項目にすぎず、負けることがある
- ページの言う通りクライアントの背景を先に読み込む：
fact list --actors <クライアント>（全件、数件だけ）を system prompt に入れ、MemoryRouter はプレイブックだけ。例外 72 中 71。標準どおりの 4 問が対照（36 中 34） - 各回答は
Answer:で始まり、採点して表示。合計は全 9 回の実行分。ほかにclient、askとローカル Web UI
必要なもの: MemoryLake の API キー · memorylake CLI · Python 3.9 以上
実行する
git clone https://github.com/memorylake-ai/memorylake-usecases.git cd memorylake-usecases/client-background-memory export MEMORYLAKE_API_KEY=sk-… python3 demo.py # or: python3 web/server.py
動作を見る · 実際の録画、未編集
関連するユースケース
よくある質問
Background Memoryは、クライアントが自分のコンテキストを変更できないように制限できますか？
Background Memoryは、クライアントが自分のコンテキストを変更できないように制限できますか？
はい。Background Memoryは設計上読み取り専用です — セッション開始時に読み込まれる持続的なコンテキストを提供しますが、セッション活動によって上書きされることはありません。あなたはそれに何が入るか、いつ更新されるかを制御します。
複数のクライアントアカウントを管理するチームの役割ベースのアクセスはどのように機能しますか？
複数のクライアントアカウントを管理するチームの役割ベースのアクセスはどのように機能しますか？
MemoryLakeの役割ベースのアクセス制御により、アカウントごとに記憶の境界を定義できます。クライアントAのCSMは、デフォルトではクライアントBの記憶にアクセスできません。アカウント内では、アカウントエグゼクティブ、CSM、およびソリューションエンジニアが何を読み取ったり変更したりできるかを区別できます。完全な監査トレイルがすべてのアクセスイベントを記録します。
MemoryLakeはクライアントデータを取得するためにCRMシステムと統合していますか？
MemoryLakeはクライアントデータを取得するためにCRMシステムと統合していますか？
MemoryLakeは、MySQL、PostgreSQL、REST APIを含む一般的なデータソースと統合しており、ほとんどのCRMデータエクスポートパスをカバーしています。Google WorkspaceおよびOffice 365の統合も、文書ベースのクライアント記録のために利用可能です。直接のCRM統合はREST APIおよびPython SDKを介して利用可能です。