ツールを共有して、招待メールも送った。最初の1週間は開いてくれていた。
それがいつの間にか確認が止まり、Slackに「進捗どうですか？」と聞くと「ああ、ちゃんと見てますよ」と返ってくる。でもツールのアクセスログを見ると、2週間ほど動きがない。
これは、よくあることだ。
ツールを「開かなくなる」には、理由がある
クライアントがツールを開かなくなったとき、「使い方を覚えてもらえなかった」「やる気がない」という方向に考えが向きやすい。
しかし実際には、使い手の問題である場合はほとんどない。
開かなくなる理由は、ほぼ3つに集約される。
理由1：「通知が届いていない」
タスクが更新されたとき、コメントが入ったとき——そのたびに通知が来る設定になっていれば、クライアントは自然に開く。通知が来なければ、能動的に確認しなければならない。
能動的な確認は、習慣になるまでが難しい。特にプロジェクトがひとつではなく、複数の会社・担当者とやりとりしているクライアントにとって、ツールごとにログインして確認するという行動はコストが高い。
対処は単純だ。招待したあと、「メール通知の設定が届いているか」を確認する。最初の共有タスクに対してコメントを入れ、「通知きましたか？」と聞く。ここで届いていなければ、スパムフォルダの確認や通知設定の変更を案内する。
通知が機能していれば、多くの場合ここで解決する。
理由2：「確認しなくても進んでいる」
ツールを見なくても、メッセージで連絡が来て、仕事は回っている。
このとき、クライアントの立場から見ると「ツールを開く必要がない」という状態だ。合理的な判断として、確認しなくなる。
これは、使い方の設計に問題がある。
ツールを「共有している」だけで、クライアントがそこで何かを「決める・承認する・フィードバックする」設計になっていない場合、ツールは記録場所にしかなっていない。記録場所は、記録をつける側しか開かない。
解決策は、クライアントの判断が必要なタスクをツール上に置くことだ。たとえば「この方向性でよいか、コメントをください」「こちらの案を承認してください」という形のタスクがあれば、クライアントには「開かないと答えられない」理由が生まれる。
ツールへの参加を形式的なものにしない。クライアントが「動く場所」として機能させる。
理由3：「使い方がわからないまま止まった」
招待メールを送って「あとはよろしく」にした場合、ログイン方法、どこを見ればいいか、どう操作すればいいかがわからないまま放置された可能性がある。
わからないことをわざわざ聞いてくれるクライアントは少ない。「聞くのも手間だし、まあ後で」となって、そのまま開かなくなる。
これは最初の案内の問題だ。招待後に「このリンクから開くと、担当案件の一覧が見えます。最初のタスクに一度コメントを入れてもらえますか？」という一文を送るだけで、最初の動作を確認できる。
最初の1アクションを経験してもらうことが、使い続けてもらうための最低条件だ。
診断の順序
クライアントがツールを開かなくなったとき、責める前に診断する。
まず確認すること：通知設定は機能しているか。次に問うこと：クライアントが「ここで動く理由」がある設計になっているか。最後に振り返ること：最初の案内で、一度使う体験を作れていたか。
この3つのうちどれかが欠けていることがほとんどだ。
ツール自体の問題である場合は少ない。設計と案内の問題であることがほとんどで、どちらも直せる。
「使わないなら使わなくていい」は損失だ
クライアントがツールを開かなくなると、制作側だけが使うツールになる。そうなると、クライアントへの連絡はSlackやメールに戻る。ツールとコミュニケーションが分離して、「あの件、どこで話したか」という状態が生まれる。
クライアントとの案件をツール上で完結させることのメリットは、「振り返れること」と「引き継げること」だ。チャットに流れていくと、案件が終わったときに残るものが何もない。
クライアントが開かなくなったとき、放置するより、一度立ち止まって理由を探す方が早い。ほとんどの場合、小さな設計の修正で動き始める。
クライアントが自然に開くタスクボードの設計から始めるなら、Paqutはクライアントを何人招待しても追加費用なし、月額¥2,980のフラット料金で使えます。まず進行中の案件1件でクライアントを招待してみてください。