技術問い合わせ対応の再設計
問い合わせ対応を、「人が処理する仕事」から「人が決める仕事」へ。AIが実務を進め、人が判断と責任に集中できる業務構造を設計しました。
「どこにAIを入れるか」ではなく、「AIがいるなら、仕事はどうあるべきか」から考える。
製造業の技術問い合わせは、一件の回答を返すまでに多くの工程を伴います。内容を読み、対象製品と使用条件を特定し、技術資料や過去回答を確認し、技術的な論点を整理して回答を書く。内容によっては、そこから在庫と納期の確認、見積の準備、交換部品やサービス対応の手配まで続きます。ここに検索と文章作成の高速化だけを足しても、仕事の流れそのものは変わりません。そこで入口から回答・手配・決裁までを、AIが実務を担うことを前提に組み直しました。
一つのAIにまとめて任せるのではなく、役割ごとに分けて、同時に進める。
分担の境界は、AIの技術ではなく業務の側から決めました。参照する情報が変わるところ、判断条件が変わるところ、接続する業務やシステムが変わるところ、人の承認が必要になるところ。この四つの境界で処理を切り分け、順番に依存しないものは同時に走らせています。
AIができる仕事を増やすだけでは、仕事の仕組みは変わらない。
回答案だけを生成しても、その後に人が在庫を確認し、見積を作り、手配方法を考えるなら、従来業務の一部が速くなるだけです。
AIは判断の直前まで処理する。人は判断と責任を担う。
参照する情報も、判断条件も、実行先も異なる仕事を一つの処理にまとめると、結果の根拠と責任の所在が追えなくなります。分けたうえで組み合わせることを原則とし、人が確認すべき点を常に特定できる状態を保っています。
入口、実務、判断、更新。問い合わせ業務を一つの流れとして組み直す。
問い合わせを同じ案件構造へ変換し、複数のAIが必要な実務を分担し、人には判断に必要な情報と次のアクションをまとめて渡します。回答後の情報更新までを含めて、一つの業務として設計しました。
どこから届いても、同じ一件の案件にする。
メール、電話、Webフォーム、営業・販売店経由など、入口が違っても、その先では同じ構造で処理できるようにします。メールは本文と添付資料を読み取り、電話は会話内容を記録して構造化します。誰から、どの製品について、何が起きていて、何を求めているか。この四点と、処理を進めるうえで不足している情報を揃えた一件の案件として、後続処理へ渡します。
複数のAIが、必要な実務を並行して進める。
技術資料や過去回答の検索、技術論点の整理、回答案の作成に加え、必要に応じて在庫・納期確認、見積条件、交換部品、サービス対応、手配準備までを分担します。すべての問い合わせに同じ一本道を通らせるのではなく、一件ごとに必要な処理を選んで組み合わせます。例外条件やリスクの判定も同じ層に置き、人へ渡す前に論点として立てます。
人には、作業ではなく判断を渡す。
問い合わせ概要、対象製品と条件、技術情報、回答案と根拠、確認が必要な点、在庫・納期、見積候補、必要な手配を一画面に集約します。担当者は調べ直すのではなく、内容を確認し、必要に応じて修正したうえで実行を承認します。通常案件は案件を確定するOPERATORが処理し、品質・安全・契約など責任を伴う案件だけをDECISION MAKERへ送ります。
処理結果を、次の判断に使える情報へ戻す。
人がどこを修正したか、どの資料が判断の根拠になったか、既存のFAQで不足していた情報は何かを、AIが参照する情報へ反映します。問い合わせ対応そのものを、次の対応で使う情報を更新する入口にしました。一度きりの自動化ではなく、運用しながら精度が上がる業務として設計しています。
この事例で組んだ専門性とフェーズ
案件内容に合わせ、主に担った領域を色付きで示しています。薄いセルは、この事例では主対象としていない範囲です。
問い合わせの入口設計から、チャネルをまたいだ案件化、複数AIによる実務分担、技術・ナレッジ検索、回答案、在庫・納期確認、見積・手配準備、オペレーターの判断UI、例外案件の上位決裁、回答後の情報更新までを、AIが実務を担うことを前提に、一つの業務システムとして再設計した範囲です。
「人が処理する問い合わせ」から、「人が決める問い合わせ」へ。
変えたのは問い合わせ画面でも、検索ツールでもありません。AIが担う実務と、人が担う判断。その境界を引き直したことで、次の三つが可能になりました。
AI導入を、仕事の仕組みが変わるところまで。
「どこにAIを入れるか」からではなく、「AIがいるなら仕事はどうあるべきか」から、業務と人の役割を一緒に設計します。