승인 워크플로, 대행사의 모든 결정을 하나의 인박스에서 내립니다

승인 워크플로의 승인 매트릭스: 항목별 결정 주체와 필요한 권한

첫 실행 전에 한 번 정해 두면, 누가 무언가를 승인했어야 하는지에 대한 이후의 모든 논쟁이 짧아집니다. 표는 콘솔이 오늘 실제로 강제하는 내용을 행마다 적었습니다.

기본적으로 대행사 팀원은 라이브러리 자산과 플랜을 보고, 만들고, 수정할 수 있으므로 플랜을 승인을 위해 제출할 수는 있어도 승인하거나 게시할 수는 없습니다. 이메일이나 문자 캠페인의 실행을 요청하려면 요청자에게 CRM 접근 권한도 필요한데, 팀원에게는 기본으로 이 권한이 없습니다. 대행사 관리자는 모든 권한을 가집니다. 관리자는 팀장에게 “Approve”(승인 권한)나 “Publish”(게시 권한)를 한 사람씩, 또는 권한 템플릿으로 부여할 수 있고, 팀원은 배정된 클라이언트에 대해서만 행동합니다. 휴가 결정은 아예 위임할 수 없습니다.

제출자, 검토자, 승인자, 게시 권한자, 요청자를 쉬운 말로

같은 다섯 단어가 모든 탭에 나옵니다. 각각은 한 가지 뜻입니다.

제출자(Submitter)

플랜을 승인을 위해 보내는 사람입니다. 수정하고 제출하며, 대행사 관리자가 아니면 자신의 플랜을 승인할 수 없습니다.

검토자(Reviewer)

제출자가 플랜에 지정하는 사람입니다. 이 지정은 참고용입니다. 누구에게 알릴지와 검토 업무를 누가 맡을지를 정할 뿐이며, 어느 승인자든 여전히 결정할 수 있습니다.

승인자(Approver)

해당 클라이언트에 대한 승인 권한을 가진 누구나입니다. 승인자는 라이브러리 검토와 플랜 승인을 결정합니다.

게시 권한자(Publisher)

해당 클라이언트에 대한 게시 권한을 가진 누구나입니다. 게시 권한자는 승인된 플랜을 실행하고, 실행 요청을 결정하고, 클라이언트에게 라이브러리 자산 검토를 요청합니다.

요청자(Requester)

게시 권한 없이 실행을 요청한 사람입니다. 대기 중에는 자신의 요청을 취소할 수 있습니다.

승인을 채팅과 이메일에서 꺼내오는 네 단계

사람들은 이미 대화하는 곳에서 계속 승인합니다. 인박스가 메시지보다 쉬울 때 도입이 성공하므로, 클라이언트 한 곳과 결정 한 종류로 시작합니다.

1. 1

   오늘 하고 있는 승인 목록 만들기

   일주일 동안 채팅이나 이메일에서 이뤄지는 모든 승인을 적어 둡니다. 광고 소재, 랜딩페이지, 캠페인, 실행, 하루 휴가입니다. 이를 인박스가 담는 네 가지로 분류하고, 나머지는 그대로 둡니다.

2. 2

   클라이언트별 승인자 정하기

   클라이언트마다 플랜을 승인할 사람과 게시할 사람을 정하고, 해당 권한을 부여하고, 그 사람들을 클라이언트에 배정합니다. 클라이언트에 배정되지 않은 팀원은 그 클라이언트의 작업을 인박스에서 보지 못합니다.

3. 3

   클라이언트 한 곳으로 두 주 운영하기

   제출자에게 검토자를 지정하고 이유를 메모에 적게 합니다. 누군가 채팅에서 승인을 요청하면 인박스에 있다고 답하고 그곳에서 결정합니다. 검토 업무, 알림 벨, 이메일이 이미 검토자에게 알리므로 대부분의 검토자는 재촉하지 않아도 소식을 듣습니다.

4. 4

   인박스를 유일한 승인 창구로 만들기

   두 주 뒤에 다음 클라이언트로 넘어갑니다. 승인된 플랜이 없는 실행은 어차피 콘솔이 거부한다는 점을 팀에 알리고, 매일 “All”(전체) 탭에서 시작해 수치가 영보다 크면 그것을 첫 번째 일로 삼습니다.

