「人が気づく」から「仕組みが気づく」へ。サポート課の業務改善を追ってみた

BPO事業部 部長の小林です。

これまでの記事では、BPO事業部の「サポート課」がどのような仕事をしているのか、そして私たちがなぜ「仕組み化」にこだわっているのかをご紹介してきました。

でも、「業務改善」「仕組み化」と言われても、

「実際、どんなことをする仕事なの？」

となかなかイメージしづらいですよね。

そこで今回は、実際にサポート課で取り組んだ業務改善を一つ取り上げて、現場で起きたことをどのように整理し、仕組みに変えていったのかをご紹介します。

今回のテーマは、あるBPO案件で案件管理に使用している「タスク管理ツール」です。

🔔 きっかけは「通知されないケース」でした

あるBPO案件では、タスク管理ツールを使ってクライアントとの案件管理を行っています。

コメントを受け取った際には、担当者へのメンションやステータス変更によって通知が届き、必要な対応を行うという運用です。

ところがある日、コメントは追加されていたものの、メンションもステータス変更もされていない案件が発生しました。

そのため通常の通知が発生せず、担当側がコメントに気づくまでに時間がかかり、結果として対応が遅れてしまいました。

もちろん、通常の運用では、決められたルールに沿ってメンションやステータス変更を行うことが基本です。

ただ、今回考えたのは、通常とは異なるケースが発生したときに、それをどうやって検知するかということでした。

🤔 すべての案件を、人が一件ずつ確認する？

今回のようなケースに気づくために、まず考えられるのは、担当者がタスク管理ツールを定期的に開き、すべての案件を一件ずつ確認する方法です。

もちろん、通常の運用ルールに沿ってメンションやステータス変更が行われることが基本です。

一方で、イレギュラーなケースに備えて、担当者がすべての案件を毎日確認する運用を追加するとなると、別の課題が出てきます。

案件数が少ないうちは対応できても、案件数が増えれば確認する量も増えていきます。

さらに、確認する案件のほとんどが問題なく進んでいるのであれば、「何か起きていないか」を探すために、人が毎日すべての案件を見続けることになります。

それでは、案件数が増えるほど確認作業も増え、人の注意力にも依存する運用になってしまいます。

そこで私たちは、「人がすべての案件を確認する」のではなく、「確認が必要な案件だけを仕組みが見つけて知らせる」ことはできないか？

と考えました。

「人が停滞している案件を探しに行く」のではなく、「停滞している案件の方から知らせてもらう」。

ここから、今回の仕組みづくりが始まりました。

💡 何をもって「停滞」とする？

方向性が決まったら、次は具体的な条件を考えます。

例えば、「対応依頼」というステータスになった案件があるとします。

対応依頼になってから2日未満なら、そのまま。
2日以上経過しているのであれば、「対応が止まっている可能性がある案件」としてアラートを出す。

一見するとシンプルですが、ここでも一つ考えなければならないことがありました。

それは、「何を基準に2日間と判断するのか？」ということです。

単純に「最終更新日」を使ってしまうと、途中でコメントが追加されたり、担当者が変更されたりしただけでも日付が更新されます。

でも、私たちが知りたいのは、「最後にいつ更新されたか」ではなく、「その案件がいつから同じステータスにとどまっているのか」です。

コメントが追加されていても、「対応依頼」の状態がずっと変わっていなければ、対応すべき案件としては停滞している可能性があります。

そこで、現在のステータスになった日時を基準に、どれくらいの期間その状態が続いているのかを判定することにしました。

こうして、現場で起きている「困った」を、少しずつ仕組みにするための条件へ落とし込んでいきます。

🛠 Power Automateで「停滞」を自動検知

条件が整理できたら、今度は実際に形にしていきます。

今回はPower Automateを活用し、案件管理に使用しているタスク管理ツールから、一定期間ステータスが変化していない案件を自動で検知する仕組みを構築しました。

仕組み自体は、

毎日決まった時間に自動実行
→ 対象となる案件を確認
→ 現在のステータスを確認
→ いつそのステータスになったのかを確認
→ 滞留している日数を計算
→ 基準を超えていたらTeamsへ通知

