왜 연락 순서를 사고 유형별로 다르게 정하는가

정책 위반 정지는 플랫폼의 이의신청 창구가 사실상 유일한 해결 경로이므로 공식 지원팀 접근이 최우선입니다. 반면 계약·정산 관련 사고라면 대행사 담당자와의 협의가 먼저이고, 내부 시스템 오류로 의심되는 태그 장애라면 사내 개발·마케팅 담당자 확인이 먼저입니다. 유형을 구분하지 않고 매번 같은 순서로 연락하면, 정작 필요한 창구에 늦게 도달해 대응이 지연됩니다. 이 순서는 1강에서 정리한 사건 분류표와 짝을 이루도록 설계해, 유형이 정해지는 순간 연락 순서도 자동으로 정해지게 만드는 것이 이상적입니다.

플랫폼 공식 지원팀은 어떻게 접근하는가

전담 계정 관리자가 배정된 광고주는 그 담당자에게 직접 연락하는 것이 가장 빠른 경로입니다. 전담 관리자가 없는 계정은 각 플랫폼의 공식 고객센터·정책 고객센터를 통해 이의신청이나 문의를 제출해야 하며, 이때 계정 ID, 사고 발생 시각, 2강에서 확보해둔 자산·권한 캡처 화면을 함께 제출하면 처리 속도가 빨라집니다. 비공식 대행사나 컨설턴트가 "플랫폼 내부 연락망이 있다"며 접근하는 경우는 검증되지 않은 경로이므로 신중하게 판단해야 하며, 이런 제안은 바로 다음 항목에서 다루는 비공식 채널 위험과 같은 선상에서 봐야 합니다.

대행 구조에서는 누가 창구 역할을 하는가

계정이 대행사 명의로 운영되는 경우 플랫폼과의 공식 소통 창구는 대행사가 됩니다. 광고주가 직접 계정을 소유한 경우에는 광고주가 창구가 되고 대행사는 지원 역할에 머무릅니다. 이 역할 구분이 사고 발생 전에 명확하지 않으면, 플랫폼 창구에 누가 이의신청을 넣어야 하는지부터 다시 확인하느라 시간을 씁니다. 계약 체결 시점에 이 창구 역할을 문서로 정리해두는 것이 가장 확실한 예방책이며, 창구가 바뀌는 계약 갱신·대행사 교체 시점마다 이 문서를 다시 확인하는 절차도 함께 마련해야 합니다.

내부 보고는 왜 실무자 선에서 끝나지 않아야 하는가

사고를 처음 발견한 실무자가 혼자 해결하려다 시간을 지체하는 경우가 많습니다. 사고 유형과 예상 손실 규모를 확인하는 즉시 승인권자에게도 동시에 알리는 구조를 만들어두면, 3강에서 다룬 예산 중지 같은 결정을 더 빨리 승인받을 수 있습니다. 실무자는 상황을 정확히 보고할 책임을, 승인권자는 그 보고를 근거로 판단할 책임을 지는 구조가 여기서도 그대로 적용되며, 이 이중 보고는 늦어도 사고 인지 후 한 시간 이내에는 이뤄지는 것이 바람직합니다.

연락처 목록은 어떤 형태로 관리하는가

사고가 터진 순간에 연락처를 찾아 헤매지 않도록, 플랫폼별 공식 지원 창구 링크, 전담 관리자 연락처(있는 경우), 대행사 담당자, 내부 승인권자를 한 장짜리 표로 정리해 상시 접근 가능한 곳에 보관해야 합니다. 이 표는 담당자가 바뀔 때마다 갱신해야 하며, 갱신 책임자를 지정해두지 않으면 실제 필요한 순간에 표가 오래돼 쓸모없어지는 경우가 흔합니다. 분기에 한 번씩 정기 점검일을 정해 표를 최신 상태로 유지하는 것도 좋은 방법입니다.

담당자 공백기에는 어떻게 대비하는가

휴가나 퇴사로 담당자가 자리를 비운 사이 사고가 발생하면 대응이 마비될 위험이 큽니다. 최소한 이 연락처 표와 사고 유형별 대응 절차를 두 명 이상이 접근할 수 있는 공유 문서로 관리하고, 담당자 교체 시 인수인계 체크리스트에 이 문서 위치를 반드시 포함해야 합니다. 한 사람만 아는 절차는 그 사람이 없을 때 존재하지 않는 것과 같으며, 이 원칙은 이후 8강에서 다룰 사고 회고·예방 통제 설계 전체에 공통으로 적용됩니다.

비공식 채널의 유혹을 왜 경계해야 하는가

사고가 급하다 보면 "아는 사람을 통하면 빨리 해결된다"는 제안에 흔들리기 쉽습니다. 하지만 플랫폼 정책상 공식 절차를 거치지 않은 비공식 경로는 검증할 방법이 없고, 오히려 계정 정보를 넘기는 과정에서 새로운 보안 사고로 이어질 위험이 있습니다. 급할수록 공식 지원 창구와 전담 관리자 경로를 우선하고, 비공식 제안은 내부 승인권자와 상의한 뒤에만 검토하는 원칙을 세워둬야 합니다.

연락 이후의 후속 조치는 어떻게 이어지는가

공식 창구에 연락을 마쳤다고 사고 대응이 끝나는 것은 아닙니다. 접수 번호나 답변 예상 시점을 받았다면 이를 5강에서 다룰 사실 기록에 남기고, 답변이 오지 않는 기간에는 정해둔 주기(예: 하루 1회)로 진행 상황을 확인해야 합니다. 연락 자체를 마지막 조치로 여기고 방치하면, 정작 플랫폼의 추가 요청 사항을 놓쳐 이의신청이 지연되는 경우가 흔합니다.

여러 대행사가 함께 일할 때 창구가 겹치면 어떻게 하는가

매체별로 서로 다른 대행사가 붙어 있는 경우, 사고가 특정 매체에서만 발생했더라도 다른 대행사까지 혼선을 겪는 일이 생깁니다. 이런 구조에서는 사고 발생 매체를 담당하는 대행사가 1차 창구를 맡고, 나머지 대행사에는 상황 공유만 하도록 역할을 미리 나눠둬야 합니다. 창구를 정하지 않은 채 관련된 모든 대행사에 동시에 문의가 쏟아지면, 정작 누가 실제로 플랫폼과 소통하고 있는지 내부에서도 헷갈리게 됩니다.