DMで受けていた依頼業務を管理画面に置き換えた——処理速度と安心感が同時に上がった経緯
依頼業務は、構造化するだけで体験が変わる
ネイルチップマーケットの公式Instagramでは出品しているクリエイターを紹介する投稿を続けています。
依頼の受付は最初InstagramのDMでやっていました。クリエイターと運営が画像と紹介文をやり取りする。掲載してもよいかを文面で確認する。投稿後にURLをスプレッドシートに転記する。
これをフォームと管理画面に置き換えました。やっていることは同じです。依頼を受けて、確認して、投稿する。それだけ。
でも運営の処理速度と依頼者の安心感、そして属人化の解消が同時に進みました。今回はその「何が変わったか」を整理します。
運営の処理速度——1件あたりの工数が目に見えて減った
DMで運用していたとき依頼1件にかかっていた工数を分解するとこうでした。
- DMの通知に気づく
- スレッドを開いて内容を読む
- 画像をダウンロードする
- テキストをコピーする
- 掲載許諾の文面を遡って確認する
- スプレッドシートに転記する
- 投稿のためのデザインに反映する
- 投稿後、URLを別のスプレッドシートに書き戻す
ひとつひとつは数十秒の作業です。 ただ、これが1件のなかに8ステップ点在していてしかも全部「手作業のコピペ」でつながっている。件数が増えると依頼そのものに使う時間より依頼を扱うための周辺作業のほうが長くなっていく。
フォームに置き換えてから変わったのはこの周辺作業がほぼ消えたことでした。
依頼が送られてくると、画像とアピール文と掲載許諾が最初から構造化された状態で1件のレコードになって届きます。コピペは要りません。 状態が変わるたびに「申請中／確認中／プレビュー送付／公開済み」のラベルが自動で動きます。誰が何の段階の依頼を抱えているかが一覧画面を開いた瞬間にわかる。
修正依頼が来たときにはSlackに自動で流れる仕組みも入れました。気づくのが遅れることがなくなりました。
体感では依頼1件あたりの運営工数は半分以下になりました。件数が3倍になっても、回り続けるようになりました。
依頼者の安心感——「いまどうなっていますか」が消えた
もうひとつ大きく変わったのが依頼を出した側の体験です。
DMで依頼を受けていたとき依頼者から定期的に届くメッセージがありました。
「先日お願いした件、いまどうなってますか？」
責められているわけではありません。送ったあとは何も見えないから聞くしかないだけです。当然のことです。
新しい仕組みでは依頼者は自分のマイページから依頼の段階を直接見られます。下書き／申請中／確認中／プレビュー送付／公開済み／修正依頼中。どこまで進んでいて、次は何が起きるのかがログインすればわかる。
なかでも効いたのが「プレビュー送付」の段階でした。
投稿のレビューには、Figmaを使っています。運営がFigmaで投稿用のデザインを組みそのまま共有用のプロトタイプのリンクを依頼者に送る。 依頼者はリンクを開けば実際に投稿される見た目に近い状態をそのまま確認できる。文字の位置、写真の見え方、紹介文のニュアンス。投稿が出る前に「これで出します」を依頼者と運営が同じ画面を見ながら合意できるようになりました。
Figmaを選んだのは依頼者側に新しいアカウントを作らせなくていいからです。送られてきたリンクをタップするだけで依頼者は完成形に近い画面を見られる。 デザインを画像で書き出して送るのとは違って後から運営が一箇所だけ直したいときもリンクはそのままで中身を更新できる。
これを入れてから「いまどうなっていますか」のメッセージはほぼ来なくなりました。依頼者にとっては聞かなくていい状態になった。運営にとっては、その都度返信していた時間がなくなった。
両方の負担が同時に減りました。
依頼者の不安はたいてい「相手が見えていないこと」から来ます。何も難しい仕掛けはしていません。状態と完成イメージを見える場所に置いただけです。それだけで、関係性の温度が変わりました。
属人化の解消——「あの人しかわからない」がなくなった
DM運用で実は一番やっかいだったのが属人化でした。
依頼のやり取りが特定の運営メンバーのDMに閉じてしまう。誰がどの依頼を抱えているのか本人以外からは見えない。担当者が休みの日に来た依頼や修正依頼は出社するまで止まる。引き継ぎをしようにも、DMの履歴を遡って読み返してもらう必要があって引き継ぐほうも引き継がれるほうも気が重い。
「あの依頼、〇〇さんに聞かないとわからない」という状態が件数とともに増えていきました。
フォームに置き換えてからこの状態は自然になくなりました。
依頼の中身、画像、アピール文、掲載許諾の有無、いまの段階、依頼者とのやり取りメモ、運営側のメモ。これが全部、依頼1件ごとに同じ場所にまとまっています。誰が開いてもその依頼が今どの状態にあって次に何をすればいいかが見ればわかる。
担当者が休んでも誰かがそのまま続きを進められる。新しいメンバーが入っても過去の依頼を見れば「こういう温度感でやり取りしているんだ」が伝わる。引き継ぎ資料を作る必要がない。
属人化はサボっていたから生まれていたわけではありません。DMという「個人に紐づく場所」で運用していたから構造的にそうなっていただけでした。場所を「依頼に紐づく場所」に移したら属人化のほうが消えていったという感覚に近いです。
自動化されたところ、されていないところ
念のため書いておくとすべてを自動化したわけではありません。
依頼の中身を読んでこれは紹介に向いているか判断する。Figmaで投稿用のデザインを組む。紹介文を整える。このあたりは、引き続き運営が手で触っています。クリエイターを紹介する投稿は機械的に流すものではなく温度のあるものとして出したいという方針があるからです。
自動化したのはその手前と後ろです。
受け取る、整理する、ステータスを動かす、依頼者に進捗を見せる、修正依頼を通知する、投稿後のURLを依頼に紐づけて記録する。この「定型でいいところ」を全部仕組みに任せて運営が考える時間を確保する側に倒しました。
判断の部分は人がやる。整理と通知は仕組みがやる。この線引きがはっきりしてから運営の動きが軽くなりました。
構造化は、複数の課題を同時に底上げする
新しいSaaSを入れた話ではありません。自分たちのデータベースに依頼1件ぶんのレコードを作ってクリエイター用と運営用の画面を1枚ずつ足しただけです。
それでも依頼1件あたりの処理時間は半分以下になり、依頼者からの「いまどうなっていますか」は消え、修正依頼の見落としもなくなり「あの人しかわからない」もなくなりました。
依頼業務は運営と依頼者という二者がいて両方が情報を持ちたい仕事です。情報の置き場所が個人のDMから「依頼そのもの」に移ると、処理速度も依頼者の安心感も属人化の解消も同じ一枚の仕組みで一気に進みます。
DMやチャットで依頼を回している事業者は多いと思います。件数が増えてきたとき、運営の手数を減らすためだけでも依頼者の体験を上げるためだけでも特定のメンバーに集中している業務をほどくためだけでもなく、これらを同時に底上げできる打ち手として構造化は割に合うと考えています。