B2B SaaS onboarding adoption health score 체크리스트 2026, login activation·feature usage·support ticket·renewal risk를 customer success 리포트로 묶기 전 확인할 기준
B2B SaaS onboarding adoption health score 체크리스트 2026, login activation·feature usage·support ticket·renewal risk를 customer success 리포트로 묶기 전 확인할 기준
B2B SaaS에서 enterprise 계약이 끝난 뒤 customer success 팀이 가장 먼저 봐야 할 것은 "고객이 샀는가"가 아니라 "고객이 실제로 쓰기 시작했는가"입니다. kickoff는 잡혔고, SSO도 켰고, billing contact도 남겼는데, 정작 핵심 사용자는 로그인하지 않았거나 첫 프로젝트를 만들지 않았거나 support ticket만 늘고 있다면 갱신 위험은 조용히 커집니다.
이 글은 고객 성공 컨설팅, 재무 예측, 법률 자문이 아닙니다. B2B SaaS 운영팀이 onboarding 이후 login activation, feature usage, support ticket, billing status, security blocker, renewal risk를 하나의 adoption health score 리포트로 묶기 전 확인할 운영 체크리스트입니다.
직전 글인 B2B SaaS enterprise procurement handoff 체크리스트는 closed-won 이후 procurement, security review, billing contact, SSO setup, renewal owner를 customer success로 넘기는 기준을 다뤘습니다. 이번 글은 그 handoff 이후 실제 사용 신호를 보는 단계입니다. 보안 검토 증거는 B2B SaaS security questionnaire·vendor review evidence 체크리스트와 연결하고, 지원 접근 이슈는 B2B SaaS support impersonation·customer access 감사 체크리스트와 함께 확인하는 편이 좋습니다.
health score는 점수보다 근거 신호가 먼저입니다
adoption health score를 하나의 숫자로 만들고 싶은 유혹이 큽니다. 하지만 숫자만 있으면 왜 위험한지, 누가 조치해야 하는지, 어떤 데이터가 빠졌는지 알 수 없습니다. 좋은 health score는 점수 이전에 근거 신호를 안정적으로 모으는 구조입니다.
또한 health score에는 모든 SaaS에 공통으로 적용되는 보편 산식이 없습니다. 협업 도구, 자동화 도구, 분석 도구, 고객지원 도구는 핵심 사용 행동이 다릅니다. 이 글의 목적은 가중치 공식을 정하는 것이 아니라, 제품별로 가중치를 정하기 전에 account 단위 데이터가 같은 고객을 가리키는지 확인하는 것입니다.
| 신호 | 운영 질문 |
|---|---|
| account activation | 계약된 account와 실제 workspace가 연결됐는가 |
| login activation | admin, champion, end user가 각각 로그인했는가 |
| feature usage | 구매 이유와 연결된 핵심 기능을 썼는가 |
| support load | ticket 수가 사용 확대 신호인지 장애 신호인지 구분했는가 |
| billing status | 결제 실패, invoice 미수신, 구매 담당자 변경이 있는가 |
| security blocker | SSO, SCIM, audit log, data request 이슈가 adoption을 막는가 |
| renewal risk | 갱신 전 owner, success metric, blocker가 같은 리포트에 있는가 |
핵심은 green, yellow, red 색깔을 빨리 붙이는 것이 아닙니다. 어떤 근거로 그 색깔이 나왔고, 다음 action owner가 누구인지 남기는 것입니다.
최소 식별자는 account_id, workspace_id, crm_company_id, billing_customer_id, cs_owner처럼 분리해 둡니다. 네 값이 서로 다른 고객을 가리키면 health score는 정확해 보이지만 실제로는 잘못된 리포트가 됩니다.
login activation은 전체 로그인 수보다 역할별 첫 사용을 봅니다
첫 로그인 수만 보면 adoption을 과대평가하기 쉽습니다. enterprise 고객은 admin 한 명이 설정을 끝냈지만 실제 사용자 그룹은 아직 초대되지 않았을 수 있고, 반대로 많은 사용자가 초대됐지만 핵심 champion은 로그인하지 않았을 수 있습니다.
출처: GitHub Docs – Viewing people in your enterprise
login activation 리포트에는 아래처럼 역할을 분리합니다.
| 역할 | 확인할 값 |
|---|---|
technical_admin |
workspace 생성, domain verification, SSO 설정 여부 |
business_owner |
kickoff 참석, success metric 확인 여부 |
champion_user |
첫 로그인, 첫 핵심 기능 사용 여부 |
end_user_group |
초대 수, 활성 사용자 수, 미활성 사용자 수 |
support_contact |
support portal 또는 ticket 접수 경로 확인 여부 |
renewal_owner |
갱신 전 리뷰 일정과 사용량 리포트 수신 여부 |
단순 MAU보다 "역할별 첫 사용이 끝났는가"를 보면 onboarding 병목이 더 빨리 보입니다.
feature usage는 구매 이유와 연결된 행동만 핵심 신호로 둡니다
모든 클릭을 adoption 신호로 넣으면 리포트가 금방 시끄러워집니다. customer success health score에서는 고객이 샀던 이유와 연결된 몇 개 행동만 핵심 사용 신호로 둬야 합니다.
출처: Google Analytics Help – Events and key events
| 구매 이유 | 핵심 사용 신호 예시 |
|---|---|
| team collaboration | 첫 workspace 생성, member invite, shared project 생성 |
| workflow automation | 첫 automation draft, test run, production run |
| analytics reporting | dashboard 생성, report schedule, stakeholder share |
| security control | SSO enforced, audit log reviewed, role mapping tested |
| customer support | first ticket sync, macro use, escalation rule configured |
| billing optimization | usage threshold alert, invoice owner confirmed |
GA4나 내부 product analytics를 쓰더라도 이벤트 이름은 도구용 로그와 CS 리포트용 요약을 분리하는 편이 좋습니다. 예를 들어 workflow_run_created는 원본 이벤트이고, CS 리포트에는 first_value_signal = automation_live처럼 고객 성공 관점의 요약 필드로 남깁니다.
support ticket은 많을수록 나쁘다는 뜻이 아닙니다
onboarding 초기에 support ticket이 많다고 바로 위험 계정으로 보면 안 됩니다. 설정 질문과 교육 요청은 adoption이 시작됐다는 신호일 수 있습니다. 반대로 ticket 수가 적어도 핵심 사용자가 로그인하지 않았다면 더 큰 위험일 수 있습니다.
출처: Zendesk Developer Docs – Tickets API
support signal은 아래처럼 나눠야 합니다.
| ticket 유형 | health score 해석 |
|---|---|
| setup_question | onboarding 진행 신호일 수 있음 |
| bug_blocker | 기능 사용 차단 위험 |
| billing_issue | 결제·구매 담당자 위험 |
| sso_scim_issue | enterprise activation 차단 위험 |
| data_request | 보안·운영 검토와 연결 |
| how_to_training | 교육 필요 신호 |
| no_ticket_no_usage | 조용하지만 위험한 계정 |
티켓 수 자체보다 blocker_ticket_open, average_first_response, customer_waiting, training_need, resolved_before_kickoff 같은 상태가 더 중요합니다.
billing과 subscription 상태는 adoption 리포트에서 숨기지 않습니다
customer success가 제품 사용만 보면 갱신 위험을 놓치기 쉽습니다. adoption은 좋은데 invoice가 실패했거나 billing contact가 퇴사했거나 구매 order가 갱신되지 않았으면 고객 경험은 바로 흔들릴 수 있습니다.
출처: Stripe Docs – Subscriptions overview
| billing 신호 | CS 리포트 필드 |
|---|---|
| subscription active | billing_status = active |
| payment failed | billing_blocker = payment_failed |
| invoice overdue | billing_blocker = invoice_overdue |
| billing contact missing | billing_contact_ready = no |
| plan mismatch | plan_access_mismatch = yes |
| renewal date near | renewal_review_due = yes |
이 항목은 재무 판단이 아니라 운영 신호입니다. customer success는 결제 처리를 대신하는 팀이 아니지만, adoption 리포트에서 billing blocker를 볼 수 있어야 갱신 전 조치가 빨라집니다.
CRM에는 원본 이벤트가 아니라 account health 요약을 남깁니다
제품 이벤트, 지원 티켓, 결제 상태를 CRM에 전부 복제하면 데이터가 지저분해집니다. CRM에는 customer success가 후속 조치를 할 수 있는 요약 필드만 남기는 편이 좋습니다.
출처: HubSpot Knowledge Base – Create and edit properties
출처: Salesforce Help – Create a Report
| CRM health 필드 | 예시 값 |
|---|---|
onboarding_stage |
not_started, kickoff_done, setup_in_progress, first_value, live |
activation_status |
blocked, partial, active |
first_value_signal |
dashboard_shared, automation_live, first_report_sent |
open_blocker_count |
0, 1, 2 이상 |
health_band |
green, yellow, red, unknown |
health_reason |
no_champion_login, sso_blocker, support_waiting, billing_issue |
next_cs_action |
schedule_training, escalate_sso, confirm_billing, review_usage |
next_action_owner |
CS, support, billing ops, security ops, customer admin |
CRM은 원본 로그 저장소가 아니라 계정 상태판입니다. 원본 이벤트는 product analytics, support tool, billing system에 두고, CRM에는 후속 조치에 필요한 요약만 넣습니다.
특히 support ticket 원문, 고객 대화 전문, 내부 보안 메모, 개인 식별 정보는 health score 리포트로 복제하지 않는 편이 안전합니다. CS 리포트에는 ticket_open_count, highest_ticket_severity, customer_waiting, blocker_type처럼 상태 요약만 남기고, 원문은 권한이 맞는 원본 시스템에서 확인하도록 연결합니다.
health band는 unknown을 허용해야 합니다
green, yellow, red만 있으면 데이터가 없는데도 억지로 색을 붙이게 됩니다. health score에는 반드시 unknown 또는 insufficient data 상태가 있어야 합니다.
| 상태 | 의미 |
|---|---|
| green | 핵심 사용자와 기능 사용 신호가 있고 blocker가 낮음 |
| yellow | 사용은 시작됐지만 blocker 또는 owner 공백이 있음 |
| red | 핵심 사용 신호가 없거나 갱신·지원·보안 blocker가 큼 |
| unknown | 데이터 연결이 안 됐거나 owner가 확인하지 않음 |
unknown은 부끄러운 상태가 아니라 운영 신호입니다. unknown 계정이 많다면 adoption이 나쁜 것이 아니라 리포트 연결이 깨졌을 수 있습니다.
renewal risk는 만료일 30일 전이 아니라 onboarding 때부터 쌓입니다
갱신 위험은 계약 종료 직전에 갑자기 생기지 않습니다. 첫 가치 실현이 늦어지고, champion이 바뀌고, support blocker가 반복되고, billing contact가 비어 있고, 보안 예외가 남는 순간부터 누적됩니다.
기존 B2B SaaS trial-to-paid 전환 추적 감사 체크리스트는 trial end와 subscription_created를 매출 보고서와 연결하는 기준을 다뤘고, B2B SaaS 구독 취소·churn reason 추적 감사 체크리스트는 취소 사유와 운영 분류를 분리했습니다. onboarding health score는 그 중간에서 갱신 위험이 커지기 전에 신호를 모으는 리포트입니다.
| renewal risk 신호 | 확인할 질문 |
|---|---|
| no first value | 고객이 구매 이유와 연결된 첫 결과를 만들었는가 |
| champion inactive | 내부 champion이 최근 14일 또는 30일 안에 활동했는가 |
| SSO blocker | SSO·SCIM 설정 지연이 전체 사용을 막는가 |
| support blocker | unresolved blocker ticket이 남아 있는가 |
| billing blocker | invoice, payment, PO, billing contact 이슈가 있는가 |
| low expansion signal | 좌석 추가, 기능 확장, usage increase 신호가 전혀 없는가 |
| unresolved security exception | 보안 예외나 evidence 요청이 갱신 전 위험으로 남는가 |
renewal risk는 담당자를 탓하기 위한 점수가 아니라, customer success가 먼저 움직일 수 있게 만드는 조기 경보입니다.
monthly CS 리포트는 activity보다 action을 보여줘야 합니다
월간 리포트가 로그인 수, 티켓 수, 기능 사용 수만 보여주면 다음 행동이 흐려집니다. 좋은 CS 리포트는 각 계정의 다음 action과 owner를 보여줍니다.
| 리포트 섹션 | 봐야 할 질문 |
|---|---|
| onboarding status | kickoff 이후 setup이 어디에서 멈췄는가 |
| activation gap | 어떤 역할이 아직 첫 사용을 하지 않았는가 |
| feature adoption | 구매 이유와 연결된 핵심 기능을 썼는가 |
| support blocker | customer waiting 또는 unresolved blocker가 있는가 |
| billing blocker | 결제·invoice·billing contact 이슈가 있는가 |
| renewal risk | 갱신 전 반드시 해결할 blocker가 있는가 |
| next action | 누가 언제까지 무엇을 할 것인가 |
리포트의 목적은 계정을 평가하는 것이 아니라 다음 일을 정하는 것입니다.
adoption health score 템플릿
아래 템플릿은 CRM이나 customer success board에 바로 옮겨 쓸 수 있는 최소 구조입니다.
| 섹션 | 필드 |
|---|---|
| account | account ID, workspace ID, plan, segment, CS owner |
| onboarding | onboarding stage, kickoff date, target go-live date |
| activation | admin login, champion login, invited users, active users |
| feature usage | primary use case, first value signal, key feature used |
| support | open blocker count, latest ticket type, customer waiting |
| billing | billing status, invoice issue, billing contact ready |
| security | SSO status, SCIM status, security exception count |
| renewal | contract end, renewal owner, usage review date, renewal risk reason |
| action | next action, owner, due date, customer-visible summary |
이 템플릿에서 가장 중요한 필드는 next action, owner, due date입니다. 점수가 낮아도 owner가 없으면 아무 일도 일어나지 않습니다.
초기 필드 이름은 onboarding_stage, first_value_event, active_admin_count, core_feature_7d, ticket_open_count, ticket_severity, renewal_date, risk_reason, cs_owner처럼 단순하게 시작하는 편이 좋습니다. 나중에 점수 모델을 만들더라도 이 원본 요약 필드가 있어야 가중치 변경을 추적할 수 있습니다.
바로 쓰는 체크리스트
- account, workspace, CRM company, billing customer가 같은 고객을 가리키는가.
- admin, champion, end user의 login activation을 분리했는가.
- feature usage는 구매 이유와 연결된 핵심 행동만 선택했는가.
- support ticket을 setup question, blocker, billing issue, SSO issue, training need로 나눴는가.
- billing status와 subscription blocker를 CS 리포트에서 볼 수 있는가.
- CRM에는 원본 이벤트가 아니라 health summary와 next action만 남기는가.
- health band에
unknown또는insufficient data상태가 있는가. - renewal risk reason이 no first value, inactive champion, SSO blocker, billing issue처럼 행동 가능한 값인가.
- monthly CS 리포트가 activity count보다 owner와 due date를 보여주는가.
- 데이터가 없을 때 green으로 처리하지 않고 데이터 연결 문제로 표시하는가.
마무리
B2B SaaS onboarding adoption health score는 고객을 점수로 줄이는 장치가 아닙니다. 계약 이후 실제 사용, 지원 이슈, 결제 상태, 보안 blocker, 갱신 위험을 한 화면에서 보고 다음 행동을 정하는 운영 리포트입니다.
처음부터 완벽한 점수 모델을 만들 필요는 없습니다. account 연결, 역할별 로그인, 핵심 기능 사용, support blocker, billing blocker, renewal owner만 안정적으로 모아도 customer success 팀은 훨씬 빨리 움직일 수 있습니다. 숫자보다 중요한 것은 "왜 위험한가", "누가 조치하는가", "언제 다시 확인하는가"입니다.
공식 출처
About The Author
