고객 성공 팀에 각 클라이언트를 이미 알고 있는 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에 의존하는 고객 성공 관리자, 계정 관리자 및 전문 서비스 팀을 위해 설계되었습니다. 클라이언트 지식이 인수인계, 역할 변경 및 제도적 계정 지식이 취약해지는 자연스러운 이직을 견뎌야 하는 팀에 특히 유용합니다.
이 사용 사례를 내 계정에서 직접 실행하기
MemoryRouter 위의 온보딩 어시스턴트. 기억은 두 가지입니다: 팀이 함께 쓰는 플레이북(1주차 12개, 12개월차 293개)과 각 고객의 배경(Azure AD가 아닌 Okta, 프랑크푸르트만, XML만, API로 JSON 전송, SSO 없음, 토요일에만 교육). 같은 12개 질문을 세 가지 구성으로 묻습니다.
보게 될 것
- 고객마다 둘 다 담은 boundary 하나(
boundary create --projects <플레이북> --human-actor <고객>): 온보딩 질문은 플레이북의 말투로 쓰여 플레이북 항목이 자리를 차지합니다. Copperline은 CSV 파일을 보내라는 답을 받아 9회 중 0회 정답. 예외는 작은 플레이북에서 72개 중 60개, 큰 플레이북에서 53개를 지킴 - 검사기(MemoryRouter가 붙인 기억을 Claude가 그대로 옮겨 적음)가 이유를 보여 줍니다: 그 질문에는 CSV에 관한 플레이북 항목이 붙고 고객의 줄은 붙지 않았습니다(14회 중 13회). 고객의 줄이 들어가도 나란한 항목 하나일 뿐이라 여전히 밀릴 수 있습니다
- 페이지 말대로 고객 배경을 먼저 넣기:
fact list --actors <고객>(전부, 몇 개뿐)을 system prompt에 넣고 MemoryRouter는 플레이북만 담당. 예외 72개 중 71개. 표준 경로 질문 4개가 대조군(36회 중 34회) - 모든 답은
Answer:로 시작하며 채점되어 출력됩니다. 합계는 9회 실행 전체 기준. 그 밖에client,ask하위 명령과 로컬 웹 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를 통해 가능합니다.