계약까지 끝났는데 고객이 첫 단계에서 멈춘다면, 환영 문구보다 상태 전환 조건을 먼저 확인해야 합니다. 1인 개발자는 영업·개발·지원을 함께 맡기 때문에 온보딩을 기억으로 운영할수록 누락이 생깁니다. 첫 7일을 작은 상태 머신처럼 다루면 고객과 운영자 모두 다음 행동을 바로 알 수 있습니다.
체크리스트보다 상태 머신이 필요한 이유
체크박스는 운영자가 무엇을 했는지는 알려주지만 고객이 실제로 다음 단계로 이동했는지는 보여주지 못합니다. 예를 들어 ‘계정 생성 메일 발송’은 완료됐어도 고객이 로그인하지 않았다면 온보딩은 진행되지 않은 상태입니다.
각 단계에는 현재 상태, 다음 상태로 넘어가는 조건, 지금 행동해야 할 사람, 마감이 지났을 때의 예외 경로를 함께 붙여보세요.
첫 7일을 네 개의 이벤트로 줄이기
1. contract_confirmed
계약과 결제를 확인한 날에는 긴 환영 자료보다 이번 주의 첫 결과, 고객이 오늘 할 일 하나, 질문할 공식 경로를 먼저 보냅니다. 여러 요청을 한꺼번에 던지면 시작 전부터 고객의 작업 대기열이 생깁니다.
2. required_data_received
자료는 필수·선택·나중으로 나눕니다. 필수는 없으면 첫 결과를 만들 수 없는 항목만 남기고, 요청마다 용도·형식·기한을 붙입니다. 선택 자료가 늦어져도 첫 작업은 시작할 수 있어야 합니다.
3. first_value_delivered
첫 결과는 완제품일 필요가 없습니다. 실제 고객 데이터가 들어간 진단표 한 장, 핵심 화면 시안 하나, 테스트 발송처럼 구매한 약속이 움직이고 있음을 보여주는 결과면 충분합니다. 이 단계가 빠르면 잘못된 방향도 적은 비용으로 고칠 수 있습니다.
4. steady_state_entered
첫 결과 피드백과 다음 일정을 합의하면 정규 운영으로 전환합니다. 완료된 일, 남은 일, 고객 확인 항목, 다음 전달일을 한 화면에 남겨 매번 진행 상황을 처음부터 설명하지 않게 합니다.
데이터 모델은 네 필드로 시작합니다
초기에는 복잡한 워크플로 엔진보다 onboarding_status, next_action, waiting_on, due_at 네 필드만 두어도 충분합니다. 상태가 바뀔 때만 알림을 보내고, waiting_on이 고객인지 운영자인지 분명히 표시합니다. 메시지 양보다 현재 누가 무엇을 기다리는지가 선명한지가 중요합니다.
자동화는 예외를 관찰한 다음에 붙입니다
처음부터 모든 안내를 자동화하면 잘못된 요청도 더 빠르게 반복됩니다. 최소 세 건은 수동으로 운영하면서 상태 체류 시간, 재요청한 자료, 반복 질문, 일정 변경을 기록하세요. 같은 질문이 세 번 나오면 시작 메시지를 고치고, 같은 자료가 두 번 빠지면 제출 예시를 추가합니다.
구현 전 점검
- 고객이 오늘 해야 할 행동이 하나로 보이는가
- 다음 상태로 넘어가는 조건이 행동으로 정의돼 있는가
- 첫 결과에 고객의 실제 정보가 반영돼 있는가
- 마감이 지나면 누가 어떤 메시지를 보내는가
- 정규 운영으로 전환되는 시점이 분명한가
온보딩은 환영 페이지가 아니라 계약을 첫 가치로 전달하는 운영 시스템입니다. 혼자 만들고 운영할수록 성공 경로뿐 아니라 멈췄을 때 돌아오는 경로까지 먼저 설계해두면 지원 비용을 줄일 수 있습니다.
Top comments (0)