というものです。

例えば、「対応依頼」の状態が設定した期間以上続いている案件があれば、
「○○の案件が『対応依頼』の状態で一定期間停滞しています」
と担当チームのTeamsへ自動でアラートが届きます。

これなら担当者がすべての案件を毎日確認しなくても、確認が必要な案件を仕組みの側から知らせてもらうことができます。

大切なのは、Power Automateを使うことそのものではありません。
現場で起きている問題を整理して、
「どういう状態になれば、この問題を防げるのか？」
を考え、それを実現する方法としてツールを使っています。

🔍 作ったら、まず試してみる

仕組みを作っても、そこで完成ではなく、実際に想定通り動くのかを確認します。

今回も、まずはアラートが発生するまでの時間を短く設定し、テスト用の条件で正常にTeamsへ通知されるかを確認しました。
正常に通知されることが確認できたら、本来の判定時間へ戻し、今度は実際の運用環境でテストします。
そこで問題がなければ、他の案件管理にも展開していく予定です。

さらに今後は、
「対応依頼なら○日」
「再提案待ちなら○日」

というように、ステータスごとに許容する滞留日数を設定できる状態を目指しています。

一つの問題を解決して終わりではなく、他の案件でも使える仕組みにしていく。
これもサポート課が大切にしていることの一つです。

🤝 業務改善は、サポート課だけではできない

今回の改善も、サポート課だけで突然「こんなシステムを作ろう」と考えたわけではありません。

始まりは、実際に業務を運営している現場で起きた出来事でした。
オペレーション側で何が起きたのかを整理し、どうすれば同じようなことを防げるのかを考える。
その中で、運用だけではなく仕組みで補完できる部分について、サポート課がシステムとして形にしていく。

そして完成したものを再び現場で使ってもらい、必要があれば改善する。
現場を一番よく知っているオペレーション課と、仕組みを考えるサポート課。
それぞれが役割を持ち、一緒に改善を進めていきます。

だからサポート課の仕事は、パソコンに向かってシステムを作るだけの仕事ではありません。
現場の話を聞き、課題を整理し、関係者と相談しながら、実際に使えるところまで持っていくことが必要になります。

💡 「人が気づく」から「仕組みが気づく」へ

今回の改善も、最初から、
「Power Automateを使って停滞アラートを作ろう！」
と決まっていたわけではありません。

始まりは、
「通常の通知が発生しないケースでも、必要な対応に気づけるようにできないか？」
という一つの課題でした。

そこから、

なぜ気づくことができなかったのか。
ルールだけで防ぐことができるのか。
人が毎回確認しなくても済む方法はないか。
何を「停滞」と判断すればいいのか。
どうすれば現場で実際に使えるのか。

一つずつ考えた結果が、今回の仕組みです。

サポート課の仕事には、最初から答えが用意されていないことがたくさんあります。
だからこそ、
「これ、もっと良くできないかな？」と考えることが、仕事のスタートになります。

人が頑張って気づくのではなく、仕組みが気づいて、人を支えてくれる状態をつくる。

現場の小さな「困った」を見つけ、その原因を考え、実際に使える仕組みに変えていく。

それが、私たちサポート課の仕事です。

仕組み化や業務改善が好きな方、自分で考えて何かをより良くしていくことが好きな方。少しでもサポート課の仕事に興味を持っていただけたら、ぜひ一度カジュアル面談でお話ししませんか？

あなたの「もっとこうしたい」を、ぜひ聞かせてください。

記事を書いた人

元ウェディングプランナーの事業部長が語る、0から組織を創る醍醐味とAIに負けない"人の感情"を動かすサポートの真髄とは？ | メンバーインタビュー

こんにちは！今回は、株式会社ウィリッチの創業メンバーであり、現在はBPO事業部長を務める小林にインタビューしました。「教科書通りを着実に」と語る独自の組織論や、AI時代におけるカスタマーサポート...

https://www.wantedly.com/companies/company_1651955/post_articles/1063936