承認ワークフローツール、代理店のあらゆる判断を一つの受信箱で

承認ワークフローツールの承認マトリクス：誰が、どの権限で、何を決めるか

最初のローンチの前に一度決めておけば、あとで「誰が承認すべきだったか」で揉める時間が短くなります。表は、コンソールが現在強制している内容を、行ごとに示します。

初期設定では、代理店チームのメンバーは、ライブラリのアセットとプランを表示、作成、編集できます。つまりプランを承認に提出することはできても、承認や公開はできません。メールやSMS キャンペーンのローンチを依頼するには、依頼者にCRMのアクセス権も必要ですが、チームメンバーには初期設定で付与されていません。代理店管理者はすべての権限を持ちます。管理者は、「Approve」や「Publish」を、一人ずつ、または権限テンプレートを通じて、リーダーに付与でき、チームメンバーが操作できるのは、割り当てられたクライアントだけです。休暇の判断は、そもそも委任できません。

提出者、レビュー担当者、承認者、公開担当者、依頼者を、分かりやすく

同じ五つの言葉が、すべてのタブに出てきます。それぞれが意味するものは一つです。

提出者

プランを承認に送る人です。編集して提出できますが、代理店管理者でない限り、自分のプランを自分で承認することはできません。

レビュー担当者

提出者がプランに指名する人です。この名前は参考で、誰に知らせるか、レビューのタスクを誰が持つかを決めますが、承認者なら誰でも判断できます。

承認者

そのクライアントの「Approve」権限を持つ人です。承認者は、ライブラリのレビューとプランの承認を判断します。

公開担当者

そのクライアントの「Publish」権限を持つ人です。公開担当者は、承認済みのプランをローンチし、ローンチ依頼を判断し、クライアントにライブラリのアセットのレビューを依頼します。

依頼者

「Publish」権限を持たずにローンチを依頼した人です。待機中は、自分の依頼を取り下げられます。

サインオフを、チャットやメールから四つの手順で移す

人は、すでに話をしている場所で承認を続けます。展開がうまくいくのは、メッセージよりも受信箱のほうが楽なときなので、一つのクライアントと、一種類の判断から始めます。

1. 1

   今出している「承認」を書き出す

   一週間のあいだ、チャットやメールで行われるサインオフをすべて書き留めます。クリエイティブ、ランディングページ、キャンペーン、ローンチ、休暇などです。受信箱が扱う四つのものに仕分け、残りはそのままにします。

2. 2

   クライアントごとに承認者を決める

   クライアントごとに、誰がプランを承認し、誰が公開するかを選び、その権限を付与して、その人たちをクライアントに割り当てます。クライアントに割り当てられていないメンバーには、その仕事が受信箱に表示されません。

3. 3

   一つのクライアントで二週間試す

   提出者には、レビュー担当者を指名し、理由をメモに書いてもらいます。誰かがチャットで承認を求めてきたら、受信箱にあると答えて、そこで判断します。レビューのタスク、通知ベル、メールがすでにレビュー担当者に知らせているので、たいていは促さなくても伝わります。

4. 4

   受信箱を唯一の承認の場にする

   二週間たったら、次のクライアントに移します。承認されたプランのないローンチは、どのみちコンソールが拒否することをチームに伝え、毎日を「All」のタブから始めて、ゼロより大きい件数を最初の仕事として扱います。

「Changed since approval」が守ってくれるもの

この警告は、小言ではありません。プランが、誰かが合意したものではなくなった瞬間を示します。

比較の対象は三つです。プラン自体、メールキャンペーン設計のプランが送るライブラリのメールテンプレート、そしてメール、SMS、運用型広告のプランの背後にある保存済みのオーディエンス（その定義と、固定リストの場合は含まれる人）です。どれか一つの編集でも対象で、ほかのキャンペーンと共有しているテンプレートの編集も含まれます。ルールで定義されたセグメントは、送信日までに別の人に一致することがありますが、それで承認が古くなることはありません。承認待ちのあいだに編集された提出は承認できず、その行に、もう一度提出する必要があると表示されます。

知っておくべき限界が二つあります。ローンチが予約されたあとでプランが編集された場合、ディスパッチャーは動く直前にもう一度比較し、ローンチは分かりやすい説明とともに失敗して、何も送られません。また、ライブラリのアセットは仕組みが違います。アセットが持つのは内容のフィンガープリントではなくレビューのステータスなので、承認済みのアセットを編集しても、そのレビューはそのままです。作業が変わったときは、レビューを開き直してください。

承認者のための、受信箱の十分間の見回り

受信箱は、上から片づけていくように作られています。この順序なら、ほかの人を止めている判断を先に処理できます。

1. 1

   「All」から始める

   タブの件数を読みます。ヘッダーの切り替えでクライアントの絞り込みが一つのアカウントに絞られている場合は、先に広げます。忘れていた絞り込みの陰で何かが待つことがないようにするためです。

