긴급 상황(예산 소진·계정 정지) 발생 시 에스컬레이션 프로토콜 설계

예산 소진은 예측 가능한 사건입니다. 일 예산과 소진 속도를 매일 확인하는 팀이라면 대부분 몇 시간 전에 징후를 볼 수 있고, 대응도 예산 증액이나 캠페인 일시중지처럼 담당자 선에서 끝나는 경우가 많습니다. 반면 계정 정지는 매체의 정책 위반 판정이나 결제 실패처럼 담당자가 미리 통제하기 어려운 원인에서 시작되는 경우가 흔하고, 해제 절차도 매체사의 검토를 거쳐야 해서 대행사 내부에서 즉시 해결되지 않습니다. 두 상황을 하나의 "긴급 대응 매뉴얼"로 뭉뚱그리면, 예산 소진처럼 담당자가 즉시 처리할 수 있는 사안까지 불필요하게 상위 보고 절차를 거치게 하거나, 반대로 계정 정지처럼 여러 단계의 승인과 매체사 소통이 필요한 사안을 담당자 혼자 붙들고 있게 만들 위험이 있습니다.

서비스수준계약(SLA)의 표준 구성은 KPI를 정기적으로 검토·수정하는 절차, 목표 미달 시 상위 보고로 이어지는 에스컬레이션 절차, 서비스 제공자가 조건을 충족하지 못했을 때의 보상(페널티) 규정 세 가지를 포함하는 것으로 설명됩니다. 이 틀을 긴급 상황 대응에 그대로 옮기면, ① 어떤 지표가 어느 수준을 넘으면 긴급 상황으로 분류하는지(예: 일 예산의 150% 이상 소진, 계정 상태가 '검토 중' 이상으로 전환), ② 그 상황이 발생했을 때 누구에게 몇 시간 안에 보고해야 하는지, ③ 대응이 늦어졌을 때 광고주에게 어떤 방식으로 설명하고 보상할지를 문서로 미리 정해두는 형태가 됩니다. 이 세 요소가 계약서나 운영 매뉴얼에 없으면, 긴급 상황이 터졌을 때 "누가 결정할 권한이 있는지"부터 그 자리에서 논쟁하게 됩니다.

긴급 상황에서 가장 흔한 병목은 보고 체계가 아니라 접근 권한입니다. 구글 애즈는 이메일 전용·결제·읽기 전용·표준·관리 중 하나의 액세스 수준으로 사용자를 초대하는 구조이고, 메타 비즈니스 관리자는 광고 계정·페이지·픽셀 같은 자산 단위로 파트너 접근 권한을 부여하는 구조입니다. 예산을 즉시 조정하거나 정지 사유를 확인하려면 최소한 표준 이상의 액세스 수준이 필요한데, 담당자가 읽기 전용 권한만 갖고 있다면 문제를 발견해도 직접 조치하지 못하고 다시 권한 보유자를 찾아야 합니다. 에스컬레이션 프로토콜을 설계할 때는 "누가 보고받을지"와 별개로 "누가 실제로 버튼을 누를 수 있는지"를 접근 권한 목록과 함께 미리 확인해둬야 합니다.

계약서에 "광고주 소유, 대행사는 운영 권한만 위임"이라는 문구가 명확하지 않고 계정이 대행사 명의로 개설돼 있으면, 계정 정지 같은 긴급 상황에서 광고주가 직접 매체사에 이의를 제기할 방법이 없어집니다. 대행사를 거치지 않고는 상황을 확인할 수조차 없는 구조는 정지 해제가 지연될수록 광고주의 불안을 키우고, 대행사에 대한 신뢰도 함께 흔들립니다. 소유권 조항 정비는 평시에는 눈에 띄지 않지만, 긴급 상황에서 대응 속도를 좌우하는 요소입니다.

긴급 상황이 해결됐다고 그대로 넘어가면 같은 유형의 문제가 반복됩니다. 무엇이 트리거였는지, 보고까지 걸린 시간, 실제 조치자, 광고주에게 전달한 시점과 내용을 짧게라도 기록해두고, 다음 SLA 검토 주기에 에스컬레이션 절차 자체를 다시 손볼 필요가 있는지 점검하는 것이 표준 KPI 검토 절차의 연장선입니다.

모든 예산 소진·계정 정지를 똑같은 무게로 다루면 정작 심각한 사안이 묻힙니다. 일 예산이 20% 초과 소진된 것과 계정 전체가 정지된 것은 대응 속도와 보고 대상이 달라야 합니다. 긴급도를 두세 단계로 나누고(예: 담당자 선에서 즉시 조치 가능한 수준, 팀장 보고가 필요한 수준, 광고주에게 즉시 알려야 하는 수준), 각 단계마다 몇 시간 안에 무엇을 해야 하는지 미리 표로 정리해두면 상황이 터졌을 때 "이게 몇 단계짜리 사안인지"부터 판단하는 시간을 아낄 수 있습니다. 이 표는 SLA의 에스컬레이션 절차를 계정 단위로 더 세분화한 버전이라고 볼 수 있습니다.

긴급 상황이 발생했을 때 누구에게 연락해야 하는지 자체를 몰라 시간을 허비하는 경우가 생각보다 흔합니다. 광고주 쪽 담당자가 휴가 중이거나 퇴근 후라면 대체 연락처가 필요하고, 대행사 쪽도 담당자 한 명에게만 연락이 몰리면 그 사람이 자리를 비운 순간 대응이 전면 중단됩니다. 계약 초기에 평시 연락 창구와 긴급 연락 창구를 구분해 양쪽 팀의 비상연락망을 서로 공유해두면, 실제 상황에서 연락 자체를 못 해 대응이 늦어지는 일을 막을 수 있습니다.

매체 광고관리자의 예산 소진 알림이나 계정 상태 변경 알림을 설정해두는 것만으로 프로토콜이 완성됐다고 생각하기 쉽지만, 알림은 결국 사람이 확인해야 의미가 있습니다. 알림이 특정 담당자 한 명의 메일함에만 꽂히게 설정돼 있다면, 그 사람이 알림을 놓치는 순간 아무도 상황을 모르는 채로 시간이 흘러갑니다. 알림은 팀 공용 채널로도 함께 전달되도록 설정하고, "알림을 받았다"와 "확인하고 조치를 시작했다"를 구분해 누가 언제 확인했는지 표시하는 최소한의 절차를 둬야, 알림 시스템이 실제로 에스컬레이션 프로토콜의 일부로 작동합니다.