“승인 후 변경됨”이 막아 주는 것

이 경고는 잔소리가 아닙니다. 플랜이 누군가 동의했던 그 플랜이 아니게 된 순간을 표시합니다.

비교는 세 가지를 읽습니다. 플랜 자체, 이메일 캠페인 기획이 보내는 라이브러리 이메일 템플릿, 그리고 이메일·문자·유료 광고 플랜 뒤에 있는 저장된 오디언스의 정의와, 고정된 리스트라면 누가 포함되어 있는지입니다. 이 가운데 무엇이든 수정하면 해당하며, 다른 캠페인이 공유하는 템플릿의 수정도 포함됩니다. 규칙으로 정의된 세그먼트는 발송일에 다른 사람과 일치하게 되더라도 그것만으로 승인이 “Changed since approval” 상태가 되지는 않습니다. 대기하는 동안 수정된 제출은 승인할 수 없으며, 행에는 다시 제출해야 한다고 표시됩니다.

알아 둘 한계가 둘 있습니다. 실행이 예약된 뒤에 플랜이 수정되면 디스패처는 동작하기 직전에 다시 비교하고, 실행은 쉬운 설명과 함께 실패하며 아무것도 발송되지 않습니다. 그리고 라이브러리 자산은 방식이 다릅니다. 자산에는 내용 지문 대신 검토 상태가 붙으므로, 승인된 자산을 수정해도 검토는 그대로 남습니다. 작업이 바뀌면 검토를 다시 엽니다.

승인자를 위한 십 분 인박스 점검

인박스는 위에서부터 비워 나가도록 만들어졌습니다. 이 순서는 다른 사람을 막고 있는 결정을 먼저 둡니다.

1. 1

   “All”(전체) 탭에서 시작하기

   탭의 수치를 읽습니다. 헤더 전환기가 클라이언트 필터를 계정 하나로 좁혀 놓았다면 먼저 넓혀서, 잊고 있던 필터 뒤에서 기다리는 항목이 없게 합니다.

2. 2

   실행 요청부터 처리하기

   누군가 게시를 기다리고 있습니다. 점검 결과와, 승인하면 어떻게 되는지 알려 주는 한 줄을 읽은 뒤 승인하거나 사유와 함께 반려합니다. 실패한 점검은 대화 상자에 나타나며 승인을 막습니다.

3. 3

   그다음 플랜

   행에서 플랜을 하나씩 엽니다. 제출 뒤에 수정되었다고 표시된 행은 승인할 수 없으므로, 기다리지 말고 다시 제출해 달라고 요청합니다. 수정을 요청할 때는 무엇을 고쳐야 하는지 적은 메모를 남깁니다.

4. 4

   그다음 라이브러리

   클라이언트가 보게 될 모습 그대로 검토를 하나씩 엽니다. 승인하거나, 수정을 요청하거나, 승인을 건너뜁니다. 건너뛰기는 아무도 그 자산을 검토하지 않았다는 사실을 기록하며 승인된 것으로 표시되지 않습니다. 댓글은 가리키려는 위치에 고정합니다.

5. 5

   휴가와 “Also waiting”(함께 대기 중)으로 마무리하기

   관리자는 휴가를 마지막에 결정하며, 반려마다 사유를 남깁니다. “Also waiting” 카드에 타임시트 항목이나 상담 스크립트 개정이 보이면 카드의 링크로 업무 시간이나 “Booking Scripts”(상담 스크립트)를 엽니다.

세 가지 습관이 점검을 짧게 유지합니다. 메모와 함께 제출하고, 검토자를 지정하고, 채팅이 아니라 인박스에서 결정합니다. 인박스는 탭으로 돌아올 때마다, 그리고 열려 있는 동안 매분 다시 읽으므로 열어 둔 채로 돌아와도 최신 수치를 볼 수 있습니다.

인박스가 하지 않는 일, 오해를 막는 한계 목록

결정 대기열은 한계가 분명할 때에만 믿을 수 있습니다.

