社内の専門部署には、日々さまざまな問い合わせが届きます。
担当者はメールを確認し、内容を調べ、回答を作成して返信する。
ごく一般的な業務です。
しかし、この業務には見落とされやすい問題があります。
その回答は、半年後に別の担当者が再利用できる状態になっているでしょうか。
今回は、メールを中心に行われていた問い合わせ・照会回答業務を、SharePoint ListsとPower Automateを使って再設計した事例をご紹介します。
目的は、単に問い合わせ管理をデジタル化することではありません。
「回答する」という業務を、「回答する＋組織に知識を残す」という業務へ変えること。
ここが今回の業務改善のポイントです。
毎日回答しているのに、組織に知識が残らない
改善前の問い合わせ対応は、シンプルなものでした。
問い合わせメールを受信
↓
担当者が内容を確認
↓
必要な情報を調査
↓
回答を作成
↓
メールで回答
一見すると、何も問題がないように見えます。
問い合わせを受け、必要な回答を返しているからです。
しかし、問題はその後です。
回答したメールは担当者のメールボックスに残ります。
数か月後、似た問い合わせが別の担当者に届いたとします。
過去に同じような回答をしていたとしても、その存在を知らなければ、別の担当者がもう一度調べることになります。
つまり、
担当者Aが調査して回答
↓
メールボックスに回答が残る
↓
数か月後、似た問い合わせが発生
↓
担当者Bがもう一度調査して回答
ということが起こります。
一件では小さなロスでも、問い合わせ件数が増えれば、この重複は積み重なっていきます。
課題は「メールを使っていること」ではない
ここで、メールをやめれば解決するわけではありません。
Outlookは、多くの企業で日常的に使われているコミュニケーションツールです。
問い合わせる側からすれば、新しいシステムを覚えるよりも、普段使っているメールから質問できる方が便利な場合もあります。
問題なのはメールそのものではありません。
メールを「問い合わせの入口」と「回答の保存場所」の両方にしてしまっていることです。
メールはコミュニケーションには適しています。
一方で、何百件もの問い合わせについて、「どんな質問があったのか」「誰が担当したのか」「現在どの状態なのか」「どのように回答したのか」「過去に似た質問がなかったか」を組織的に管理・検索・分析する用途には限界があります。
そこで今回、問い合わせの入口としてメールを残しながら、その裏側の業務プロセスを再設計しました。
問い合わせを「メール」ではなく「業務データ」として考える
設計するときに最初に行ったのは、SharePoint Listsを作ることではありません。
まず、「問い合わせとは、どんな情報で構成されているのか」を整理します。
- 受付日時
- 問い合わせ元
- 問い合わせ内容
- 問い合わせカテゴリ
- 担当者
- 対応ステータス
- 回答内容
- 回答日
- 関連情報
こうして見ると、問い合わせは単なるメールではありません。
受付から回答まで状態が変化していく、一つの「業務データ」として捉えることができます。
この考え方へ切り替えることで、問い合わせ管理の設計が大きく変わります。
SharePoint Listsで業務システムを設計する際の考え方については、「SharePoint Listsで業務システムを作るなら、最初に『列』を作ってはいけない」でも詳しく解説しています。
SharePoint Listsで問い合わせを一元管理する
今回の仕組みでは、問い合わせ情報をSharePoint Listsで一元管理します。
メールボックスの中に問い合わせが点在している状態から、「現在どんな問い合わせがあり、誰が、どこまで対応しているのか」を一覧で把握できる状態へ変えていきます。
例えば、「未対応」「対応中」「回答済み」といったステータスを持たせれば、担当者だけでなく、チームとして問い合わせ状況を把握できます。
担当者が休んでいたり異動したりしても、「本人のメールボックスを見なければ分からない」という状態から切り離せます。
SharePoint Listsで問い合わせを管理すると、こう見える
画面上では、受付日、カテゴリ、問い合わせ内容、問い合わせ元、担当者、ステータス、回答日、ナレッジ登録など、問い合わせ対応に必要な情報を一覧で確認できます。
重要なのは、見た目をきれいにすることではありません。
問い合わせ業務の現在地を、担当者の頭の中ではなくデータで表現することです。
Power Automateで「受付」と「登録」をつなぐ
ただし、問い合わせを管理するために、「メールが来たら、毎回担当者がSharePoint Listsへ転記してください」としてしまうと、新しい作業が増えてしまいます。
そこでPower Automateを使います。
例えば、対象となる問い合わせメールを受信した際に必要な情報を取得し、SharePoint Listsへ登録する仕組みを作ることで、OutlookとSharePoint Listsをつなぎます。
Outlook
↓
Power Automate
↓
SharePoint Lists
問い合わせる側は、これまでと同じようにメールを送る。
その裏側では、管理に必要なデータが蓄積されていく。
つまり、利用者の入口を大きく変えずに、裏側の業務プロセスを変えるという設計です。
業務改善では、新しい仕組みを作ることだけでなく、現場へどう定着させるかも重要です。
回答して終わりではなく、回答をナレッジとして残す
ここからが今回の事例で最も重要な部分です。
問い合わせをSharePoint Listsで管理するだけなら、「問い合わせ管理システム」です。
しかし、それだけでは十分ではありません。
今回実現したいのは、回答するたびに、組織の知識が増えていく状態です。
そこで、問い合わせ内容だけではなく、最終的な回答内容もデータとして残します。
すると、「質問」と「回答」がセットで蓄積されていきます。
例えば、半年後に似た問い合わせを受けたとき、ゼロから調査を始めるのではなく、次のような対応が可能になります。
過去のQ&Aを検索
↓
類似する回答を確認
↓
現在の状況に合わせて必要な部分を修正
↓
回答
これによって、問い合わせ対応が、「その場で回答して終了する仕事」から「回答するたびに次の問い合わせ対応を楽にする仕事」へ変わります。
Before／Afterで見ると違いが分かりやすい
| Before | After |
|---|---|
| メールで問い合わせ | メールを入口として活用 |
| 担当者が個別に管理 | SharePoint Listsで一元管理 |
| 誰が対応中か分かりにくい | 担当者・ステータスを可視化 |
| 回答メールを送って終了 | 回答内容をデータとして保存 |
| 過去回答を探しにくい | Q&Aとして検索可能 |
| 同じ質問でも再調査 | 過去回答を再利用 |
| 担当者個人に知識が蓄積 | 組織にナレッジが蓄積 |
「回答して終了」から「回答するほど知識が増える」へ
改善前は、「問い合わせ → 調査 → 回答 → 終了」という一方向の業務でした。
改善後は、「問い合わせ → 管理 → 回答 → 蓄積 → 次の問い合わせで再利用」という循環型の業務へ変わります。
問い合わせ管理とナレッジ管理は、目的が少し違う
設計上、もう一つ重要なのがこの点です。
問い合わせを処理するために必要な情報と、将来ナレッジとして利用したい情報は必ずしも同じではありません。
問い合わせ管理で重要な情報
- 誰が担当しているか
- 未対応か回答済みか
- いつ受け付けたか
- いつ回答したか
ナレッジとして重要な情報
- 何を聞かれたのか
- どのカテゴリの質問なのか
- どのように回答したのか
- 関連する資料や情報は何か
つまり、「現在の業務を回すためのデータ」と「将来知識として使うためのデータ」の両方を考えて設計する必要があります。
単にメールの内容をSharePoint Listsへコピーすればいいわけではありません。
ここを最初に設計しておくことが、後の検索性や再利用性に大きく影響します。
本当の効果は「回答時間の短縮」だけではない
この仕組みには、問い合わせ対応時間を短縮できる可能性があります。
しかし、それだけが効果ではありません。
- 過去回答を検索・再利用できる
- 同じ調査を繰り返す作業を減らせる
- 回答品質を標準化しやすくなる
- 新任担当者が過去の回答を参照できる
- 問い合わせ傾向を把握できる
例えば、ベテラン担当者が過去にどのような考え方で回答していたのかを、新任担当者が確認することもできます。
つまり、「詳しい人に聞かなければ分からない」状態から、「過去に組織がどう回答したのかを確認できる」状態へ変えていくことができます。
これは、問い合わせ対応の効率化だけでなく、属人化対策にもつながります。
問い合わせデータが蓄積すると、次の業務改善が見えてくる
さらに重要なのは、問い合わせをデータとして残すことで、その先の改善が可能になることです。
問い合わせが100件、500件と蓄積していけば、例えば次のようなことが見えてきます。
- どのカテゴリの問い合わせが多いのか
- どんな質問が繰り返されているのか
- どのテーマで調査負荷が高いのか
- どこに情報不足があるのか
すると、次に考えるべきことは、「問い合わせへ効率よく回答する方法」だけではなくなります。
- よくある質問をFAQとして公開する
- 分かりにくいマニュアルを改善する
- 問い合わせが多いテーマを研修にする
- 社内ポータルへ必要な情報を掲載する
こうした改善によって、「問い合わせに答える」から「問い合わせそのものを減らす」という次の段階へ進むことができます。
AIを活用するなら、その前に「使えるナレッジ」を作る
生成AIを使って社内問い合わせへ回答したい、という企業も増えています。
しかし、AIを導入すれば自動的に問い合わせ対応が改善するわけではありません。
AIが参照できる情報が整理されていなければ、十分な活用にはつながりません。
だからこそ、先に「質問と回答を構造化して蓄積する」ことが重要です。
例えば将来的には、次のような仕組みへの発展も考えられます。
問い合わせを受ける
↓
過去のQ&Aから類似する情報を検索
↓
回答候補を提示
↓
担当者が内容を確認・修正
↓
回答
つまり、SharePoint Listsによるナレッジ蓄積は、単なる問い合わせ管理の改善だけではありません。
将来AIを活用するための「ナレッジ基盤」を作るという意味もあります。
AIから始めるのではなく、AIが使えるデータを先に作る。
この順番が重要です。
同じような課題を抱えている部署は多い
今回の考え方は、特定の業務だけに使えるものではありません。
- 営業支援部門
- 商品・サービスの専門部署
- 経理・人事・総務
- ITヘルプデスク
- 法務・コンプライアンス
- 社内システム問い合わせ窓口
などでも応用できます。
共通しているのは、「同じような質問に、詳しい人が何度も回答している」ということです。
もし、次のような状態になっているなら、問い合わせ業務そのものを見直す余地があります。
- 「過去にも同じ質問があった気がする」
- 「○○さんに聞かないと分からない」
- 「昔のメールを検索して回答している」
- 「新しい担当者が毎回ゼロから調べている」
「その回答、組織のナレッジとして残せていますか？」
メールで問い合わせを受け、担当者が調べて回答する。
その業務自体に問題があるわけではありません。
問題は、時間をかけて作った回答が、その一回だけで消費されてしまうことです。
問い合わせ対応を、
受付
↓
管理
↓
回答
↓
蓄積
↓
再利用
まで一つの業務プロセスとして考える。
そうすることで、日々の問い合わせ対応そのものを、組織のナレッジを増やす活動へ変えることができます。
株式会社uniteでは、SharePoint ListsやPower Automateを導入するところからではなく、現在の問い合わせ業務を整理し、どの情報を管理し、どのように回答を残し、どう再利用するのかというところから業務プロセスを設計しています。
「メールで回答して終わりになっている問い合わせを、どうにかしたい」という段階からでも構いません。
現在の問い合わせ業務を整理するところからご相談いただけます。
