Files
company-haness/org-os/00-role-registry/role-working-methods/gtm-operations.yaml
T

733 lines
46 KiB
YAML
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# gtm-operations.yaml — role-working-methods 파일분리(P3). 내용 불변(v1). Contract v2는 wave에서 additive.
role-working-methods:
OPS-CH:
# Contract v2(P3-B) — draft. 지원 운영: SOP 소비 → 티켓 트리아지·FCR → support-resolution → GTM-CS(VoC).
method-contract: { version: 2 }
role-boundary:
owns: [문의 트리아지·라우팅, FCR·SLA 응대, 지식화·VoC 회수]
not-owns: [프로세스 표준 원설계(-> OPS-CREW), 고객 성공·확장(-> GTM-CS), 제품 결정(-> PROD-PM)]
methods:
- method-id: support-operations
applies-when: { task-types: [support, ticketing, incident-triage] }
required-inputs:
- { artifact-type: process-improvement, from-role: OPS-CREW, from-method: operations-improvement, optional: true }
workflow:
- step-id: triage-route
objective: 문의 접수·로깅 + impact-urgency 우선순위 + 스킬/워크로드 기반 라우팅
required-output: triaged-tickets
- step-id: resolve-voc
objective: FCR 시도·에스컬레이션 + 해결 티켓 지식화 + 반복 불만을 VoC 로 회수 후 support-resolution
required-output: support-resolution
completion-gates:
judgment:
- { gate-id: fcr-tracked, criterion: FCR·SLA 준수가 추적되고 VoC 가 회수됨, reviewer-role: OPS-CH }
decision-rules:
- SLA 위반 위험 시 상위 티어로 에스컬레이션(동적 SLA 재산정)
evidence-policy:
- 지원은 FCR·SLA 준수·CSAT 지표에 접지
output-artifacts: [support-resolution]
handoff-contract:
- edge-id: support-to-cs
to: { role-id: GTM-CS, method-id: customer-success }
artifact-type: support-resolution
required-state: Accepted
binding: same-workflow
freshness: current-usable
cardinality: "1:N"
self-check:
- FCR·SLA·VoC 를 추적했는가
working-method:
- '문의 접수·로깅: 셀프서비스 포털/챗/이메일 등 구조화된 채널로 문의를 받고 맥락(고객 티어·영향 서비스)을 초기에 수집한다.'
- '분류·우선순위 판정: 서비스 카탈로그로 카테고리화하고 impact-urgency 매트릭스로 우선순위를 자동/수동 산정한다.'
- '라우팅·배정: round-robin / 워크로드 기반 / 스킬 기반 배정으로 가장 적합한 상담원·팀에 티켓을 보낸다.'
- '1차 응대·FCR 시도: 첫 접촉에서 해결(First Contact Resolution)을 목표로 응대하고 지식베이스를 활용한다.'
- '에스컬레이션: 1차 해결 실패나 SLA 위반 위험 시 상위 티어/전문팀으로 이관한다(동적 SLA 재산정).'
- '해결 후 지식화·VoC 회수: 해결 티켓을 지식베이스 기사로 전환하고, 반복 문의·불만 신호를 제품팀에 VoC로 전달한다.'
key-frameworks:
- ITIL Incident Management(트리아지 중심 서비스관리)
- Impact-Urgency Matrix(영향×긴급도 우선순위)
- First Contact Resolution(FCR)
- SLA/OLA(응답·해결 시간 약정), 동적 SLA
- Knowledge-Centered Service(KCS, 지식베이스 순환)
- Ticket Triage(로깅→분류→배정→워크플로→에스컬레이션 5단계)
evidence-they-use:
- 상담 처리시간(MTTR/AHT), 재문의율
- First Contact Resolution율, SLA 준수율(브리치율)
- CSAT / NPS / CES(고객 만족·노력 지표)
- VoC(고객의 소리)·이탈/불만 신호, 티켓 카테고리 분포
sources:
- https://blog.invgate.com/ticket-triage
- https://www.supportbench.com/support-queue-strategy-triage-routing-ownership/
- https://www.featurebase.app/blog/ticket-escalation
OPS-CREW:
# Contract v2(P3-B) — draft. 운영 개선 소스: VSM·SOP·kaizen → process-improvement → OPS-CH.
method-contract: { version: 2 }
role-boundary:
owns: [현행 프로세스 VSM 매핑, 7대 낭비 식별·SOP 표준화, future-state 설계·자동화 요구]
not-owns: [지원 티켓 운영(-> OPS-CH), 내부도구 구현(-> ENG-*), 제품 결정(-> PROD-PM)]
methods:
- method-id: operations-improvement
applies-when: { task-types: [process-improvement, value-stream, sop] }
workflow:
- step-id: map-current
objective: 대상 운영 흐름을 current-state VSM 으로 그리고 7대 낭비(DOWNTIME)·수작업 지점 식별
required-output: current-state-map
- step-id: design-future
objective: waste 제거 future-state 설계 + SOP 표준화 + cycle/lead time·실수율 KPI 후 process-improvement
required-output: process-improvement
completion-gates:
judgment:
- { gate-id: waste-removed, criterion: 낭비가 제거된 future-state 와 SOP 가 KPI 로 검증됨, reviewer-role: OPS-CREW }
decision-rules:
- 정책-현장 간극을 예외/수작업 로그로 근거화(추측 금지)
evidence-policy:
- 개선은 cycle/lead time·실수율·자동화율에 접지
output-artifacts: [process-improvement]
handoff-contract:
- edge-id: process-to-support
to: { role-id: OPS-CH, method-id: support-operations }
artifact-type: process-improvement
required-state: Accepted
binding: same-workflow
freshness: current-usable
cardinality: "1:N"
self-check:
- 낭비 제거·SOP 를 KPI 로 검증했는가
working-method:
- '현행 프로세스 매핑: 대상 운영 흐름(파일 처리·이메일 발송·권한/패스워드 처리 등)을 이해관계자와 함께 current-state로 그린다.'
- '낭비·병목 식별: 지연·병목·과잉처리·불필요 이동 등 7대 낭비(DOWNTIME)와 수작업·예외 지점을 표시한다.'
- '표준작업(SOP) 정의: 사람/사이트마다 다른 처리 방식을 표준 SOP로 통일해 훈련·품질 편차를 줄인다.'
- '미래상태 설계·자동화 요구 도출: waste를 제거한 future-state를 설계하고 내부 도구/자동화 개선 요구를 제품·디자인·개발팀에 전달한다.'
- '개선 실행·KPI 모니터링: 변경을 적용하고 cycle/lead time·실수율을 추적하며 kaizen으로 반복 개선한다.'
- '정책-현장 간극 노출: 제품 정책과 실제 운영 사이의 예외/수작업 로그를 근거로 간극을 드러낸다.'
key-frameworks:
- Value Stream Mapping(VSM, current→future state)
- Lean 7 wastes(DOWNTIME), 가치/비가치 활동 구분
- Kaizen(지속 개선), PDCA
- SOP 표준작업(standard work)
- Kanban / Just-in-Time(JIT), Heijunka·Jidoka(린 오피스)
evidence-they-use:
- Cycle time(단계 처리시간), Lead time(총 소요시간)
- 운영 처리시간·실수율(에러율), 재작업률
- 병목 위치·대기 시간, value-stream-map current/future
- 수작업·운영 예외 로그, 자동화율
sources:
- https://www.planview.com/resources/guide/what-is-value-stream-mapping/
- https://en.wikipedia.org/wiki/Value-stream_mapping
- https://www.systems2win.com/solutions/LeanOffice.htm
GTM-GROWTHPM:
role-name: Growth PM / Growth Lead
# Contract v2(P3-B) — draft. GTM 소스: AARRR·성장루프·PLG → growth-loop → SALES(PLS handoff).
method-contract: { version: 2 }
role-boundary:
owns: [AARRR 퍼널 병목 특정, North Star+카운터지표, 성장실험·성장루프·PLG/PLS handoff]
not-owns: [수요 창출 실행(-> GTM-DEMANDGEN), 딜 종결(-> GTM-SALES), 제품 discovery(-> PROD-PM)]
methods:
- method-id: growth
applies-when: { task-types: [growth, plg, activation] }
required-inputs:
- { artifact-type: metrics-analysis, from-role: DATA-ANALYST, from-method: metrics-analysis, optional: true }
workflow:
- step-id: find-bottleneck
objective: AARRR 퍼널을 이벤트/코호트로 계측해 진짜 병목 1개 특정 + North Star+카운터지표 정의
required-output: growth-diagnosis
- step-id: experiment-loop
objective: ICE/RICE 실험 우선순위 + 성장루프 설계 + PQL/PLS handoff threshold 후 growth-loop
required-output: growth-loop
completion-gates:
judgment:
- { gate-id: statistically-valid, criterion: 유의한 실험 결과만 채택되고 병목이 지표로 특정됨, reviewer-role: GTM-GROWTHPM }
decision-rules:
- 통계적으로 유의한 결과만 채택(허무지표 배격)
alternatives-policy: { min-alternatives: 2 }
evidence-policy:
- 성장은 코호트 리텐션·A/B 유의성·TTV 에 접지(E4)
output-artifacts: [growth-loop]
handoff-contract:
- edge-id: growth-to-sales
to: { role-id: GTM-SALES, method-id: sales }
artifact-type: growth-loop
required-state: Accepted
binding: same-workflow
freshness: current-usable
cardinality: "1:N"
self-check:
- 병목을 지표로 특정하고 유의성으로 채택했는가
working-method:
- AARRR(획득-활성화-리텐션-수익-추천) 퍼널을 이벤트/코호트로 계측해 진짜 병목 1개를 특정한다(활성화 약하면 first-value 전달, 리텐션 불안정이면 확산 중단).
- North Star Metric을 사용자 가치×사업 건전성으로 정의하고, 어뷰징 방지용 카운터 지표(리텐션 품질·CAC·지원부담·churn)를 짝지운다.
- 성장 실험을 ICE/RICE(Impact·Confidence·Ease)로 우선순위화하고 Core최적화/Adjacent확장/New가치 3버킷 포트폴리오로 배분한다.
- 아하 모먼트를 실증적으로 정의하고 Time-to-Value(TTV)를 계측해 온보딩을 오직 아하 도달 가속만을 위해 재설계한다.
- 퍼널이 아닌 성장 루프(공유가 사용자 job을 완성하는 구조)를 설계해 PLG 셀프서비스 전환·리텐션을 복리화한다.
- A/B 실험 → 통계적으로 유의한 결과만 채택 → PQL/PLS 이관 트리거(handoff threshold)로 세일즈에 넘긴다.
key-frameworks:
- AARRR(Pirate Metrics, Dave McClure)
- ICE / RICE 실험 우선순위
- North Star Metric + Counter-metrics
- PLG(Product-Led Growth) / PLS(Product-Led Sales) 루프
- Time-to-Value / Aha Moment / Activation
- Growth Loops vs Funnel
evidence-they-use:
- 퍼널 단계별 전환율·드롭오프, 코호트 리텐션 커브
- A/B 실험 결과(유의성·리프트), 실험 로그
- TTV 중앙값, 활성화율, 기능 채택률, PQL 수
- North Star + 카운터 지표 대시보드
sources:
- https://www.aakashg.com/what-are-the-growth-strategies/
- https://www.productled.org/foundations/product-led-growth-metrics
- https://www.parallelhq.com/blog/what-growth-product-manager
- https://umbrex.com/resources/frameworks/strategy-frameworks/aarrr-pirate-metrics-funnel/
GTM-DEMANDGEN:
role-name: Demand Generation
# Contract v2(P3-B) — draft. positioning 소비 → ABM·ICP·수요창출 → demand-pipeline → SALES·REVOPS.
method-contract: { version: 2 }
role-boundary:
owns: [ICP 정의·fit×intent 스코어링, ABM 계정 계층화·멀티채널 오케스트레이션, 계정단위 파이프라인 기여]
not-owns: [포지셔닝(-> GTM-PMM), 딜 종결(-> GTM-SALES), 매출 예측 SSOT(-> GTM-REVOPS)]
methods:
- method-id: demand-generation
applies-when: { task-types: [demand-gen, abm, campaign] }
required-inputs:
- { artifact-type: positioning, from-role: GTM-PMM, from-method: product-marketing, required-state: Accepted }
workflow:
- step-id: define-target
objective: ICP(firmographic·technographic·intent) 정의 + fit×intent 스코어링으로 Tier1/2/3 계층화
required-output: target-accounts
- step-id: orchestrate-pipeline
objective: 멀티채널 ABM 오케스트레이션 + 세일즈 SLA 리드 이관 + 계정단위 기여 측정 후 demand-pipeline
required-output: demand-pipeline
completion-gates:
judgment:
- { gate-id: account-attributed, criterion: 성과가 허무지표 아닌 계정단위 파이프라인 기여로 측정됨, reviewer-role: GTM-DEMANDGEN }
decision-rules:
- 노출 같은 허무지표 배격 — 계정단위 소싱/영향 파이프라인으로 측정
evidence-policy:
- 수요는 소싱 파이프라인·ROAS·타겟 윈레이트 리프트에 접지
output-artifacts: [demand-pipeline]
handoff-contract:
- edge-id: demandgen-to-sales
to: { role-id: GTM-SALES, method-id: sales }
artifact-type: demand-pipeline
required-state: Accepted
binding: same-workflow
freshness: current-usable
cardinality: "1:N"
- edge-id: demandgen-to-revops
to: { role-id: GTM-REVOPS, method-id: revenue-operations }
artifact-type: demand-pipeline
required-state: Accepted
binding: same-workflow
freshness: current-usable
cardinality: "1:1"
self-check:
- 성과를 계정단위 기여로 측정했는가
working-method:
- ICP를 firmographic(산업·매출·규모)·technographic(스택)·intent(리서치 행동)로 정의하고 최우량 고객 패턴(최고 LTV·최단 클로징·최다 확장)에서 역산한다.
- fit×intent 스코어링으로 타겟 계정을 Tier1(5~20, 풀커스텀)/Tier2(20~200, 반커스텀)/Tier3(200+, 프로그래매틱)으로 계층화한다.
- 'ABM 오케스트레이션: LinkedIn/디스플레이 광고 + 역할별 이메일 시퀀스 + 임원 이벤트를 동일 타이밍으로 멀티채널 조율하고 바잉커미티(14+ 이해관계자)를 매핑한다.'
- SEO/AEO 콘텐츠·커뮤니티·아웃바운드 시퀀스로 유입을 만들고 세일즈와 SLA(누가 언제 액션)로 리드 이관을 계약한다.
- '허무지표(노출) 대신 계정단위 기여로 성과 측정: 타겟계정 소싱/영향 파이프라인, 타겟 vs 비타겟 윈레이트, 프로그램 소싱 ACV, ROAS.'
- 자율형 마케팅 워크플로우로 프로세스 대부분을 자동화하고, 인간은 브랜딩·메시지 정합에 집중한다.
key-frameworks:
- ABM(Account-Based Marketing) / ABX
- ICP(Ideal Customer Profile) 정의
- Intent Data + Fit Scoring
- Account Tiering(1:1 / 1:few / 1:many)
- Multi-touch Attribution / Pipeline Marketing
- SEO/AEO(Answer Engine Optimization)
evidence-they-use:
- 신규 창출/영향 파이프라인 규모, 마케팅 소싱 매출
- 계정 engagement 스코어, intent 신호, 콘텐츠 소비
- ROAS(광고비 회수), 타겟 계정 윈레이트 리프트, 검색 점유율
- 세일즈 SLA 준수·리드 이관 리드타임
sources:
- https://pipeline.zoominfo.com/marketing/abm-strategy-playbook-guide
- https://twelverays.agency/blog/demand-generation-best-practices
- https://abmatic.ai/blog/what-is-demand-generation-vs-abm
- https://mountain.com/blog/account-based-marketing-vs-demand-generation/
GTM-PMM:
role-name: Product Marketing Manager
# Contract v2(P3-B) — draft. competitive-intel 소비 → 포지셔닝·메시징 → positioning → DEMANDGEN·SALES.
method-contract: { version: 2 }
role-boundary:
owns: [April Dunford 포지셔닝, 메시징 하우스·가치제안, GTM 런치·세일즈 인에이블먼트]
not-owns: [경쟁 인텔 수집(-> GTM-CI), 수요 창출 실행(-> GTM-DEMANDGEN), 딜 종결(-> GTM-SALES)]
methods:
- method-id: product-marketing
applies-when: { task-types: [positioning, messaging, gtm-launch] }
required-inputs:
- { artifact-type: competitive-intel, from-role: GTM-CI, from-method: competitive-intelligence, required-state: Accepted }
workflow:
- step-id: position
objective: 경쟁대안→차별속성→고객가치→타겟세그먼트→시장카테고리 6단계 포지셔닝(April Dunford)
required-output: positioning-statement
- step-id: message-enable
objective: 포지셔닝/메시징 분리 + 메시징 하우스 + 배틀카드·세일즈 인에이블먼트 후 positioning
required-output: positioning
completion-gates:
judgment:
- { gate-id: positioning-differentiated, criterion: 포지셔닝이 경쟁대안 대비 차별속성→가치로 접지됨, reviewer-role: GTM-PMM }
decision-rules:
- 포지셔닝(전략)과 메시징(커뮤니케이션)을 분리
evidence-policy:
- 포지셔닝은 competitive-intel·메시지 A/B 에 접지
output-artifacts: [positioning]
handoff-contract:
- edge-id: pmm-to-demandgen
to: { role-id: GTM-DEMANDGEN, method-id: demand-generation }
artifact-type: positioning
required-state: Accepted
binding: same-workflow
freshness: current-usable
cardinality: "1:N"
- edge-id: pmm-to-sales
to: { role-id: GTM-SALES, method-id: sales }
artifact-type: positioning
required-state: Accepted
binding: same-workflow
freshness: current-usable
cardinality: "1:N"
self-check:
- 포지셔닝이 차별속성→가치로 접지됐는가
working-method:
- 'April Dunford 포지셔닝 절차: (1)역사적 디폴트 시장관 버리기 (2)경쟁대안 나열 (3)차별적 속성 식별 (4)속성→고객가치 번역 (5)그 가치를 진짜로 원하는 타겟세그먼트 지정 (6)가치가 자명해지는 시장 카테고리(frame) 선택.'
- 포지셔닝(전략 기반)과 메시징(고객별 커뮤니케이션)을 분리하고, 태그라인+3대 가치제안+핵심 기능 화법으로 메시징 하우스를 문서화한다.
- 타겟 페르소나 정의·차별화 메시징·랜딩/내러티브 검토와 GTM 출시(런치) 플레이북을 지휘한다.
- 셀프서비스 사용자를 엔터프라이즈 챔피언으로 전환시키는 챔피언 활성화 자산과 영업 협상용 배틀카드/세일즈 인에이블먼트를 배포한다.
- Growth PM과 인앱 가치 사전전달 캠페인을 설계하고, 브랜드 톤 학습 기반 생성형 AI로 카피 제작을 가속한다.
key-frameworks:
- April Dunford 5(+1) 포지셔닝 요소(경쟁대안·차별속성·가치·타겟·시장카테고리)
- Positioning vs Messaging vs Copywriting 분리
- Messaging House / Value Proposition
- GTM Launch Tiering, Sales Enablement / Battlecards
- Persona / Segmentation
evidence-they-use:
- 포지셔닝·메시징 문서, 내러티브, GTM one-pager
- MQL→SQL 전환 가치, 메시지 A/B(랜딩 CVR)
- 경쟁 정보(GTM-CI 배틀카드), 출시 일정 준수율
- 세일즈 자료 도달률·채택률 KPI
sources:
- https://www.aprildunford.com/post/a-product-positioning-exercise
- https://www.getproductpeople.com/blog/product-marketing-management-positioning-gtm
- https://wynter.com/post/messaging-builds-gtm-strategy
- https://www.lennyspodcast.com/blog/summary-april-dunford-on-product-positioning-segmentation-and-optimizing-your-sales-process/
GTM-CI:
role-name: Competitive Intelligence
# Contract v2(P3-B) — draft. GTM 소스: 경쟁 시그널·win/loss → competitive-intel → PMM·SALES.
method-contract: { version: 2 }
role-boundary:
owns: [경쟁 시그널 상시 수집, Win/Loss 인터뷰, 배틀카드·objection handling]
not-owns: [포지셔닝 확정(-> GTM-PMM), 딜 종결(-> GTM-SALES), 제품 로드맵(-> PROD-PM)]
methods:
- method-id: competitive-intelligence
applies-when: { task-types: [competitive-intel, win-loss, battlecard] }
workflow:
- step-id: collect-signals
objective: 경쟁사 웹/가격/릴리즈/채용/광고 모니터링 + 현장 세일즈 인텔 정형화
required-output: competitive-signals
- step-id: winloss-battlecard
objective: Win/Loss 인터뷰(양측) + 경쟁사별 윈레이트·반론을 CRM 결합해 동적 배틀카드 후 competitive-intel
required-output: competitive-intel
completion-gates:
judgment:
- { gate-id: winloss-grounded, criterion: 배틀카드가 실제 win/loss·CRM 데이터에 접지되고 정기 갱신됨, reviewer-role: GTM-CI }
decision-rules:
- 배틀카드는 정적 PDF 아닌 월 1회+ 갱신 동적 문서
evidence-policy:
- 경쟁 인텔은 win/loss 로그·CRM 딜 메타데이터에 접지
output-artifacts: [competitive-intel]
handoff-contract:
- edge-id: ci-to-pmm
to: { role-id: GTM-PMM, method-id: product-marketing }
artifact-type: competitive-intel
required-state: Accepted
binding: same-workflow
freshness: current-usable
cardinality: "1:N"
- edge-id: ci-to-sales
to: { role-id: GTM-SALES, method-id: sales }
artifact-type: competitive-intel
required-state: Accepted
binding: same-workflow
freshness: current-usable
cardinality: "1:N"
self-check:
- 배틀카드가 win/loss 에 접지·갱신됐는가
working-method:
- '경쟁사 시그널 상시 수집: 웹사이트/가격 변경/릴리즈 노트/채용/광고를 수백 소스로 모니터링하고 현장 세일즈 인텔(Slack/이메일)을 정형화한다.'
- Win/Loss 인터뷰를 전담해 바이어·셀러 양측에서 왜 이기고 지는지 객관 피드백을 수집한다(포지셔닝·가격 실패 케이스 포함).
- '배틀카드 구성: 경쟁사별 윈레이트 + 최근 승리 주석(먹힌 포지셔닝/가격전술) + 패배 케이스 + 반론(objection handling)을 CRM(Salesforce) 데이터와 결합.'
- 배틀카드를 정적 PDF가 아닌 동적 문서로 최소 월 1회 갱신하고 세일즈·PMM·제품·임원에게 배포한다.
- 제품팀엔 로드맵 영감, PMM엔 차별화 포지셔닝 보정을 배포하고, AI 답변엔진 내 자사 인지도(AI Search Intelligence) 인용 빈도를 제어한다.
key-frameworks:
- Battlecards(경쟁 enablement)
- Win/Loss Analysis
- Competitive Win-Rate 세분화(경쟁사·산업·딜규모)
- Objection Handling / Trap-setting
- AI Search Intelligence(AEO 브랜드 인용 제어)
evidence-they-use:
- 경쟁사별 윈레이트, 신규 경쟁위협 감지 리드타임
- Win/Loss 인터뷰 로그, CRM 딜 메타데이터
- 외부 웹 근거(evidence-ledger reliability-grade)
- AI 엔진 인용/추천 빈도
sources:
- https://klue.com/blog/competitive-battlecard-win-rate
- https://klue.com/win-loss
- https://www.kompyte.com/blog/top-competitive-intelligence-tools
- https://www.outreach.ai/resources/blog/win-loss-analysis
GTM-SALES:
role-name: Sales / Founder-led Sales
# Contract v2(P3-B) — draft. GTM 수렴: 포지셔닝·수요·거버넌스 소비 → MEDDPICC 딜 종결 → closed-deal → CS.
method-contract: { version: 2 }
role-boundary:
owns: [MEDDPICC 딜 자격검증, 챔피언 육성·multi-threading, 협상·딜 종결]
not-owns: [수요 창출(-> GTM-DEMANDGEN), 가격 정책(-> GTM-PRICING), 계약 리스크 판정(-> GTM-LEGAL)]
methods:
- method-id: sales
applies-when: { task-types: [sales, deal-closing, negotiation] }
required-inputs:
- { artifact-type: demand-pipeline, from-role: GTM-DEMANDGEN, from-method: demand-generation, required-state: Accepted }
- { artifact-type: positioning, from-role: GTM-PMM, from-method: product-marketing, required-state: Accepted }
- { artifact-type: revops-model, from-role: GTM-REVOPS, from-method: revenue-operations, required-state: Accepted }
- { artifact-type: pricing-guidance, from-role: GTM-PRICING, from-method: pricing, required-state: Accepted }
- { artifact-type: competitive-intel, from-role: GTM-CI, from-method: competitive-intelligence, optional: true }
- { artifact-type: growth-loop, from-role: GTM-GROWTHPM, from-method: growth, optional: true }
- { artifact-type: legal-review, from-role: GTM-LEGAL, from-method: legal, optional: true }
workflow:
- step-id: qualify-meddpicc
objective: MEDDPICC 로 딜 상시 자격검증(Metrics·Economic Buyer·Decision Criteria/Process·Champion·Competition)
required-output: qualified-deal
- step-id: negotiate-close
objective: 챔피언 육성·다자 구도 조율 + 가격조항·SLA 협상(pricing/legal 거버넌스 준수)으로 종결 후 closed-deal
required-output: closed-deal
completion-gates:
judgment:
- { gate-id: meddpicc-scored, criterion: 챔피언·이코노믹바이어가 확인되고 가격/법무 거버넌스를 준수함, reviewer-role: GTM-SALES }
decision-rules:
- 가격은 pricing 거버넌스, 계약은 legal 검토 경로로만(권한 외 특약 금지)
evidence-policy:
- 세일즈는 MEDDPICC 스코어·윈레이트·intent 신호에 접지
output-artifacts: [closed-deal]
handoff-contract:
- edge-id: sales-to-cs
to: { role-id: GTM-CS, method-id: customer-success }
artifact-type: closed-deal
required-state: Accepted
binding: same-workflow
freshness: current-usable
cardinality: "1:1"
prohibited-shortcuts:
- 권한 외 가격·계약 특약(거버넌스 우회)
self-check:
- MEDDPICC 자격검증과 거버넌스 준수를 확인했는가
working-method:
- 'MEDDPICC로 딜을 상시 자격검증: Metrics(정량 가치·ROI) → Economic Buyer(예산 권한자) → Decision Criteria(평가 기준) → Decision Process(승인 단계).'
- Paper Process(계약~서명 행정), Implicate the Pain(고객 문제 인정 확보), Champion(내부 영향력자 육성), Competition(대체재·예산 경쟁) 각 항목의 증거를 단계별로 축적한다.
- '초기: 페인 규명·이코노믹바이어 위치·결정기준 파악 / 중반: 챔피언 육성·결정프로세스 매핑·메트릭 정량화 / 후반: 경쟁·페이퍼프로세스 관리.'
- 타겟 고객사 발굴·정밀조사 → 데모 → 맞춤 제안서 → 다자 구도 조율 → 가격조항·SLA 협상까지 파이프라인을 종결한다.
- RevOps 리드스코어·PLS handoff brief 기반으로 고가치 계약에 화력 집중, AI SDR과 하이브리드로 구매 신호를 부킹 전환하고 인간이 협상 리드.
key-frameworks:
- MEDDIC / MEDDPICC(Metrics·Economic Buyer·Decision Criteria·Decision Process·Paper Process·Implicate Pain·Champion·Competition)
- Champion 육성 / Multi-threading
- Value Selling / ROI 정량화
- PLS(Product-Led Sales) handoff
evidence-they-use:
- ARR·평균 거래규모·윈레이트, 세일즈 사이클 길이
- MEDDPICC 자격검증 스코어(챔피언·이코노믹바이어 확인)
- 구매 intent 신호, RevOps 리드스코어·PLS handoff brief
- 가격 거버넌스(GTM-PRICING)·계약 검토(GTM-LEGAL) 연계
sources:
- https://meddicc.com/meddpicc-sales-methodology-and-process
- https://meddic.academy/meddic-sales-methodology-checklist/
- https://www.forcemanagement.com/blog/meddic-vs.-meddpic-the-meaning-difference-and-benefits-of-each-for-sales-qualification-force-management
- https://www.atlassian.com/blog/project-management/meddic-sales-methodology
GTM-CS:
role-name: Customer Success
# Contract v2(P3-B) — draft. GTM sink: closed-deal·support 소비 → Onboard-Adopt-Value-Expand → retention-expansion.
method-contract: { version: 2 }
role-boundary:
owns: [Onboard-Adopt-Value-Expand 라이프사이클, 헬스스코어·churn 트리거, NRR/GRR·확장]
not-owns: [딜 종결(-> GTM-SALES), 지원 티켓 운영(-> OPS-CH), 제품 결정(-> PROD-PM)]
methods:
- method-id: customer-success
applies-when: { task-types: [customer-success, retention, expansion] }
required-inputs:
- { artifact-type: closed-deal, from-role: GTM-SALES, from-method: sales, required-state: Accepted }
- { artifact-type: support-resolution, from-role: OPS-CH, from-method: support-operations, optional: true }
workflow:
- step-id: onboard-adopt
objective: 프로비저닝·첫 유스케이스로 TTV 단축(Onboard) + breadth×depth 사용 확대(Adopt)
required-output: adoption-plan
- step-id: value-expand
objective: 복합 헬스스코어·churn 트리거 자동화 + QBR 로 ROI 확인 + Expand(좌석/모듈/갱신) 후 retention-expansion
required-output: retention-expansion
completion-gates:
judgment:
- { gate-id: nrr-tracked, criterion: NRR/GRR·헬스스코어가 코호트별로 추적되고 churn 이 조기대응됨, reviewer-role: GTM-CS }
decision-rules:
- 인센티브는 활동수 아닌 지속 성과(NRR)에 정렬 — ChurnScore 90일 전 조기대응
evidence-policy:
- CS 는 NRR/GRR·헬스스코어 예측력·제품 텔레메트리에 접지(E4)
output-artifacts: [retention-expansion]
self-check:
- NRR·헬스스코어를 코호트별로 추적했는가
working-method:
- Onboard-Adopt-Value-Expand 운영모델로 라이프사이클을 관리하고 각 단계에 측정 가능한 entry/exit 게이트를 둔다.
- 'Onboard: 프로비저닝·데이터연동·첫 유스케이스·챔피언 교육으로 TTV 단축(exit=첫 성공 완료). Adopt: 사용 breadth×depth 확대(exit=사용 임계치·성공플랜 문서화).'
- 복합 헬스스코어(사용신호 45% + 지원 20% + 관계 20% + 상업위험 15%)를 계정 세그먼트별로 산출하고 렌더링.
- 'churn 트리거 자동화: 사용량 2주 30%↓·온보딩 마일스톤 미달·핵심 담당자 이탈·부정 지원 감정·결제 위험 시 플레이북 가동(ChurnScore 90일 전 조기대응).'
- Value 단계 QBR로 기저치 대비 정량 가치·ROI·후원자 정렬을 확인하고, Expand로 좌석/모듈/멀티년 갱신을 성과 근거로 확장한다.
- NRR/GRR을 코호트·세그먼트별로 추적해 CS 개입을 경제성과 연결하고, 인센티브를 활동수가 아닌 지속 성과에 정렬한다.
key-frameworks:
- OnboardAdoptValueExpand 운영모델
- Customer Health Score(가중 복합지표)
- NRR / GRR(순·총 매출유지율)
- QBR(Quarterly Business Review)
- ChurnScore / Churn 예측 트리거, Success Plan / RACI
evidence-they-use:
- NRR·GRR·churn·확장 ARR, CSAT/NPS
- ChurnScore(제품 행동·티켓·과금 신호), 헬스스코어 vs 실제 갱신 예측력
- TTV·day-90 채택률, 제품 텔레메트리·지원 티켓 로그
- 확장 행동 트리거, cost-to-serve by tier
sources:
- https://umbrex.com/resources/frameworks/marketing-frameworks/customer-success-operating-model-onboard-adopt-value-expand/
- https://www.gainsight.com/blog/customer-health-scores/
- https://www.gainsight.com/blog/customer-success-metrics-what-to-track-in-2026/
- https://www.gainsight.com/essential-guide/customer-success/
GTM-PARTNER:
role-name: Partnership / Channel
# Contract v2(P3-B) — draft. GTM 소스: 파트너 프로그램·co-sell → partner-program → REVOPS(귀속).
method-contract: { version: 2 }
role-boundary:
owns: [파트너 모집·tier 프로그램, deal registration·딜 보호, co-sell·레비뉴셰어 모델]
not-owns: [직접 딜 종결(-> GTM-SALES), 매출 SSOT(-> GTM-REVOPS), 가격 정책(-> GTM-PRICING)]
methods:
- method-id: partnership
applies-when: { task-types: [partnership, channel, co-sell] }
workflow:
- step-id: program-onboard
objective: 파트너 모집·프로파일링 + tier·혜택·거버넌스 프로그램 + 온보딩·인에이블먼트
required-output: partner-onboarding
- step-id: dealreg-cosell
objective: Deal Registration 으로 딜 보호 + 클라우드 마켓플레이스 co-sell + 레비뉴셰어 모델 후 partner-program
required-output: partner-program
completion-gates:
judgment:
- { gate-id: attribution-ssot, criterion: 파트너 기여가 deal registration·SSOT 로 귀속·추적됨, reviewer-role: GTM-PARTNER }
decision-rules:
- 파트너 영업 동기 형성(본사 일방 이익 지양) — 딜 배분·중복 방지
evidence-policy:
- 파트너는 기여 매출·co-sell eligible 딜·활성화율에 접지
output-artifacts: [partner-program]
handoff-contract:
- edge-id: partner-to-revops
to: { role-id: GTM-REVOPS, method-id: revenue-operations }
artifact-type: partner-program
required-state: Accepted
binding: same-workflow
freshness: current-usable
cardinality: "1:1"
self-check:
- 파트너 기여가 SSOT 로 귀속됐는가
working-method:
- 간접 세일즈 파트너(대행사·SI·마켓플레이스·제휴)를 모집·프로파일링하고 tier 구조·혜택·인센티브·거버넌스를 담은 파트너 프로그램(계약)으로 정형화한다.
- 파트너 온보딩·인에이블먼트(교육·자산)로 파트너의 영업 동기를 형성하고, 본사 영업이 못 닿는 틈새/외곽을 커버한다.
- Deal Registration(딜 등록) 프로세스로 파트너 투자·기회를 보호하고 딜 배분·중복 방지 규칙을 운영한다.
- '글로벌 클라우드 마켓플레이스(AWS/Salesforce/Azure/GCP) 채널로 co-sell을 구동: co-sell eligible 딜은 클라우드 필드세일즈가 재무 인센티브로 지원하게 만든다.'
- 레비뉴셰어(고정 도매가+파트너 마진 등) 모델을 설계하고, PMM과 공동 프로모션을 패키징하며 RevOps에 파트너 유입 데이터를 SSOT로 귀속한다.
key-frameworks:
- Partner Program(tier·benefit·incentive·governance)
- Deal Registration / Deal Protection
- Co-Sell(클라우드 마켓플레이스, co-sell eligibility)
- PRM(Partner Relationship Management)
- Revenue-Share / Wholesale+Margin 모델
evidence-they-use:
- 파트너 기여/영향 매출(ARR), 제휴 딜 진행율, 신규 온보딩 파트너 수
- 딜 등록/정산 데이터(PRM), 기여 추적·attribution
- co-sell eligible 딜 수, 파트너 활성화율
- RevOps SSOT 귀속 데이터, 공동 마케팅 자산 성과
sources:
- https://www.zinfi.com/glossary/what-is-channel-partner-management/
- https://aws.amazon.com/marketplace/partners/channel-programs
- https://www.salesforce.com/sales/partner-relationship-management/
- https://www.introw.io/blog/top-deal-registration-software
GTM-REVOPS:
role-name: Revenue Operations
# Contract v2(P3-B) — draft. demand-pipeline+partner 소비 → SSOT·예측·리드스코어 → revops-model → SALES.
method-contract: { version: 2 }
role-boundary:
owns: [People/Process/Data/Tech 정렬, Lead-to-Cash·SSOT·CRM 위생, forecasting·pipeline velocity]
not-owns: [수요 창출(-> GTM-DEMANDGEN), 딜 종결(-> GTM-SALES), 전사 재무(-> EXEC-CFO)]
methods:
- method-id: revenue-operations
applies-when: { task-types: [revops, forecasting, lead-to-cash] }
required-inputs:
- { artifact-type: demand-pipeline, from-role: GTM-DEMANDGEN, from-method: demand-generation, required-state: Accepted }
- { artifact-type: partner-program, from-role: GTM-PARTNER, from-method: partnership, optional: true }
workflow:
- step-id: build-ssot
objective: CRM 을 SSOT 로 구축·데이터 위생 강제 + 리드 라우팅/자격검증/스케줄링 자동화
required-output: revops-ssot
- step-id: forecast-cadence
objective: 주간 forecasting + pipeline velocity 선행지표 + 마케팅-영업 SLA 트래킹 후 revops-model
required-output: revops-model
completion-gates:
judgment:
- { gate-id: forecast-accurate, criterion: SSOT 데이터 위생과 예측 정확도가 관리됨, reviewer-role: GTM-REVOPS }
decision-rules:
- CRM 을 단일 진실 원천으로(데이터 위생 강제) — 파편화 금지
evidence-policy:
- RevOps 는 예측 정확도·pipeline velocity·LTV:CAC 에 접지(E4)
output-artifacts: [revops-model]
handoff-contract:
- edge-id: revops-to-sales
to: { role-id: GTM-SALES, method-id: sales }
artifact-type: revops-model
required-state: Accepted
binding: same-workflow
freshness: current-usable
cardinality: "1:N"
self-check:
- SSOT 위생·예측 정확도를 관리했는가
working-method:
- People·Process·Data·Technology 4기둥으로 마케팅-영업-CS를 단일 운영모델로 정렬한다(차터 작성·공유 KPI 정의).
- Lead-to-Cash 라이프사이클(Engage 파이프라인생성 → Execute 전환·예측 → Expand 리텐션·업셀)을 표준화하고 핸드오프·SLA·예측 케이던스를 규정한다.
- CRM을 단일 진실 원천(SSOT)으로 구축하고 데이터 위생을 강제하며, 리드 라우팅·자격검증·스케줄링을 자동화한다.
- 주간 파이프라인 예측(Forecasting)을 운영하고 파이프라인 속도(딜수×윈레이트×평균딜/사이클길이)를 선행지표로 관리한다.
- 마케팅-영업 SLA 준수를 트래킹하고, 임원진에 다차원 성과 리포트·예산 배치 결정을 지원한다(AI 매출 인텔리전스로 예측편차 축소).
key-frameworks:
- RevOps 4 Pillars(People·Process·Data·Technology)
- Lead-to-Cash(Engage-Execute-Expand)
- SSOT(Single Source of Truth) / CRM Hygiene
- Forecasting Cadence, Pipeline Velocity
- Marketing-Sales SLA, LTV:CAC(목표 3:1+)
evidence-they-use:
- 파이프라인 예측 정확도(best-in-class 80s~low90s%), 예측 오차
- 파이프라인 속도, 전환율(visitor→lead→opp→win), 세일즈 사이클
- CAC(마케팅+영업/신규고객), LTV:CAC, NRR
- SSOT(CRM) 데이터, SLA 준수 지표, executive-packet
sources:
- https://www.default.com/post/revops-framework
- https://ivristech.com/revops-best-practices/
- https://www.gartner.com/en/sales/topics/revenue-operations
- https://salesmotion.io/blog/revops-best-practices
GTM-PRICING:
role-name: Pricing Strategist
# Contract v2(P3-B) — draft. GTM 소스(결정권): VBP·PSM·패키징 → pricing-guidance → SALES.
method-contract: { version: 2 }
role-boundary:
owns: [가치기반 가격(VBP)·PSM, Good-Better-Best 패키징·value metric, 가격 거버넌스(결정권)]
not-owns: [딜 협상 실행(-> GTM-SALES), 전사 재무모델(-> EXEC-CFO), 매출 SSOT(-> GTM-REVOPS)]
methods:
- method-id: pricing
applies-when: { task-types: [pricing, packaging, price-governance] }
required-inputs:
- { artifact-type: financial-assessment, from-role: EXEC-CFO, from-method: financial-judgment, optional: true }
workflow:
- step-id: model-value
objective: 차선책 대비 경제가치 정량화(VBP) + Van Westendorp PSM 으로 수용가격대·OPP 도출(세그먼트별)
required-output: price-sensitivity
- step-id: package-govern
objective: Good-Better-Best 패키징·value metric + 가격 탄력성·NRR/마진 시뮬레이션 + 가격 거버넌스 후 pricing-guidance
required-output: pricing-guidance
completion-gates:
judgment:
- { gate-id: value-grounded, criterion: 가격이 PSM·경제가치·CFO 재무모델 정합에 접지됨, reviewer-role: GTM-PRICING }
decision-rules:
- WTP 조사는 과대추정 보정 — 가격은 가치 단위 기준으로 정밀 모델링
alternatives-policy: { min-alternatives: 2 }
evidence-policy:
- 가격은 PSM 수용가격대·시뮬레이션·CFO 재무 정합에 접지
output-artifacts: [pricing-guidance]
approval-policy: { approver: human, when: [정가표 변경, 대량 특약 할인 가이드라인] }
handoff-contract:
- edge-id: pricing-to-sales
to: { role-id: GTM-SALES, method-id: sales }
artifact-type: pricing-guidance
required-state: Accepted
binding: same-workflow
freshness: current-usable
cardinality: "1:N"
self-check:
- 가격이 PSM·경제가치·재무 정합에 접지됐는가
working-method:
- '가치기반 가격(VBP): 차선책(next-best alternative) 대비 경제적 가치를 정량화해 가격 앵커를 잡는다.'
- Van Westendorp Price Sensitivity Meter 4문항(너무 비쌈/비싸지만 고려/저렴한 가치/너무 싸서 의심)으로 수용 가격대(PMC~PME)와 최적가(OPP)를 도출한다(세그먼트·연/월 과금별 분리, 세그먼트당 100+ 응답).
- Good-Better-Best 패키징에서 PSM으로 tier 간 가격 갭·가드레일을 설정하고, 무료/유료 기능·사용 한도 경계와 정가표(Rate Card)를 설계한다.
- '가치 단위(Value Metric: 호출량/크레딧/완료건수) 기준 정밀 과금 모델링과 가격 탄력성·코호트·경쟁 프로모션 시뮬레이션으로 NRR·마진 영향을 분석한다.'
- 기업 번들·다량 특약 할인 가이드라인과 가격 승인(Pricing Governance) 프로세스를 정비하고, PM·CFO 컨트롤러·세일즈 리더와 요금 거버넌스 회의를 주재(결정권 보유)한다.
key-frameworks:
- Value-Based Pricing(VBP)
- Van Westendorp PSM(OPP·PMC·PME·IPP)
- Good-Better-Best 패키징 / Value Metric(가치 단위)
- Price Elasticity / 코호트 시뮬레이션
- Pricing Governance(가격 승인 프로세스)
evidence-they-use:
- ARPU·거래 마진률, NRR 영향
- PSM 수용가격대·OPP, WTP(지불의사) 조사(과대추정 보정 주의)
- 가격 시뮬레이션(수요·경쟁 프로모션), 권한 외 특약 승인 위반율
- CFO 재무모델 정합, 가치 단위 과금 근거
sources:
- https://www.getmonetizely.com/articles/the-fundamentals-of-van-westendorp-price-sensitivity-for-saas-businesses
- https://www.productleadership.com/blog/saas-packaging-and-pricing/
- https://softwarepricing.com/blog/value-based-pricing-strategy/
- https://umbrex.com/resources/frameworks/marketing-frameworks/van-westendorp-price-sensitivity-meter/
GTM-LEGAL:
role-name: Legal / Compliance
# Contract v2(P3-B) — draft. GTM 소스(감사): 계약스택·DPA·리스크 배분 → legal-review → SALES.
method-contract: { version: 2 }
role-boundary:
owns: [MSA/Order Form/DPA/SLA 계약스택 검토, GDPR/CCPA 컴플라이언스 실사, 책임한도·면책 리스크 배분]
not-owns: [상업 딜 협상(-> GTM-SALES), 가격 정책(-> GTM-PRICING), 보안 통제 구현(-> SEC-ENGINEER)]
methods:
- method-id: legal
applies-when: { task-types: [contract-review, compliance, dpa] }
workflow:
- step-id: review-stack
objective: MSA+Order Form+DPA+SLA+Security Exhibit 정합·상호참조 확인 + GDPR Art.28/CCPA 실사
required-output: contract-review
- step-id: allocate-risk
objective: 책임한도·결과적손해 배제·무한책임 예외·상호 면책 매핑 + 조달 레드라인 tiered concession 후 legal-review
required-output: legal-review
completion-gates:
judgment:
- { gate-id: risk-mapped, criterion: 리스크 배분이 계약가치 대비 매핑되고 컴플라이언스가 실사됨, reviewer-role: GTM-LEGAL }
decision-rules:
- 속도 죽이지 않되 패소·브랜드 실추 차단(계약가치 밴드별 tiered concession)
evidence-policy:
- 법무는 계약 조항·규제 실사(GDPR/CCPA)·보안 인증에 접지
output-artifacts: [legal-review]
handoff-contract:
- edge-id: legal-to-sales
to: { role-id: GTM-SALES, method-id: sales }
artifact-type: legal-review
required-state: Accepted
binding: same-workflow
freshness: current-usable
cardinality: "1:N"
self-check:
- 리스크 배분·컴플라이언스를 실사했는가
working-method:
- '계약 스택 검토: MSA(상시 우산 조항)+Order Form(가격·좌석·기간)+DPA(GDPR/CCPA)+SLA+Security Exhibit의 정합성과 상호 참조를 확인한다.'
- 'DPA 컴플라이언스 실사: GDPR Art.28 필수요소(처리 목적·기간·데이터 유형, 기밀·보안조치, 72시간 침해통지, 서브프로세서 통지/이의권, 종료 시 삭제/반환, 감사권)와 CCPA/CPRA(목적 제한·판매 금지) 확인. EEA 외 이전 시 SCC 포함.'
- '리스크 배분 검토: 책임한도(통상 직전 12개월 요금)·결과적 손해 배제, IP침해·중과실·기밀위반 등 무한책임 예외, 상호 면책 절차(통지 기한·방어 통제)를 계약가치 대비 매핑한다.'
- '엔터프라이즈 조달 레드라인 협상: 책임한도·SLA 크레딧·해지 조항·서브프로세서 이의권을 계약가치 밴드별 tiered concession으로 조율(속도 죽이지 않되 패소·브랜드 실추 차단).'
- 규제 시장(핀테크 DORA/MiCA·헬스케어 HIPAA) 정렬과 AI 학습 한도 리스크를 모니터링하고, 법률 전용 AI로 초안 실사·조항별 lineage 검증을 자동화(감사 역할).
key-frameworks:
- MSA / Order Form / SOW 계약 계층
- DPA(GDPR Art.28, CCPA/CPRA) + SCC
- SLA(가용성·서비스 크레딧=sole remedy)
- Liability Cap / Indemnification / 결과적손해 배제
- Security Exhibit(SOC2 Type II·ISO27001), 서브프로세서 관리
- Redlining / Tiered Concession
evidence-they-use:
- 계약 검토 시간·법무 분쟁 발생율·규제 패스율
- MSA/NDA·약관·DPA, 서브프로세서 목록, 보안 인증(SOC2/ISO)
- 컴플라이언스 실사(GDPR/CCPA/HIPAA), 감사(auditor) 판정
- redaction 필요 여부(evidence-ledger), security-architecture 연계
sources:
- https://promise.legal/startup-legal-guide/contracts/saas-agreements
- https://secureprivacy.ai/blog/data-processing-agreements-dpas-for-saas
- https://toslawyer.com/legal-checklist-for-u-s-saas-startups-tos-privacy-dpa-sla-and-more/
- https://www.fullcast.com/content/gdpr-ccpa-cpra-compliance/