B2B SaaS enterprise renewal 90/60/30 readiness 체크리스트 2026, QBR action·stakeholder map·billing blocker·security exception을 갱신 일정별로 나누기 전 확인할 기준
B2B SaaS enterprise renewal 90/60/30 readiness 체크리스트 2026, QBR action·stakeholder map·billing blocker·security exception을 갱신 일정별로 나누기 전 확인할 기준
B2B SaaS enterprise renewal은 갱신일 직전에 시작하면 늦습니다. 고객 사용량이 좋아도 QBR action이 닫히지 않았거나, champion이 바뀌었거나, PO와 invoice owner가 비어 있거나, security exception이 남아 있으면 renewal 일정은 쉽게 흔들립니다.
이 글은 가격 인상, 할인, 계약 조건, 법률 검토, 회계 처리, 매출 예측에 대한 조언이 아닙니다. customer success, RevOps, support, billing ops, security ops가 enterprise renewal 90일·60일·30일 전에 같은 readiness board를 보도록 만드는 운영 체크리스트입니다.
직전 글인 B2B SaaS renewal stakeholder map 체크리스트는 champion change, procurement owner, security owner, billing contact를 renewal risk 리포트에 맞추는 기준을 다뤘습니다. 이번 글은 그 stakeholder map과 B2B SaaS customer success QBR renewal review 체크리스트의 QBR action을 90/60/30 일정으로 나누는 데 집중합니다.
90/60/30 readiness는 영업 압박표가 아니라 운영 누락 방지표입니다
90/60/30 표를 영업 forecast처럼만 쓰면 customer success, support, billing, security가 빠집니다. renewal readiness에서 필요한 것은 "언제 계약을 닫을 것인가"가 아니라 "갱신 전에 어떤 운영 공백을 먼저 닫아야 하는가"입니다.
| 구간 | 운영 목적 |
|---|---|
| 90일 전 | account identity, QBR action, stakeholder map, open blocker를 모두 모아 기준선을 만든다 |
| 60일 전 | billing, procurement, security, support blocker owner를 확정하고 고객 대기 상태를 줄인다 |
| 30일 전 | open action, invoice readiness, security exception, executive summary를 마지막으로 검증한다 |
| 7일 전 | 공개 가능한 next step과 내부 escalation owner만 남기고 민감 메모를 분리한다 |
이 표는 고객을 압박하기 위한 문구가 아닙니다. 갱신 전까지 고객과 내부팀이 놓치기 쉬운 action owner, due date, blocker type을 미리 분리하는 운영 장치입니다.
90일 전에는 account identity와 QBR action을 먼저 맞춥니다
90일 전에는 새 일을 많이 만들기보다 계정 데이터가 같은 고객을 가리키는지 확인해야 합니다. CRM company, workspace, billing customer, support organization, security review record가 어긋나면 health score와 billing issue가 서로 다른 고객을 보는 문제가 생깁니다.
출처: HubSpot Knowledge Base – Create tasks
출처: Salesforce Help – Create a Report
| 90일 전 확인 항목 | readiness 필드 |
|---|---|
| CRM company와 opportunity | crm_account_id, renewal_opportunity_id |
| product workspace | workspace_id, plan, active_roles |
| support organization | support_org_id, open_blocker_count |
| billing customer | customer_id, subscription_id, invoice_owner |
| security review record | security_owner, open_exception_count |
| QBR action | action_type, owner, due_date, status |
QBR 후 action item이 있다면 90일 전에 readiness board로 옮겨야 합니다. training, support escalation, billing follow-up, SSO owner 확인 같은 항목이 QBR 문서에만 남아 있으면 60일 전에도 같은 이슈가 반복됩니다.
90일 전 stakeholder map은 최신성 상태가 핵심입니다
stakeholder map은 한 번 만들고 끝나는 문서가 아닙니다. champion, business owner, procurement owner, billing contact, security owner가 90일 전에 확인됐는지 봐야 합니다. 이름이 있는 것보다 최신성 상태가 더 중요합니다.
B2B SaaS renewal stakeholder map 체크리스트에서 정리한 역할을 그대로 90일 전 readiness에 연결하면 됩니다.
| 역할 | 90일 전 상태값 |
|---|---|
| champion | confirmed, changed, inactive, unknown |
| business owner | confirmed, unknown, vacant |
| procurement owner | confirmed, process_unknown, owner_unknown |
| billing contact | confirmed, stale, bounced, unknown |
| security owner | confirmed, exception_open, unknown |
| executive sponsor | confirmed, not_needed, missing |
| internal owner | CS, AE, RevOps, support, billing ops, security ops |
unknown을 green으로 처리하면 안 됩니다. unknown은 고객 문제가 아니라 내부 확인 작업입니다. 90일 전에는 unknown 역할마다 확인 task를 만들고, 고객에게 공유 가능한 문장과 내부 메모를 분리합니다.
60일 전에는 billing blocker를 따로 떼어 봅니다
60일 전에는 billing readiness를 별도 섹션으로 봐야 합니다. 고객이 제품을 잘 쓰고 있어도 invoice owner가 바뀌었거나, PO가 필요하거나, subscription status가 past due이거나, billing contact가 퇴사자 메일이면 갱신 운영은 막힙니다.
출처: Stripe Docs – Subscriptions overview
출처: Stripe Docs – Invoicing overview
| billing 항목 | 60일 전 확인 기준 |
|---|---|
| subscription status | active, trialing, past_due, canceled |
| invoice owner | 고객 finance, procurement, admin 중 누구인지 확인 |
| billing contact | 이메일 bounce, 퇴사자, 공유 메일 여부 확인 |
| PO status | received, requested, missing, not_required |
| payment issue | none, failed, overdue, disputed |
| internal owner | billing ops 또는 finance ops 담당자 |
이 항목은 회계 조언이 아닙니다. CS가 결제를 대신 처리한다는 뜻도 아닙니다. 60일 전에는 billing ops가 확인해야 할 blocker를 renewal action board에 올리고, 고객에게 보낼 수 있는 짧은 확인 문장만 분리합니다. 결제 실패 흐름은 B2B SaaS 결제 실패·dunning 자동화 체크리스트와 연결해 보면 됩니다.
60일 전 security exception은 owner와 due date가 있어야 합니다
enterprise renewal에서 security exception은 막판에 몰리면 위험합니다. SSO, SCIM, audit log, support access, data retention, backup restore, vendor review evidence가 열려 있으면 renewal review가 제품 가치가 아니라 미해결 보안 질문으로 바뀔 수 있습니다.
출처: Microsoft Learn – Sign-in logs in Microsoft Entra ID
출처: Microsoft Learn – Audit logs in Microsoft Entra ID
| security 항목 | 60일 전 readiness 필드 |
|---|---|
| SSO 상태 | configured, enforced, blocked, not_requested |
| SCIM 상태 | test_done, pending, blocked, not_requested |
| audit log request | view_ready, export_needed, owner_unknown |
| support access | impersonation policy 확인 필요 여부 |
| data request | export, deletion, retention, backup restore open 여부 |
| exception owner | 고객 owner와 내부 owner가 모두 있는지 |
| due date | renewal review 전 닫을 필요가 있는지 |
보안 보증이나 인증 가능 여부를 단정하지 않습니다. readiness board에는 open item, owner, due date, customer-visible summary만 남기고, 실제 evidence는 원본 security review 도구에서 관리합니다. 관련 점검은 B2B SaaS security questionnaire·vendor review evidence 체크리스트와 B2B SaaS enterprise SSO·SCIM 권한 동기화 체크리스트에 이어집니다.
support blocker는 60일 전에 고객 대기와 내부 대기를 나눕니다
support ticket이 남아 있다면 60일 전에는 티켓 수보다 대기 방향을 확인해야 합니다. 고객 응답 대기인지, 내부 제품팀 대기인지, billing 확인 대기인지, security owner 대기인지에 따라 action owner가 달라집니다.
출처: Zendesk Developer Docs – Tickets API
| support 상태 | readiness action |
|---|---|
| customer waiting | 고객 owner와 다음 회신 예정일 확인 |
| internal waiting | support 또는 product owner 지정 |
| escalation open | escalation owner와 다음 업데이트일 확인 |
| billing related | billing contact와 billing ops에 연결 |
| security related | security owner와 security ops에 연결 |
| training request | champion 또는 admin 교육 일정 확인 |
support 원문, 고객 대화 전문, 내부 triage 메모를 renewal 자료에 그대로 복사하지 않습니다. readiness board에는 blocker type, owner, next update due만 남기고, 민감한 원문은 support tool에 둡니다.
30일 전에는 open action을 닫을지, 넘길지 결정합니다
30일 전에는 새 문제를 찾는 것보다 남은 action을 닫을지, renewal 이후 follow-up으로 넘길지, executive review에 올릴지 결정해야 합니다. 모든 일을 30일 안에 해결하려 하면 board가 지저분해집니다.
출처: GitHub Docs – About Projects
| 30일 전 decision | 기준 |
|---|---|
| close before renewal | billing blocker, security exception, support blocker가 갱신 전 필수인 경우 |
| customer follow-up | 고객 owner 확인이 필요하지만 갱신 조건 판단은 아닌 경우 |
| internal follow-up | 내부 데이터 연결, task 정리, dashboard 수정 |
| executive review | sponsor decision, blocker escalation, 일정 조정 필요 |
| post-renewal action | 사용 교육, dashboard 개선, adoption expansion처럼 갱신 이후 처리 가능 |
project board에는 status, owner, due_date, customer_visible_summary, internal_note가 있어야 합니다. 특히 internal_note에는 고객에게 그대로 공유하면 안 되는 계정 전략, 민감한 support triage, 가격 협상 메모를 넣을 수 있으므로 view 권한을 분리해야 합니다.
30일 전 executive summary는 세 줄로 충분해야 합니다
30일 전 executive summary가 길어지면 핵심이 흐려집니다. 좋은 summary는 사용 상태, open blocker, 필요한 decision을 나눕니다. forecast나 churn prediction처럼 단정적인 표현을 쓰기보다 readiness 상태를 보여주는 편이 안전합니다.
| summary 줄 | 예시 구조 |
|---|---|
| usage/readiness | primary use case, adoption status, data confidence |
| blocker | billing, security, support, stakeholder 중 open item |
| decision/action | 누가 언제까지 무엇을 결정하거나 확인해야 하는지 |
예를 들어 "health score yellow"만 쓰는 대신 "champion changed, billing contact confirmed, SSO exception open, security owner due date pending"처럼 action 가능한 신호로 씁니다. adoption health score 기준은 B2B SaaS onboarding adoption health score 체크리스트에서 이어집니다.
7일 전에는 고객 공유 view와 내부 working view를 분리합니다
7일 전에는 새 내부 메모를 고객 자료에 섞지 않는 것이 중요합니다. 고객 공유 view에는 확인할 연락처, open action, 다음 일정만 남깁니다. 내부 working view에는 escalation owner, 민감한 blocker note, 내부 리스크 판단, 다음 분기 follow-up을 남깁니다.
| view | 포함할 내용 |
|---|---|
| customer shared view | 고객 owner 확인, open action, 다음 일정, 고객에게 필요한 요청 |
| internal working view | 내부 owner, escalation note, 민감 메모, data confidence |
| executive view | decision needed, blocker owner, due date, impact summary |
고객에게 보여줄 수 없는 메모가 섞여 있다면 readiness board 자체를 공유하면 안 됩니다. 공유 가능한 summary를 따로 만들고, 원본 board는 내부 권한으로 유지합니다.
readiness risk reason은 일정별로 달라야 합니다
90일 전 risk reason과 30일 전 risk reason은 의미가 다릅니다. 90일 전에는 unknown이 허용 가능한 확인 대상일 수 있지만, 30일 전에도 unknown이면 blocker가 됩니다.
| risk reason | 90일 전 | 60일 전 | 30일 전 |
|---|---|---|---|
| champion_changed | 새 owner 확인 task 생성 | onboarding action 확인 | executive summary에 risk로 표시 |
| procurement_owner_unknown | 역할 확인 | PO/process 확인 | escalation 필요 여부 결정 |
| billing_contact_stale | contact 확인 | invoice owner 재확인 | billing blocker로 표시 |
| security_exception_open | owner 확인 | due date 확인 | renewal 전 필수 여부 결정 |
| support_blocker_open | blocker type 분류 | customer/internal waiting 분리 | close/rollover 결정 |
| account_mapping_unknown | 데이터 연결 점검 | 리포트 수정 | readiness confidence 낮음 표시 |
risk reason은 고객을 평가하기 위한 점수가 아닙니다. 내부팀이 먼저 움직일 순서를 정하는 운영 신호입니다.
바로 쓰는 enterprise renewal 90/60/30 readiness 체크리스트
- CRM company, product workspace, billing customer, support organization, security review record가 같은 account를 가리키는가.
- QBR action item이 readiness board로 옮겨졌는가.
- champion, business owner, procurement owner, billing contact, security owner, executive sponsor의 최신성 상태가 있는가.
- 90일 전 unknown 역할마다 확인 task와 internal owner가 있는가.
- 60일 전 subscription status, invoice owner, billing contact, PO status가 분리돼 있는가.
- 60일 전 SSO, SCIM, audit log, data request, vendor review open item에 owner와 due date가 있는가.
- support blocker가 customer waiting인지 internal waiting인지 나뉘었는가.
- 30일 전 open action을 close, customer follow-up, internal follow-up, executive review, post-renewal action으로 분류했는가.
- executive summary가 usage/readiness, blocker, decision/action 세 줄로 정리되는가.
- customer shared view와 internal working view를 분리했는가.
- 30일 전에도 unknown인 항목을 green으로 처리하지 않았는가.
- renewal 이후로 넘길 action에도 owner와 due date가 있는가.
마무리
B2B SaaS enterprise renewal 90/60/30 readiness의 목적은 갱신 압박 문구를 만드는 것이 아닙니다. QBR action, stakeholder map, billing blocker, security exception, support blocker를 일정별로 나눠 갱신일 전에 운영 공백을 줄이는 것입니다.
처음부터 복잡한 renewal machine을 만들 필요는 없습니다. 90일 전에는 account identity와 stakeholder map, 60일 전에는 billing·security·support blocker, 30일 전에는 open action decision과 executive summary만 안정적으로 관리해도 renewal review의 품질은 크게 올라갑니다. 중요한 것은 "누가 무엇을 언제까지 확인해야 하는가"를 고객 공유 view와 내부 working view로 나누는 것입니다.
갱신 완료 이후에는 B2B SaaS post-renewal handoff 체크리스트로 plan access, billing contact, success plan, support blocker를 다음 분기 운영으로 넘기기 전 다시 확인할 수 있습니다.
공식 출처
- HubSpot Knowledge Base – Create tasks
- Salesforce Help – Create a Report
- Stripe Docs – Subscriptions overview
- Stripe Docs – Invoicing overview
- Microsoft Learn – Sign-in logs in Microsoft Entra ID
- Microsoft Learn – Audit logs in Microsoft Entra ID
- Zendesk Developer Docs – Tickets API
- GitHub Docs – About Projects
About The Author
