SaaS 팀이 온보딩을 스스로 완결되는 여정으로 바꾸는 방법

출발점

이 시나리오에서 한 분석 SaaS는 건강한 가입과 약한 활성화를 가집니다: 많은 사람이 계정을 만들고, 아무것도 연결하지 않으며, 결코 돌아오지 않습니다. 온보딩은 타이머에 발동하는 다섯 통의 이메일 드립이었고 — 사용자가 무엇을 했든 안 했든 같은 순서였습니다 — 고객 성공 팀은 가장 큰 계정만 손수 챙길 수 있었습니다. 어느 계정이 어느 단계에서 막혔는지는 이미 이탈한 뒤에야 아무도 말할 수 없었습니다.

여정

팀은 활성화 흐름을 스토리라인 — 에이전트가 각 신규 계정과 함께 따라가는 그래프 — 으로 설계합니다:

1. 환영. 첫 로그인에서 에이전트가 자신을 소개하고, 바로 그 자리 앱 안에서 첫 데이터 소스 연결을 돕겠다고 제안합니다.
2. 데이터 소스 연결. 이 단계는 사용자가 했다고 말해서 전진하지 않습니다 — 제품이 콜백을 통해 실제 이벤트를 에이전트에게 다시 보고할 때 전진합니다. 그 신호가 도착하기 전까지 에이전트는 이 단계에 머물고, 사용자가 조용해지면 더 가벼운 경로를 제안합니다.
3. 첫 리포트 만들기. 같은 형태: 에이전트가 안내하고, 제품 자신의 "리포트 생성됨" 이벤트가 계정을 앞으로 옮깁니다.
4. 팀원 초대, 그다음 주간 리뷰 습관 만들기 — 각각 하나의 단계이고, 각각 실제 신호에 따라 전진하며, 각각 누군가 멈추면 넛지나 인계로 분기할 수 있습니다.

진행 상황이 사람에게 저장되므로, 여정은 인앱 어시스턴트와 이메일에 걸쳐 이어집니다: 2단계 이후 이탈한 사용자는 3일 뒤 처음부터 다시가 아니라 2단계에서 다시 이어집니다.

무엇이 바뀌나

에이전트는 회사 자신의 도움말 문서를 근거로 답하므로, 일반적인 제품이 아니라 이 제품에 대해 말합니다. 하루 종일 실행되므로, 자정의 가입도 즉시 맞이됩니다. 그리고 훌륭한 온보딩 전문가의 판단 — 다음에 무엇을 할지, 언제 밀어붙일지, 언제 물러설지 — 을 모든 계정에 동시에 스케일하며, 진정으로 멈추는 계정에만 사람을 라우팅합니다.

여기 숫자는 측정된 것이 아니라 구조적입니다: 방송식 순서가 아니라 사용자당 저장된 여정 1개, 24/7 커버리지, 그리고 실제 제품 이벤트가 아니라 사용자의 말에 따라 전진한 단계 0개. 특정 배포의 보고가 아니라 그 형태의 예시입니다.