계약이 끝났는데 고객이 무엇을 해야 할지 몰라 멈춘다면, 문제는 안내 문구보다 상태가 보이지 않는 것에 가깝습니다. 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을 두고 상태가 바뀔 때만 고객에게 알림을 보냅니다. 메시지 양보다 지금 누가 무엇을 기다리는지가 선명한지가 중요합니다.
온보딩은 환영 페이지가 아니라 계약을 첫 가치로 전달하는 운영 시스템입니다. 혼자 만들고 운영할수록 고객의 다음 행동과 예외 경로를 먼저 설계해두면 지원 비용도 함께 줄어듭니다.
Top comments (0)