B2B SaaS renewal exception follow-up 체크리스트 2026, discount exception·security exception·billing exception을 next QBR 전에 닫기 전 확인할 기준
B2B SaaS renewal exception follow-up 체크리스트 2026, discount exception·security exception·billing exception을 next QBR 전에 닫기 전 확인할 기준
B2B SaaS renewal이 끝났다고 해서 모든 예외가 닫힌 것은 아닙니다. discount exception, security exception, billing exception, support blocker가 "갱신 후 follow-up"으로 남아 있으면 다음 QBR에서 같은 문제가 다시 열립니다. 계약은 갱신됐지만 운영팀은 아직 무엇을 닫았고, 무엇을 보류했고, 무엇을 다음 분기 리스크로 넘겼는지 알지 못하는 상태가 됩니다.
이 글은 가격 협상, 계약 해석, 법률 검토, 세무 처리, 회계 처리, 투자 판단에 대한 조언이 아닙니다. customer success, RevOps, support ops, billing ops, security ops가 renewal 이후 남은 exception을 next QBR 전에 운영 문서와 task로 닫기 위한 체크리스트입니다.
직전 단계인 B2B SaaS post-renewal 30-day adoption review 체크리스트는 갱신 후 첫 30일 사용량, support blocker, billing issue를 확인했습니다. 이번 글은 그 점검에서 남은 exception을 close, monitor, QBR agenda, escalation으로 나누는 흐름입니다. 갱신 전 준비는 B2B SaaS enterprise renewal 90/60/30 readiness 체크리스트와 연결하고, 이해관계자 변경은 B2B SaaS renewal stakeholder map 체크리스트와 함께 보면 됩니다.
renewal exception follow-up은 예외를 없애는 일이 아니라 책임을 닫는 일입니다
renewal exception follow-up의 목적은 모든 예외를 무조건 해결했다고 쓰는 것이 아닙니다. 어떤 예외가 승인됐고, 어떤 예외가 만료됐고, 어떤 예외가 다음 분기 리스크로 남았고, 누가 언제 다시 확인해야 하는지 명확히 남기는 것입니다.
| exception 유형 | follow-up 질문 |
|---|---|
| discount exception | 예외 할인, promo, custom term이 다음 renewal 또는 invoice에 어떤 상태로 남는가 |
| security exception | security questionnaire, audit log, access review, data retention 예외가 owner와 review date를 갖고 있는가 |
| billing exception | invoice owner, PO, payment state, credit note, dunning risk가 고객 운영을 막지 않는가 |
| support exception | renewal 전에 약속한 blocker가 close, monitor, escalation 중 어디에 있는가 |
| access exception | admin role, SSO, SCIM, entitlement, temporary flag가 정리됐는가 |
| stakeholder exception | champion, procurement owner, security owner, billing contact 변경이 반영됐는가 |
| QBR exception | next QBR에서 결정해야 할 항목과 이미 닫을 항목이 분리됐는가 |
예외 관리는 깔끔한 표를 만드는 일이 아니라 계정 운영의 불확실성을 줄이는 일입니다. "누가 알고 있는가"보다 "어느 시스템에 남아 있고, 다음 action이 무엇인가"가 더 중요합니다.
1. exception register를 renewal 단위로 고정합니다
먼저 exception register의 기준을 고정합니다. 한 고객이 여러 workspace, subscription, billing account, support organization을 갖고 있으면 예외가 흩어집니다. renewal 단위로 register를 만들고 CRM account, subscription, support org, product workspace ID를 함께 남깁니다.
출처: Salesforce Help – Create a Report
출처: HubSpot Knowledge Base – Create and manage tasks
| 필드 | 운영 기준 |
|---|---|
account_id |
CRM account 또는 customer success system 기준 ID |
renewal_id |
opportunity, subscription renewal, contract renewal 중 내부 기준 |
exception_type |
discount, security, billing, support, access, stakeholder, QBR |
source_system |
CRM, billing, support, product, identity, project tool |
owner |
내부 follow-up 책임자 |
customer_owner |
고객 쪽 확인 담당자 |
due_date |
next QBR 전 닫아야 할 기준일 |
status |
open, pending_customer, pending_internal, accepted, expired, closed |
register는 고객에게 그대로 공유하는 문서가 아닙니다. 고객 공유본은 action과 due date 중심으로 줄이고, 내부본에는 source system, ID, owner, sensitive note 위치를 남깁니다.
2. discount exception은 가격 결론이 아니라 만료 조건을 남깁니다
discount exception은 민감합니다. 운영 문서에서 가격 협상이나 계약 해석을 대신하면 안 됩니다. follow-up에서 확인할 것은 예외 할인의 존재, 만료일, 다음 invoice 또는 다음 renewal에 영향을 주는지, 담당 owner가 있는지입니다.
출처: Salesforce Help – Use Collaborative Forecasts
| discount follow-up | 확인 기준 |
|---|---|
| exception source | CRM, quote, billing note, approval task 중 원본 위치 |
| effective period | 이번 renewal에만 적용인지, 다음 invoice까지 이어지는지 |
| expiration date | 만료일 또는 next review date가 있는가 |
| renewal impact | 다음 renewal에서 자동 연장으로 오해될 여지가 있는가 |
| invoice note | billing team이 고객 문의에 답할 수 있는 요약이 있는가 |
| customer-visible summary | 고객에게 공유 가능한 문장과 내부 메모가 분리됐는가 |
"할인을 더 줘야 한다" 또는 "이 조건은 유리하다" 같은 판단은 이 문서의 범위가 아닙니다. 운영팀은 예외가 다음 workflow에 어떤 상태로 남는지만 추적합니다.
3. security exception은 evidence 위치와 review date를 남깁니다
security exception은 원본 evidence를 adoption review나 QBR 메모에 복사하기보다 evidence 위치, owner, review date를 남기는 편이 안전합니다. audit log, access review, SSO, SCIM, data retention, support access 예외는 보안팀 또는 지정 owner가 원본 시스템에서 관리해야 합니다.
출처: Microsoft Learn – Access reviews overview
출처: Microsoft Learn – Audit logs in Microsoft Entra ID
출처: GitHub Docs – About the audit log for your enterprise
| security 항목 | follow-up 기준 |
|---|---|
| access review | owner, 대상 role, review date, completion status |
| audit log request | evidence location, export owner, customer-visible summary |
| SSO/SCIM exception | pending, blocked, not_requested, accepted risk 구분 |
| support access exception | impersonation reason, approval path, audit log 위치 |
| data retention exception | retention hold, deletion request, backup restore 요청과 연결 |
| security questionnaire item | accepted, needs_evidence, expired, next_review 구분 |
보안 예외를 고객에게 공유할 때는 "가능하다/불가능하다"를 단정하기보다 owner, evidence location, next date를 중심으로 씁니다. vendor review evidence 관리는 B2B SaaS security questionnaire·vendor review evidence 체크리스트와 연결하면 됩니다.
4. billing exception은 invoice 전에 닫을 항목과 QBR로 넘길 항목을 분리합니다
billing exception은 다음 invoice 전에 닫아야 할 항목과 next QBR에서 논의할 항목을 분리해야 합니다. PO 누락, billing email bounce, open invoice, failed payment, credit note, refund follow-up은 모두 같은 "결제 이슈"처럼 보이지만 owner와 deadline이 다릅니다.
출처: Stripe Docs – Invoicing overview
출처: Stripe Docs – Smart Retries
| billing 항목 | follow-up 기준 |
|---|---|
| invoice owner | confirmed, changed, unknown |
| billing email | active, bounced, shared mailbox, unknown |
| PO status | received, requested, missing, not_required |
| open invoice | customer action, internal action, no action 구분 |
| failed payment | dunning flow 상태와 CS handoff 여부 |
| credit note/refund | 원본 billing system link와 고객 공유 요약 분리 |
| QBR impact | 결제 이슈가 adoption, renewal risk, executive review에 영향을 주는가 |
결제 실패 자동화는 B2B SaaS 결제 실패·dunning 자동화 체크리스트와 연결하고, refund나 credit note가 churn report와 섞일 위험은 B2B SaaS 환불·크레딧·부분 취소 추적 감사 체크리스트로 분리합니다.
5. support exception은 약속, blocker, customer-visible update를 나눕니다
support exception은 renewal 당시 "이 문제는 갱신 후 처리하겠다"로 넘어간 항목입니다. 30일 뒤에도 owner가 없으면 고객은 같은 ticket을 QBR에서 다시 꺼냅니다. support follow-up은 약속한 action, 실제 blocker, 고객에게 공유할 update를 분리해야 합니다.
출처: Zendesk Developer Docs – Tickets API
| support 상태 | 처리 기준 |
|---|---|
| promised fix | renewal 전에 약속한 update와 실제 ticket 연결 |
| rollover blocker | next update due, internal owner, customer owner 지정 |
| reopened ticket | 이전 ticket과 재발 사유 연결 |
| customer waiting | 고객에게 요청한 자료와 due date 기록 |
| internal waiting | support, product, billing, security owner 구분 |
| customer-visible update | 고객에게 보낼 수 있는 짧은 상태 문장 |
ticket 전문을 QBR 문서에 붙이지 않습니다. 고객에게 공유 가능한 summary와 내부 triage note를 분리해야 합니다. support access가 들어간 경우 B2B SaaS support impersonation·customer access 감사 체크리스트로 넘깁니다.
6. access exception은 entitlement와 admin owner를 같이 확인합니다
access exception은 단순 권한 문제가 아니라 renewal value와 adoption report를 동시에 흔들 수 있습니다. temporary feature flag가 남아 있거나, SSO/SCIM role mapping이 늦게 반영되거나, billing admin과 product admin이 다르면 next QBR에서 "누가 접근할 수 있는가"부터 다시 확인하게 됩니다.
| access 항목 | follow-up 기준 |
|---|---|
| product entitlement | plan, seat limit, feature access가 billing 상태와 맞는가 |
| temporary flag | trial, pilot, exception flag가 만료됐거나 owner를 갖고 있는가 |
| admin owner | primary admin, billing admin, security admin이 최신인가 |
| SSO/SCIM | configured, pending, blocked, not requested 상태 구분 |
| role mapping | IdP group, app role, workspace permission이 충돌하지 않는가 |
| access complaint | 고객 문의와 실제 권한 상태가 연결됐는가 |
entitlement와 feature flag는 B2B SaaS entitlement·feature flag 변경 추적 감사 체크리스트와 함께 확인하면 좋습니다. SSO와 SCIM은 B2B SaaS enterprise SSO·SCIM 권한 동기화 체크리스트와 연결합니다.
7. stakeholder exception은 champion 변경과 billing/security owner 변경을 분리합니다
renewal 이후 stakeholder가 바뀌면 exception follow-up이 끊깁니다. champion은 adoption action을 알고 있지만 billing contact는 invoice만 보고, security owner는 evidence만 보며, procurement owner는 다음 renewal calendar만 볼 수 있습니다. 같은 고객 안에서도 owner별로 follow-up 문장이 달라야 합니다.
| stakeholder | 확인 질문 |
|---|---|
| champion | adoption action과 QBR agenda를 알고 있는가 |
| executive sponsor | decision item만 받을 수 있게 요약됐는가 |
| procurement owner | discount exception과 next renewal condition을 추적하는가 |
| billing contact | invoice owner, PO, payment state를 확인할 수 있는가 |
| security owner | evidence location과 review date를 확인했는가 |
| admin owner | access, SSO, SCIM, entitlement follow-up을 받을 수 있는가 |
stakeholder map이 없으면 exception register가 내부 메모로만 남습니다. 고객 쪽 owner를 업데이트하고, 확인이 필요한 항목은 task로 분리합니다.
8. next QBR에는 닫힌 예외가 아니라 남은 결정만 올립니다
next QBR에 모든 exception을 올리면 회의가 정리되지 않습니다. 닫힌 예외는 close log에 남기고, monitor 항목은 owner follow-up으로 보내고, 고객 의사결정이 필요한 항목만 QBR agenda에 올립니다.
| 분류 | QBR 처리 |
|---|---|
| closed | QBR에는 올리지 않고 renewal exception log에 남김 |
| accepted | accepted risk 또는 accepted exception으로 review date만 남김 |
| monitor | owner와 next check date만 남김 |
| owner follow-up | QBR 전 고객 또는 내부 owner가 확인할 task로 분리 |
| QBR agenda | 고객 decision, executive alignment, stakeholder change가 필요한 항목 |
| escalation | adoption, billing, support, security blocker가 renewal value 설명을 막는 항목 |
QBR 문장은 "discount exception 있음"보다 "다음 renewal 전에 custom discount 만료 조건을 procurement owner와 확인해야 함"처럼 decision-ready 형태가 좋습니다. customer success review 흐름은 B2B SaaS customer success QBR renewal review 체크리스트와 연결합니다.
바로 쓰는 renewal exception follow-up 체크리스트
- renewal 단위 exception register가 있고 CRM, billing, support, product ID가 연결돼 있는가.
- exception type이 discount, security, billing, support, access, stakeholder, QBR로 분류됐는가.
- 각 exception에 내부 owner, 고객 owner, due date, source system이 있는가.
- discount exception은 가격 판단이 아니라 만료일, 원본 위치, 다음 invoice 또는 renewal 영향만 기록됐는가.
- security exception은 원본 evidence가 아니라 evidence location, owner, review date가 남아 있는가.
- billing exception은 next invoice 전에 닫을 항목과 QBR로 넘길 항목이 분리됐는가.
- failed payment, PO, open invoice, credit note, refund follow-up은 각각 owner와 customer-visible summary를 갖고 있는가.
- support exception은 promised fix, rollover blocker, reopened ticket, customer-visible update로 나뉘었는가.
- access exception은 entitlement, feature flag, admin role, SSO/SCIM 상태와 연결됐는가.
- stakeholder exception은 champion, procurement owner, billing contact, security owner, admin owner별로 분리됐는가.
- 고객 공유본에는 내부 가격 전략, 민감 support note, 보안 원본 evidence가 섞이지 않았는가.
- closed, accepted, monitor, owner follow-up, QBR agenda, escalation이 분리됐는가.
- next QBR agenda에는 고객 결정이 필요한 항목만 decision-ready 문장으로 올라갔는가.
- 예외가 만료되는 날짜와 다음 review date가 task 또는 calendar에 남아 있는가.
- 다음 renewal readiness 문서에서 같은 exception이 반복되지 않도록 source field가 업데이트됐는가.
마무리
B2B SaaS renewal exception follow-up은 갱신 후 남은 일을 "나중에 확인"으로 밀어두지 않기 위한 운영 장치입니다. discount, security, billing, support, access 예외가 각각 owner와 due date를 갖고 닫히면 next QBR은 예외를 다시 설명하는 시간이 아니라 다음 분기 결정을 정리하는 시간이 됩니다.
작게 시작하려면 5개만 보면 됩니다. discount exception의 만료 조건, security exception의 evidence location, billing exception의 next invoice 영향, support exception의 customer-visible update, QBR agenda로 넘길 decision item입니다. 이 5개가 renewal 단위로 정리되면 고객 성공팀과 운영팀은 같은 계정을 같은 기준으로 볼 수 있습니다.
공식 출처
- Salesforce Help – Create a Report
- HubSpot Knowledge Base – Create and manage tasks
- Salesforce Help – Use Collaborative Forecasts
- Microsoft Learn – Access reviews overview
- Microsoft Learn – Audit logs in Microsoft Entra ID
- GitHub Docs – About the audit log for your enterprise
- Stripe Docs – Invoicing overview
- Stripe Docs – Smart Retries
- Zendesk Developer Docs – Tickets API
About The Author
