経営者に集中していた問い合わせを、開発部で回る形へ
CS・営業から上がる不具合対応がすべて経営者を経由していた状態を、フロー整備と判断基準の文書化で解消。開発部だけで完結できる範囲を広げ、経営者が事業に向き合う時間を取り戻しました。
課題
CS部・営業部から上がる不具合や仕様の問い合わせが、すべて経営者を経由していました。件数は1日3〜5件。経営者が内容を判断し、クリティカルなものだけが開発部へ渡る。判断がつかないものは、そのまま滞留することもありました。
結果として、経営者の時間が不具合対応で埋まり、本来向かうべき新規事業の立ち上げや販路拡大に着手できない。休みも取りづらい状態が続いていました。
原因
- 問い合わせのフローが定義されていなかった（誰が受け、どこで判断し、どこへ渡すのか）
- 判断に必要な情報が経営者の中にしかなく、ドキュメントとして残っていなかった
- 部署をまたいで状況を共有する場がなく、開発部が問い合わせの全体像を把握できなかった
支援内容
- ナレッジトランスファー
問題が起きるたびに経営者へ確認し、判断の根拠をその場で文書化。2回目以降は経営者がいなくても同じ判断ができる状態へ移していきました。
- 問い合わせフローの整備
受付から一次判断、開発部へのエスカレーションまでの流れと基準を定義しました。
- 窓口の一本化とチケット管理
既存のSlack上に問い合わせ窓口を設置。あわせてAsanaを導入し、不具合を起票から完了まで追える形に。起票のテンプレート、ステータス、担当と期限のルールまで設定し、「入れたが使われない」状態にならないよう運用まで整えました。
- 部署横断の説明会
新しいフローの目的と運用方法を、CS・営業・開発の合同で共有。運用開始の起点をつくりました。
- AIによる一次回答の生成
Slackに届いた問い合わせを生成AIが読み取り、想定される原因と回答案を提示。エンジニアがその内容を検証したうえで回答する形にし、回答までの時間を短縮しました。
成果
- 全件が経営者を経由していた状態から、約90%が開発部内で完結
- 経営者の判断が必要なのは、大きな不具合やインシデントに限定
- 一次回答の生成と窓口の一本化により、回答までの時間を短縮
- 経営者が新規事業や販路拡大に時間を向けられる状態に
難しかった点
最も時間がかかったのは、経営者の中に蓄積された属人的な判断を引き出し、他の人が使える形に置き換えていく工程です。一度にすべては移せないため、問題が起きるたびに少しずつ移し替えていく。経営者の側にも、判断を手放す覚悟が要ります。仕組みだけ作っても動かないため、ここに時間をかけました。