LASSIC Media らしくメディア
問い合わせ管理システムの開発を外注｜ヘルプデスク構築
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- 問い合わせ管理システムは、メール・電話・チャットなど複数の窓口をチケットとして一元管理し、対応状況を可視化する仕組みです。
- SLA(Service Level Agreement)は「サービス品質に対する利用者側の要求水準と提供者側の運営ルールについて明文化したもの」と経済産業省のガイドラインで定義されています*1。
- ヘルプデスク体制を評価する際は、ITILへの取り組みやJIS Q 20000認証の有無を確認することが望ましいとされています*1。
目次
問い合わせ管理・ヘルプデスクシステムとは——バラバラな問い合わせを一元管理する仕組み
問い合わせ管理システムとは、メール・電話・チャット・Webフォームなど複数の窓口に届く問い合わせを「チケット」という単位で記録し、受付から解決までの状況を一元管理するシステムを指します。担当者ごとにメールソフトで対応していると、誰が何に返信したか把握しづらくなり、対応漏れや二重対応が起きやすくなります。この課題を解消する狙いで導入されるのが問い合わせ管理・ヘルプデスクシステムです。
受付段階では、メール・電話・チャットなど窓口ごとに独立していたやり取りをひとつの画面に集約します。届いた内容は自動または手動でチケットとして起票され、件名・優先度・カテゴリーなどの情報が付与されます。ここまでが「オムニチャネル対応」と呼ばれる領域です。
チケット化された問い合わせは、担当者やチームへ振り分けられ、対応履歴が時系列で蓄積されます。対応が完了した後は、繰り返し発生する質問をFAQやナレッジベースへ反映し、応答内容を継続的に見直す運用へつなげる流れが一般的です。次章では、この一連の流れを支える主要機能を具体的に整理します。
チケット管理・オムニチャネル・エスカレーション——備えるべき主要機能
問い合わせ管理・ヘルプデスクシステムに求められる機能は多岐にわたりますが、共通する骨格は以下の通りです。
| 機能 | 概要 |
|---|---|
| チケット管理 | 問い合わせをチケットとして起票し、ステータス（未対応・対応中・保留・完了）や優先度を管理します。 |
| オムニチャネル対応 | メール・電話・チャット・SNS・Webフォームなど複数チャネルの問い合わせを、同じ画面と履歴で扱えるようにします。 |
| 担当割り当て・エスカレーション | カテゴリーや過去の対応実績に応じて担当者へ自動で割り振り、対応が難しい案件は上位担当者へ引き継ぎます。 |
| SLA管理 | 初回応答や解決までの目標時間を設定し、超過が見込まれる案件を通知します。障害対応や一般的な問合せ対応に関わる項目として整理されます*1。 |
| FAQ・ナレッジベース | 過去の対応内容をもとに、利用者が自己解決できる記事を蓄積・公開します。 |
| 対応履歴・レポート/分析 | 問い合わせ件数・対応時間・満足度などを集計し、体制やFAQの見直しに役立てます。 |
これらの機能のうちSLA管理は、経済産業省がまとめたガイドラインでは「アプリケーション運用」「サポート」「データ管理」「セキュリティ」という4分類でサービスレベル項目を整理できるとされています*1。サポート項目には障害対応や一般的な問合せ対応が含まれており、問い合わせ管理システムの運用設計とも重なる部分です*1。
また同ガイドラインでは、SLAを締結して終わりにするのではなく、定めたサービスレベルを定期的に測定・分析・評価し続ける管理手法をSLM（Service Level Management：サービスレベル管理）と呼んでいます*1。問い合わせ対応の品質を一時的なものにせず、継続的に改善していく発想が前提になっています。
社外向けカスタマーサポートと社内ヘルプデスク（情シス）の違い
問い合わせ管理システムは、想定する利用者によって重視するポイントが変わります。社外向けのカスタマーサポートでは、顧客からの問い合わせ件数が多く、対応品質のばらつきが顧客満足度に直結しやすい傾向があります。返信テンプレートの整備や、対応履歴を踏まえた個別対応の質が問われる領域です。
一方、社内ヘルプデスク（情シス向け窓口）は、パスワードリセットや端末トラブル、社内システムの操作方法など、対象がある程度絞り込まれる点が特徴です。問い合わせ元が社員であるため本人確認の手間は比較的軽く済みますが、権限付与や資産管理といった、社内の運用ルールに沿った処理が求められます。
両者に共通するのは、チケット管理・エスカレーション・履歴管理という基本構造です。違いが表れるのは、SLAで重視する指標や、FAQの公開範囲、連携させる周辺システムです。カスタマーサポートでは応答速度や解決率が重視されやすく、社内ヘルプデスクでは対応範囲の明確化と属人化の解消が優先されやすいと言えます。自社がどちらの用途を主眼に置くかによって、選ぶべき機能の優先順位も変わってきます。
例えば社外向けのカスタマーサポートでは、繁忙期に問い合わせが集中しても対応品質を落とさないよう、担当者間での負荷分散やチャネルごとの受付時間の設定が課題になりやすい領域です。社内ヘルプデスクでは、対象となる社員数が固定的である一方、端末の入れ替えやシステム更改のタイミングで問い合わせが一時的に急増する傾向があります。どちらの用途でも、繁忙期を想定した体制設計をあらかじめ検討しておくことが望ましいでしょう。
また、社内ヘルプデスクは総務・人事など他部門からの問い合わせも受ける窓口になっている場合があります。IT関連以外の問い合わせが混在すると、誰がどこまで対応するのかがあいまいになりがちです。問い合わせ管理システムを導入する際は、対象とする窓口の範囲をあらかじめ線引きしておくと、運用開始後の混乱を抑えやすくなります。
チャットボット・AIとFAQ/ナレッジベース連携で自己解決を促す
コールセンターや企業の問い合わせ対応において、AIによる応答の自動化やチャットボットによる自動応答など、AIを活用した業務効率化の取り組みが進んでいると総務省の情報通信白書は指摘しています*3。同白書ではコールセンターやチャットボットの領域はすでに実用化が進んでいる分野として紹介されています*3。
問い合わせ管理システムにチャットボットを組み合わせる場合、まず利用者からの質問をFAQ・ナレッジベースと照合し、該当する回答があれば自動で提示します。回答が見つからない場合や、利用者が納得できない場合は、有人のチケットへエスカレーションする設計が一般的です。ここで重要なのは、チャットボットの回答精度がFAQの整備状況に左右される点です。よくある質問を継続的に洗い出し、回答文を更新し続ける運用体制がなければ、自己解決率は思うように伸びません。
また、チャットボットとの対話ログやチケットの対応履歴を分析することで、まだFAQ化されていない質問の傾向をつかめます。この分析結果を定期的にナレッジベースへ反映していくと、問い合わせ全体に占める定型的な質問の割合を徐々に下げていける見込みです。人による対応が必要な案件に担当者の時間を集中させられる点が、AI連携を検討する動機になります。
SaaS・パッケージ型とスクラッチ開発、CRM連携をどう選ぶか
問い合わせ管理システムの導入形態は、大きく分けてSaaS型・パッケージ型・スクラッチ開発の3つです。SaaS型は初期費用を抑えて短期間で使い始められる一方、機能や画面レイアウトはサービス提供者の仕様に沿う形になり、細かなカスタマイズには制約が伴います。パッケージ型は自社サーバーへ導入する形態で、SaaS型よりも柔軟な設定変更が可能ですが、保守・運用の体制を自社もしくは委託先で用意する必要があります。
スクラッチ開発は、既存の業務フローや承認プロセスに合わせて画面や機能をゼロから設計できる方法です。複数部門にまたがる複雑な振り分けルールや、個別仕様の帳票出力が必要な場合に選ばれやすい一方、開発期間と費用は他の2形態より大きくなりがちです。自社の問い合わせ件数や業務の特殊性を踏まえ、どこまでを標準機能でまかない、どこから作り込みが必要かを見極めることが選定の分かれ目になります。
CRM（顧客関係管理システム）との連携も、検討事項のひとつです。問い合わせ履歴と顧客の契約状況・購買履歴をひもづけておくと、対応時に顧客の背景を踏まえた回答がしやすくなります。連携方法にはAPI経由でのデータ連携や、CRM側の機能拡張として問い合わせ管理機能を追加する方式などがあり、既存のCRM構成や利用しているプランによって選べる方式は変わります。CRM側の詳細な機能設計については別途整理が必要ですが、問い合わせ管理システムを選ぶ段階では、CRMとの連携実績があるかどうかを外注先に確認しておくとよいでしょう。
導入の進め方と外注時に確認すべきポイント
導入を進める際に欠かせないのが、現状の問い合わせ経路の棚卸しです。どのチャネルにどの程度の件数が届き、誰が何を基準に対応しているかを可視化しないと、必要な機能の優先順位を判断できません。次の工程となる要件定義では、SLAとして管理したい項目の洗い出しが中心的な作業です。経済産業省のガイドラインでは、前提条件の整理、委託内容・範囲の定義、役割・責任分担の定義、サービスレベルの定義、結果対応の定義、運営ルールの設定という手順でSLAを作成する進め方が示されています*1。
要件が固まった後は、SaaS・パッケージ・スクラッチのいずれを選ぶかを検討し、FAQ・ナレッジベースの初期整備を並行して進めます。試験運用の期間を設け、実際の問い合わせ件数で運用ルールを検証してから本稼働に移す流れが現実的です。本稼働後も、SLMの考え方に沿って測定・分析・改善のサイクルを回し続けることが求められます*1。
外注先を選ぶ際に確認すべき点はいくつかあります。第一に、社外向けカスタマーサポートと社内ヘルプデスクのどちらの構築実績があるかです。第二に、SaaS・パッケージ・スクラッチのいずれにも対応できるか、あるいは特定の方式に限定されるかです。第三に、ヘルプデスクの設置や迅速なトラブル対応の体制について、ITILへの取り組みやJIS Q 20000認証の有無を確認することが望ましいとされています*1。第四に、稼働後の保守・運用フェーズまでを含むSLAを提示できるかどうかです。要件定義からFAQ整備、本稼働後の改善まで一貫して依頼できる元請（プライムベンダー）を選べるかどうかが、運用開始後の負担を左右します。
まとめ：問い合わせ管理システム導入で押さえる3つの視点
本稿で取り上げた問い合わせ管理・ヘルプデスクシステムの要点は、次の3つです。第一に、システムの骨格はチケット管理・オムニチャネル対応・エスカレーション・SLA管理・FAQ/ナレッジベース・レポート分析という機能群で構成されています。第二に、社外向けカスタマーサポートと社内ヘルプデスクでは重視する指標が異なるため、自社の用途に応じた機能の優先順位付けが欠かせない点です。第三に、SaaS・パッケージ・スクラッチのどれを選ぶか、CRMとどう連携させるかは、業務の特殊性と保守体制を踏まえて判断していく必要があります。
よくある質問
問い合わせ管理システムとヘルプデスクシステムは同じものですか。
呼び方が異なるだけで、指している機能の骨格はおおむね共通しています。問い合わせ管理システムは主に問い合わせをチケットとして管理する仕組みを指す呼び方で、ヘルプデスクシステムは対応窓口そのものを含めた呼び方として使われる傾向があります。導入時はどちらの呼称にこだわるよりも、必要な機能が備わっているかを確認することが実務的です。
社外向けと社内向けを同じシステムで運用することはできますか。
同一システム上でチケットの種別やカテゴリーを分けて運用するケースはあります。ただし、社外向けは顧客対応の品質管理、社内向けは資産・権限管理との連携が重視されるなど、求められる周辺機能が異なります。両方を担う場合は、権限設定やFAQの公開範囲を分けられるかどうかを事前に確認しておくとよいでしょう。
チャットボットを導入すれば問い合わせ対応の工数は減りますか。
よくある質問への回答をチャットボットに任せられれば、担当者が個別対応に充てられる時間は増えます。ただし効果を左右するのはFAQ・ナレッジベースの整備状況であり、導入するだけで工数が減るわけではない点に注意が必要です。継続的にFAQを見直す運用体制とあわせて検討することをおすすめします。
SaaS型と既存のCRMを連携させることはできますか。
API連携に対応したSaaS型の問い合わせ管理システムであれば、既存のCRMと連携できるケースが多くあります。ただしCRM側のプランによってはAPI利用に上位プランへの変更が必要な場合や、連携できる項目に制限がある場合があるため、契約前にベンダーへ確認しておくことが大切です。
問い合わせ管理システムの構築を外注する場合、何を確認すればよいですか。
社外向け・社内向けいずれの構築実績があるか、SaaS・パッケージ・スクラッチのどの方式に対応できるか、CRMとの連携実績があるかをまず確認します。あわせて、稼働後の保守・運用フェーズまでを含むSLAを提示できるかどうかも判断材料になります。元請（プライムベンダー）として一貫して対応できる体制かどうかも、あわせて確認しておくとよいでしょう。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：経済産業省「SaaS向けSLAガイドライン」（2008年1月21日公表）
- *2 出典：itSMF Japan（CeFIL サービスマネジメント・イノベーションセンター）「ITIL」
- *3 出典：総務省「平成30年版 情報通信白書 業務効率化の現状」
