누가 이벤트를 만들었고, 어떤 조건으로 시스템에 들어갔으며, 고객은 무엇을 봤고, 상담사는 무엇을 전달받았고, 문제가 생기면 누가 실제로 고칠 수 있는가.
읽는 법
대표 사례의 숫자는 구조를 보여주기 위한 가상 숫자이며 특정 회사의 이벤트가 아닙니다. 특정 회사에서 누가 이벤트를 기획했는지는 공개 자료가 없으면 “확인하지 못함”으로 둡니다. AMS는 어느 회사와도 제휴 관계가 없습니다.
01 / ADVERTISED VS EFFECTIVE
광고 혜택과 실제 혜택
광고 문구
“전 고객 20% 할인”
광고 혜택
20%
최대 혜택
10,000원
10만 원 주문 시 실제
10,000원 · 실제 할인율 10%
이유
최대 할인 한도(MAX_DISCOUNT_CAP)
Transparency Gap(보이는 조건과 실제 조건의 차이): 광고 전면의 숫자(20%)와 상세 조건 속 실제 혜택(최대 1만 원) 사이의 차이입니다. 같은 화면에 있었는지, 얼마나 작게 있었는지가 정보 계층 차이입니다.
상세 조건(예시)
조건
분류
앱 전용
채널 조건(앱 전용 등)
5만 원 이상 결제 시
수량·금액 조건
최대 1만 원 할인
수량·금액 조건
일부 상품 제외
상품 조건
특정 결제수단 제외
결제수단 조건
다른 쿠폰과 중복 불가
중복 사용 조건
예산 소진 시 조기 종료
예산·선착순
02 / CALCULATOR
내 주문으로 다시 계산하기
광고 혜택
20%
실제 할인액
10,000원 (광고율대로면 20,000원, 최대 할인에 걸림)
실제 할인율
10%
결제금액
90,000원
이유
최대 할인 한도(MAX_DISCOUNT_CAP)
03 / NOT APPLIED
할인이 안 될 때: 정책상 미적용인가, 시스템 오류인가
“할인 안 됨”을 바로 시스템 오류로 보지 않습니다. 대부분은 조건 하나를 충족하지 못한 정책상 미적용입니다. 상담사에게는 이 세 가지부터 구분해 달라고 물어보세요 — 조건 미충족인가요, 시스템 오류인가요, 예산·선착순 소진인가요?
이유
성격
최소 결제금액 미달
정책상 미적용
제외 상품
정책상 미적용
대상 아닌 결제수단
정책상 미적용
대상 아닌 채널(웹·앱)
정책상 미적용
대상 아닌 회원
정책상 미적용
선착순 마감
정책상 미적용
예산 소진
정책상 미적용
이벤트 종료
정책상 미적용
다른 할인과 중복 불가
정책상 미적용
시스템 오류
시스템 문제
확인하지 못함
확인 필요
쿠폰은 세 단계가 따로 실패할 수 있습니다: 쿠폰 발급(쿠폰함에 들어옴) ≠ 쿠폰 적용(주문서에서 조건을 통과해 금액이 빠짐) ≠ 결제 할인(최종 결제·카드 청구에 반영됨).
마감 시각 분쟁은 어느 시각이 기준인지에 달렸습니다: 주문 접수 시각 · 결제 완료 시각 · 카드 승인 시각 · 배송 완료 시각 · 기준 시각 확인 필요. 기간 표시는 시간대(한국 시간 등)까지 확인합니다.
04 / WHO MADE IT
이벤트를 만든 사람 ≠ 이벤트 문의를 받는 사람
정책 결정 — 정책 주체: 할인율·한도·대상·예산을 정함
프로모션 설계 — 정책 주체: 조건과 예외를 문서로 만듦
고객용 문구 — 광고 주체: 배너·푸시·이벤트 페이지
시스템 구현 — 시스템 주체: 쿠폰 발급·적용 로직
상담 안내서 — 고객센터: 상담사가 받는 FAQ·매뉴얼
고객 — 확인하지 못함: 문구를 보고 결제
고객센터 문의 — 고객센터: "할인이 왜 안 되나요?"
예외 처리 — 예외 승인권자: 조건 밖 적용·보상 결정
일반 구조에서는 경영·사업·상품·마케팅 조직이 이벤트를 기획할 수 있습니다. 실제 회사별 주체는 공개 근거가 있어야 적습니다.
이벤트 책임 지도
누가 설계했나
확인하지 못함
누가 시스템에 넣었나
확인하지 못함
누가 광고했나
확인하지 못함
누가 문의를 받나
고객센터
누가 예외를 승인하나
확인하지 못함
책임의 갈래: 정책 문제는 정책 주체, 시스템 문제는 시스템 주체, 카드·결제 문제는 결제·카드사, 고객 안내는 고객센터.
05 / AGENT LAYER
상담사는 무엇을 알고, 무엇을 바꿀 수 있나
상담사가 볼 수 있는 것
고객용 이벤트 공지·FAQ
상담용 안내서(전달받은 경우)
주문·결제 정보
쿠폰 발급·적용 여부
시스템 오류 코드 일부
상담사가 바꾸지 못할 수 있는 것
이벤트 조건 변경
쿠폰 강제 발급
소진된 예산 복구
카드사·결제사 승인
조건 밖 예외 할인 승인
CONTROL GAP — 항의받는 사람 ≠ 바꿀 수 있는 사람
고객이 가장 먼저 항의하는 사람(상담사)과 이벤트 조건을 바꾸거나 예외를 승인할 수 있는 사람이 다를 수 있습니다. 상급자 연결(SUPERVISOR_REQUEST)도 같은 정책에 묶여 있으면 정책 변경(POLICY_OVERRIDE)이 아닙니다.
주체
원인 가능성
통제하는 것
고객 접점
정책 주체
높음
조건·예산·예외 기준
없음
시스템 주체
중간
적용 로직·오류 수정
없음
결제·카드사
정책·계약에 따라 다름
카드 청구할인·캐시백 처리
낮음
고객센터
낮음
조회·안내·전달(에스컬레이션)
높음
예외 승인권자
없음
조건 밖 적용·보상 승인
없음
일반적인 구조(AMS 정리)이며 실제 권한은 회사·이벤트마다 다릅니다. 같은 개념을 배송 사고에 적용한 것이 배달탐정의 CONTROL GAP입니다. 실시간 프로모션 변경이나 외부 제휴사 조건은 상담센터 문서 반영보다 먼저 바뀔 수 있습니다. 반대로 공지·안내서가 늦게 전달된 사실이 확인되면 DOCUMENTATION_LAG로 기록합니다. 상담사가 잘못 안내했을 가능성도 있으므로 판단은 상담 기록과 안내서 기준으로 합니다.
06 / POLICY HANDOFF GAP
이벤트는 노출됐는데 상담 안내서는 아직이라면
이벤트는 고객에게 이미 노출됐는데, 고객센터가 받은 조건·예외·시스템 상태·처리 기준이 충분하지 않거나 최신이 아닌 상태입니다.
NONE
간극 없음
MINOR
경미
MATERIAL
상당함
UNKNOWN
확인하지 못함
DOCUMENTATION_LAG는 정책·시스템이 바뀐 시각과 상담 문서가 갱신된 시각의 차이입니다. 두 시각이 모두 확인될 때만 계산하고, 실제 데이터가 있을 때만 시간표(예: 09:00 이벤트 시작 → 09:20 첫 문의 → 10:00 FAQ 갱신 → 11:30 예외 기준 전달)를 그립니다. 이 페이지의 사례에는 아직 그런 기록이 없어 “확인하지 못함”입니다.
짧은 이벤트(선착순·타임세일)는 기간이 짧고 문의가 몰리며, 중간에 품절·예산 소진·조건 변경이 생기기 쉬워 이 간극이 커지기 쉽습니다. 조건이 진행 중에 바뀌면 변경 전후 조건, 변경 시각, 사유, 고객 고지 여부를 기록해야 합니다.
운영 문제 유형(근거가 있을 때만 붙임)
상담 안내서 없음 · 상담 안내서가 최신이 아님 · 조건이 모호함 · 정책과 시스템 동작이 다름 · 예외 승인권자가 불분명 · 제휴사 조건에 좌우됨 · 결제·카드사 처리에 좌우됨 · 고객용 문구가 모호함 · 광고 문구와 상담 안내서가 다름 · 정책상 가능, 시스템상 불가 · 안내서상 가능, 실제 결제 불가 · 상담 안내 오류(안내 기록 근거 필요) · 확인하지 못함
07 / CAUSES
이벤트 분쟁을 한쪽 탓으로 끝내지 않기
층
확인할 질문
광고 문구
전면 숫자와 상세 조건이 같은 화면에 있었나?
정책
조건 자체가 무엇이었나?
시스템
시스템이 정책대로 적용했나?
상담 문서
상담사가 받은 안내서가 최신이었나?
상담 안내
상담사가 안내서대로 안내했나?(기록 필요)
고객 이해
조건을 놓쳤나, 조건을 충족 못 했나?
제휴·결제사
카드사·제휴사 처리 단계 문제인가?
“고객이 조건을 안 읽었다”로도, “상담사가 몰랐다”로도 끝나지 않습니다. 정책 문제·문서 문제·시스템 문제·상담 오류·고객 오해·조건 미충족을 나눠 봅니다. 프로모션은 하나의 점수가 아니라 조건의 명확성, 시스템 일관성, 상담 문서 품질, 예외 처리 명확성, 고객 투명성 축으로만 봅니다.
08 / REFUND
일부만 취소했는데 할인금액이 왜 달라졌나
최소 결제금액 조건이 있는 쿠폰은 일부 취소로 결제금액이 기준 아래로 내려가면 할인이 다시 계산될 수 있습니다. 계산기의 “일부 취소 금액”에 넣어 보세요.
컬리 — 쿠폰을 쓴 주문을 일부 취소하면
이용약관 제13조 2항: 할인쿠폰을 사용한 주문의 일부를 취소하면 그 주문에 사용된 쿠폰은 복원되지 않고 현금으로 보상되지도 않습니다. 실제 주문 화면의 처리 문구는 확인하지 못했습니다.