• 인박스는 재알림을 보내지 않으며 상위 담당자에게 올리지도 않습니다. 플랜을 제출하면 검토자에게, 지정한 사람이 없으면 그 클라이언트의 모든 승인자에게 알림 벨이 울리고 이메일이 가며, 마감이 사흘 뒤인 검토 업무가 만들어지므로 프로젝트에서 그 업무의 날짜가 재촉 역할을 합니다. 기본적으로 평일에 발송되는 아침 요약에도 나를 기다리는 라이브러리 검토, 시간 기록, 휴가가 나오지만 플랜이나 실행 요청은 나오지 않습니다. 라이브러리 제출은 승인자에게 알리고 업무를 만들지 않습니다. 항목은 누군가 결정할 때까지 기다립니다.
• 이메일을 제외하면 지금은 대신 게시하거나 발송하지 않습니다. 유료 광고, SNS, 문자 실행은 직접 처리한 것으로 기록됩니다. 승인하면 업무와, 승인 시점으로 고정된 스펙을 내보낸 파일이 만들어지고, 누군가 집행 완료, 게시 완료, 발송 완료로 표시합니다. 이메일 실행은 예외이며 실제로 발송합니다.
• 타임시트와 상담 스크립트는 결정하지 않습니다. 둘 다 “Also waiting”에서 건수를 세고 각자의 툴에서 결정합니다.
• 플랜, 실행, 인박스를 클라이언트에게 보여 주지 않습니다. 클라이언트는 포털에서 대행사가 공유한 라이브러리 자산만 보고, 검토를 요청받은 자산만 검토합니다.
• 각 사람에게는 자신이 볼 수 있는 클라이언트만 보여 줍니다. “Approve”(승인)와 “Decline”(반려)은 권한이 있는 곳에만 나타나고, 결정할 수 없는 대기 중인 플랜이나 실행 행에는 누가 결정할 수 있는지가 적히며, 휴가 탭은 관리자에게만 나타납니다.
• 실행이 끝난 플랜을 다시 실행하지 않습니다. 다시 보내려면 플랜을 복제해 사본을 승인합니다. 실패하거나 취소되거나 반려된 실행은 다시 시도할 수 있습니다.

클라이언트 본인의 승인이 들어가는 자리

플랜과 실행은 내부 결정입니다. 클라이언트의 승인은 대행사가 공유한 라이브러리 자산에 적용됩니다.

1. 1

   먼저 내부에서 승인하기

   대행사 승인자가 승인했거나 승인을 건너뛴 자산은 클라이언트와 공유할 수 있습니다. 승인 기능이 생기기 전에 이미 공유된 자산은 공유됨으로 표시되며 막히지 않습니다.

2. 2

   공유하고 검토 요청하기

   게시 권한이 있는 사람이 자산을 공유하고 클라이언트의 검토를 요청하며, 요청과 함께 클라이언트가 보는 메모를 선택적으로 덧붙일 수 있습니다. 공유로 표시된 댓글도 클라이언트에게 보입니다.

3. 3

   클라이언트가 포털에서 답하기

   포털 관리자가 승인하고, 포털 구성원은 누구나 수정을 요청할 수 있습니다. 둘 다 클라이언트가 보는 자산 위에서 이뤄지며, 가리키려는 위치에 댓글을 고정할 수 있습니다.

4. 4

   철회, 재오픈, 다시 요청하기

   클라이언트는 한 시간 안에 승인을 철회할 수 있습니다. 수정 요청을 받으면 자산을 고치고 다시 요청합니다. 클라이언트에게 가 있는 동안에는 요청을 거둘 수 있고, 승인되었거나 건너뛴 뒤에는 검토를 다시 열 수 있습니다.

인박스에서는 이 자산들이 클라이언트가 승인하기 전까지 라이브러리 탭의 “With the client”(클라이언트 검토 중) 아래에 있다가, 승인되면 “Decided”(결정 완료) 아래로 옮겨 갑니다. 클라이언트가 수정을 요청하면 다시 요청하거나 요청을 거둘 때까지 “With the client” 아래에 남습니다. 클라이언트 검토에는 Scale과 Enterprise 요금제에서 제공하는 클라이언트 포털이 필요합니다. 아트워크가 흔한 사례이며, 광고 소재 관리에서 버전과 검토가 광고 소재 자체에 어떻게 붙는지 볼 수 있습니다.