2. 2

   ローンチ依頼を先に処理する

   誰かが公開を待っています。チェックと一行の影響の説明を読み、承認するか、理由を添えて却下します。不合格のチェックはダイアログに表示され、承認を保留にします。

3. 3

   次にプラン

   各プランを、その行から開きます。提出後に編集された印が付いた行は承認できないので、待たずに再提出を求めます。何を変えるかを書いたメモを添えて、変更を依頼します。

4. 4

   次にライブラリ

   各レビューを、クライアントに見える状態で開きます。承認する、変更を依頼する、または承認を省略します。省略は、誰もそのアセットをレビューしなかったことを記録するもので、承認済みとは表示されません。指したい位置にコメントをピンで留めます。

5. 5

   最後に休暇と「Also waiting」

   休暇は管理者が最後に判断し、却下には必ず理由を付けます。「Also waiting」のカードにタイムシートの入力や予約スクリプトのリビジョンが表示されていたら、そのリンクから工数または予約スクリプトを開きます。

見回りを短くする習慣は三つあります。メモを付けて提出すること、レビュー担当者を指名すること、チャットではなく受信箱で判断することです。受信箱は、タブに戻るたびと、開いているあいだは毎分、読み直されるため、開いたままにしておいて、戻ってきたときに最新の件数を見られます。

受信箱が行わないこと：誰も誤解しないように

判断のキューが信頼できるのは、その境界がはっきりしているときだけです。

• 受信箱は、リマインダーを送らず、エスカレーションもしません。プランが提出されると、通知ベルが鳴り、レビュー担当者に、指名がなければそのクライアントのすべての承認者にメールが届き、三日後が期限のレビューのタスクが作られるので、プロジェクト管理ツールにあるそのタスクの日付が催促になります。平日に既定で送られる朝のサマリーには、自分の判断を待つライブラリのレビュー、工数の入力、休暇も載りますが、プランとローンチ依頼は載りません。ライブラリの提出は承認者に通知されますが、タスクは作られません。項目は、誰かが判断するまで待ちます。
• メールを除き、現状では、代わりに投稿したり送信したりはしません。運用型広告、SNS、SMSのローンチは、手作業で行ったものとして記録されます。承認すると、固定した仕様のタスクと書き出しが作られ、誰かがローンチ済み、公開済み、送信済みにします。例外はメールのローンチで、これは送信します。
• タイムシートや予約スクリプトの判断はしません。それらは「Also waiting」で数えられ、それぞれのツールで判断されます。
• プラン、ローンチ、受信箱をクライアントに見せることはありません。クライアントがポータルで見るのは、共有したライブラリのアセットで、依頼したものをレビューします。
• 各自には、見られるクライアントだけが表示されます。「Approve」と「Decline」が表示されるのは権限を持つ場所だけで、判断できない待機中のプランやローンチの行には、誰が判断できるかが表示され、「Time off」のタブが表示されるのは管理者だけです。
• ローンチが完了したプランを、再びローンチすることはできません。もう一度送るには、プランを複製し、複製を承認します。失敗した、取り消された、または却下されたローンチは、やり直せます。

クライアント自身の承認が入る場所

プランとローンチは社内の判断です。クライアントのサインオフが適用されるのは、共有したライブラリのアセットです。

1. 1

   先に社内で承認する

   アセットをクライアントに共有できるのは、代理店の承認者が承認するか、承認を省略したあとです。承認の仕組みができる前にすでに共有されていたアセットは、共有済みと表示され、ブロックされることはありません。

2. 2

   共有してから、レビューを依頼する

   「Publish」権限を持つ人がアセットを共有し、クライアントのレビューを依頼します。依頼と一緒にクライアントが見る任意のメモを添えられます。共有とされたコメントも、クライアントに見えます。

3. 3

   クライアントはポータルで回答する

   クライアント管理者が承認し、ポータルのどのメンバーも変更を依頼できます。どちらも、クライアントに見えるとおりのアセット上で行い、指したい位置にコメントをピンで留められます。

4. 4

   取り消す、開き直す、もう一度頼む

   クライアントは、承認を一時間以内なら取り消せます。変更の依頼のあとは、編集してもう一度依頼します。アセットがクライアントの手元にあるあいだは依頼を取り下げられ、承認または省略されたあとは、レビューを開き直せます。

受信箱では、これらのアセットは、クライアントが承認するまで「Library」タブの「With the client」の下にあり、承認後は「Decided」の下に移ります。クライアントが変更を依頼した場合は、もう一度依頼するか依頼を取り下げるまで、「With the client」にとどまります。クライアントのレビューにはクライアントポータルが必要で、ScaleとEnterpriseのプランに含まれます。アートワークはよくある例で、クリエイティブ管理ツールで、バージョンとレビューがクリエイティブ自体にどう結びつくかを確認できます。