수요 분석
수요가 변하는 이유를 구분하는 기준 | 구매 조건과 고객 선호 분석
발행 · 최근 업데이트
수요가 줄었다는 결과만 보면 가격을 바꿔야 하는지, 구매 절차가 막혔는지, 제품 선호가 달라졌는지 구분하기 어렵습니다. 이 글에서는 2가지를 기준으로 봅니다. 구매 조건이 바뀌었는지와 같은 조건에서 고객이 원하는 사용 방식이 바뀌었는지를 따로 기록합니다. B2B SaaS에서는 계약 승인과 보안 검토를 사용 장면과 나눠 보면 가격 최적화와 동적 가격 판단의 방향을 분명히 잡을 수 있습니다.
변동의 출발점
수요 분석에서는 가격 자체와 수요곡선의 이동을 먼저 구분해야 합니다. 위키백과의 수요 설명처럼 가격이 바뀌어 선택량이 달라진 경우와 소득이나 대체재처럼 가격 밖의 조건이 달라져 수요가 이동한 경우는 기록 항목이 다릅니다. 출발점은 기록입니다. B2B SaaS에서 같은 요금표를 본 계정의 계약률이 떨어졌다면 고객 선호를 단정하지 말고 예산 승인 단계와 보안 검토 결과를 먼저 비교해 원인이 구매 조건인지 선호인지 가려야 합니다. 사용 목적은 별도 항목으로 적고, 가격을 바꾸기 전에는 이탈 계정의 마지막 행동과 승인 담당자의 반대 사유를 같은 표에 남깁니다.
구매 조건의 변화
구매 조건은 제품을 원하는지보다 거래를 진행할 수 있는지를 좌우합니다. B2B SaaS 담당자가 같은 문제를 인정해도 예산 승인 규칙이 바뀌거나 보안 심사 문서가 추가되면 고객의 선호가 그대로인 상태에서도 계약 속도가 달라집니다. 거래가 멈춘 지점을 표시합니다. 가격표를 열었지만 결제 단계로 넘어가지 않았다면 금액 외의 승인 구조를 확인합니다. 보안 문서 요청 뒤 응답이 끊겼다면 선호보다 조달 조건의 신호로 분류합니다. 예산 상한과 담당 부서를 고정 필드로 두고, 필수 연동 여부는 별도 필드로 관리하면 AI 에이전트가 관심 감소와 구매 불가를 섞지 않습니다.
고객 선호의 변화
고객 선호는 구매가 가능한 조건에서 남는 선택의 차이입니다. 같은 예산과 승인 조건에서 모바일앱 구독 화면의 선택만 줄고 다른 기능으로 이동했다면 가격보다 문제 해결 방식의 변화에 가깝습니다. 가격은 같습니다. 가격 민감도 분석은 단일 전환율만 보는 작업이 아닙니다. 같은 요금과 계약 조건에서 기능 선택과 사용 빈도가 함께 움직였는지 확인하고, 해지 사유는 별도 기록으로 남깁니다. 고객 인터뷰의 한 문장과 실제 사용 로그가 같은 방향을 가리킬 때 선호 변화로 적고, 한쪽만 바뀌면 측정 오류나 조건 변화를 다시 분리합니다.
원인 분리 실험
원인을 구분하려면 분석 단위를 계정과 사건으로 나눕니다. 가격과 계약 조건은 비교군 사이에서 고정합니다. 보안 상태는 별도 필드로 분리합니다. 구매 단계와 기능 사용 장면은 같은 기준으로 기록한 뒤 한 번에 한 조건만 바꿉니다. 가격을 바꿨을 때만 반응이 달라지면 구매 조건 가설을 검토하고, 가격이 같은데 특정 기능의 선택만 달라지면 선호 가설로 분류합니다. A/B 테스트를 도입할 때는 대상 계정의 권한과 계약 상태를 먼저 확인하고, 측정 항목을 2개 이하로 좁혀 해석 충돌을 줄입니다.
AI 에이전트 기록 기준
AI 에이전트는 원인을 대신 결정하는 장치가 아니라 분류 근거를 모으는 역할로 둡니다. 계정마다 변경된 조건과 관찰된 행동을 먼저 저장합니다. 고객이 남긴 표현은 별도 근거로 기록합니다. 가격 최적화나 동적 가격을 제안할 때도 구매가 막힌 이유와 원하는 사용 방식이 달라진 이유를 서로 다른 태그로 기록합니다. 추천 결과에는 근거 문장과 확인되지 않은 항목을 함께 표시해 운영자가 수정하도록 합니다. 초기에는 자동 변경보다 승인 대기 상태를 우선합니다. 같은 원인이 2회 이상 반복된 뒤 규칙을 승격하면 가격을 낮추는 조치가 구매 조건 문제를 가리는 일을 줄입니다.
핵심 요약
- 수요 감소를 해석할 때 가격 변화와 가격 밖 조건의 변화를 먼저 분리합니다.
- 구매 단계에서 멈춘 계정은 고객 선호보다 예산 승인과 보안 심사를 먼저 기록합니다.
- 같은 계약 조건에서 기능 선택과 사용 방식이 달라지면 고객 선호 변화로 분류합니다.
- AI 에이전트의 추천에는 변경 조건과 근거 문장을 함께 남겨 가격 조정의 원인을 추적합니다.
자주 묻는 질문
구매 조건과 고객 선호를 가장 먼저 어떻게 나누나요?
같은 가격과 계약 조건에서 구매 단계만 멈추면 구매 조건부터 봅니다. 구매가 진행된 뒤 기능 선택이나 사용 방식이 달라지면 고객 선호에 기록합니다. B2B SaaS에서는 두 단계의 로그를 분리해야 판단 근거가 남습니다.
가격이 내려갔는데 계약이 늘지 않으면 무엇을 확인하나요?
예산 승인 규칙이나 보안 심사가 병목인지 확인합니다. 중단된 단계와 요청된 문서를 계정별로 비교하면 가격 변경 전에 막힌 조건이 드러납니다.
AI 에이전트가 수요 원인을 자동으로 분류해도 되나요?
초기 분류에만 사용하고 자동 가격 변경은 승인 대기로 둡니다. 근거 태그와 고객 표현을 함께 남기고 같은 원인이 2회 이상 반복될 때 규칙을 다시 검토합니다.
동적 가격을 적용하기 전 필요한 데이터는 무엇인가요?
동일한 가격 노출 뒤의 구매 단계와 기능 사용 로그를 분리해 기록합니다. 가격 민감도 분석은 계약 조건이 다른 계정을 섞지 않아야 해석이 분명해집니다. 동적 가격은 원인 구분 뒤에 검토합니다.
참고한 자료
— Monetai · monetai.io