📖 약 3분 읽기
광고 성과 대시보드를 오픈하면 다음 날부터 광고주의 추가 요청이 도착한다. 화면이 열리는 순간 요구사항도 함께 열리는 셈이다. 실제 구축 건에서도 오픈 직후 여러 요청이 대행사를 거쳐 한꺼번에 전달되었고, 이 요청을 어떻게 나누느냐가 프로젝트의 마무리를 결정했다.
오픈 다음 날부터 시작되는 요청 목록
대시보드가 열리면 광고주는 비로소 자신의 데이터를 눈으로 확인하게 된다. 그 순간부터 보이지 않던 것이 보이고, 보였으면 하는 것이 새로 생긴다. 이번 구축 건에서 들어온 요청은 리포트 자동 메일링, 평균 CPC 계산에서 브랜딩 목적 캠페인 제외, 연초부터의 과거 데이터 소급, 연결된 전체 데이터의 CSV 다운로드, 특정 판매 채널의 협력광고가 보이지 않는 문제, 소재 성과를 실제 이미지와 함께 보는 기능까지 여섯 갈래였다. 요청의 성격이 제각각이라 하나의 기준으로 묶어 답하기는 어려웠다.
이 항목들을 그대로 접수해 순서대로 처리하면 작업 범위가 통제되지 않는다. 계약서에 없는 작업이 섞여 들어가고, 이미 보류하기로 합의했던 항목이 다시 떠오르는 경우도 생긴다. 그래서 요청이 들어온 순서가 아니라 항목별 성격에 따라 분류하는 절차가 먼저 필요했다.
요청을 나누는 세 가지 기준
항목마다 세 가지를 확인했다. 첫째는 구현이 가능한지 여부, 둘째는 계약 범위 안인지 밖인지, 셋째는 처리에 필요한 작업과 공수다. 이 세 가지를 먼저 정리하면 항목별로 답이 자연스럽게 갈린다. 예를 들어 데이터 다운로드 기능은 계약 범위가 이미지와 PDF 형식으로 한정되어 있었기 때문에, 연결된 전체 데이터를 CSV로 내려받는 요청은 범위 밖 추가 작업으로 분류되었다. 반대로 리포트 자동 메일링이나 평균 CPC 계산에서 브랜딩 캠페인을 제외하는 요청은 기존 계약 범위 안에서 설정만 조정하면 되는 항목이었다.
특정 판매 채널의 협력광고가 보이지 않는다는 요청은 처음에는 기능 오류로 받아들여질 수 있었다. 그러나 확인해 보니 대시보드 기능의 문제가 아니라 해당 채널의 원본 데이터인 CSV를 아직 받지 못한 것이 원인이었다. 기능이 아니라 데이터 공급 단계에서 막혀 있었던 셈이다. 이런 경우 기능 수정이 아니라 데이터 수급 경로를 다시 확인하는 쪽으로 방향을 잡아야 했다. 과거 데이터 소급 요청도 마찬가지였다. 매체 API마다 소급 가능한 기간이 정해져 있어, 그 기간 안쪽은 바로 반영하고 기간을 넘는 구간은 별도로 CSV를 받아 처리하는 방식으로 안내했다.
| 요청 항목 | 가능 여부 | 범위 | 처리 방식 |
|---|---|---|---|
| 리포트 자동 메일링(일·주·월) | 가능 | 범위 안 | 기존 설정 반영 |
| 평균 CPC 계산에서 브랜딩 캠페인 제외 | 가능 | 범위 안 | 계산식 수정 |
| 연초부터 과거 데이터 소급 | 매체 API 기간 내 가능 | 일부 범위 밖 | API 기간 초과분은 CSV로 수령 |
| 연결 전체 데이터 CSV 다운로드 | 가능 | 범위 밖 | 추가 견적 |
| 특정 판매 채널 협력광고 미노출 | 원인 확인 필요 | 범위 안(원인은 데이터 미수신) | 원본 CSV 수령 후 반영 |
| 소재 이미지와 함께 보는 기능 | 가능 | 범위 밖(착수 단계 보류 이력) | 추가 견적 |
이력이 범위를 지키는 이유
소재 이미지와 함께 보는 기능은 새로 나온 요청처럼 보였지만, 실제로는 착수 단계 협의에서 이미 다음 범위로 넘기기로 정리된 항목이었다. 광고주 측 담당자가 바뀌면서 이 결정이 전달되지 않았을 가능성이 컸다. 담당자 교체는 프로젝트 진행 중 흔히 벌어지는 일이고, 그때마다 과거 합의 내용이 새 담당자에게 온전히 전달되리라고 기대하기는 어렵다. 이런 상황에서 근거가 되어 준 것이 당시 협의 기록이었다. 착수 단계에서 어떤 항목을 범위에 포함하고 어떤 항목을 다음 단계로 미뤘는지 문서로 남겨 두었기 때문에, 같은 요청이 다시 들어왔을 때 처음부터 다시 논의하지 않고 기존 합의를 근거로 안내할 수 있었다.
검수 보고서에 광고주 측 조치 대기 항목과 범위 외 항목을 구분해 기록해 둔 것도 같은 역할을 했다. 구축이 끝난 뒤에도 요청은 계속 들어오고, 그때마다 기억에 의존해 설명하면 담당자에 따라 답이 달라질 위험이 있다. 반면 문서로 남은 기록은 누가 응대하든 같은 기준으로 설명할 수 있게 해 준다. 범위를 지키는 힘은 결국 그 순간의 판단이 아니라, 과거에 남겨 둔 기록에서 나온다.
요청 처리의 결론
오픈 후 들어오는 추가 요청은 피할 수 있는 일이 아니다. 중요한 것은 요청이 들어왔을 때 가능 여부, 계약 범위, 소요 공수라는 세 기준으로 먼저 정리하는 절차다. 이 기준을 표 한 장으로 만들어 회신하면 항목별로 무엇이 바로 반영되고 무엇이 추가 견적 대상인지가 명확해진다. 또한 착수 단계의 협의 기록과 검수 보고서를 문서로 남겨 두면, 담당자가 바뀌거나 시간이 지나도 범위 논쟁 없이 같은 기준으로 설명할 수 있다.
자주 묻는 질문 (FAQ)
오픈 직후 도착하는 추가 요청은 모두 처리해야 하는가
요청은 모두 접수하되 처리 여부는 구현 가능성과 계약 범위에 따라 따로 판단한다. 범위 안 항목은 기존 공수에서 반영하고, 범위 밖 항목은 추가 견적 대상으로 분리한다.
기능 문제처럼 보이는 요청이 실제로는 다른 원인일 수 있는가
가능하다. 특정 판매 채널 데이터가 보이지 않던 사례는 기능 오류가 아니라 원본 데이터인 CSV를 아직 받지 못한 것이 원인이었다. 처리에 앞서 원인 확인이 먼저 이루어져야 한다.
착수 단계에서 보류한 항목이 다시 요청으로 들어오면 어떻게 하는가
착수 단계 협의 기록과 검수 보고서에 남긴 범위 외 항목 목록을 근거로 다시 안내한다. 담당자가 바뀌어도 기록이 있으면 범위 논쟁 없이 설명할 수 있다.
대시보드 오픈 이후의 요청 관리까지 포함한 구축 설계가 필요하다면 상담을 통해 범위와 견적 기준을 함께 정리할 수 있다.
