アプリケーションやクラウドサービスを提供する企業では、利用者からの問い合わせが、営業担当者やエンジニアに直接届いているケースがあります。
利用者や問い合わせ件数が増えると、問い合わせ対応によって営業や開発・保守などの本来業務が圧迫されるだけでなく、特定の担当者への属人化や、担当者による回答品質のばらつきといった問題も生じやすくなります。
問い合わせ対応を効率化するためには、単に対応する人員を増やすのではなく、問い合わせ窓口の一本化、履歴の一元管理、FAQ・マニュアルの整備、一次受付と専門対応の分離など、サポート体制そのものを見直すことが重要です。
本記事では、アプリケーションなど自社サービスの問い合わせ対応を効率化する方法から、新しいサポート窓口へスムーズに移行・定着させる方法、自社対応と外部委託の判断ポイントまで解説します。
- この記事でわかること
-
- アプリケーションの問い合わせ対応が属人化し、営業・エンジニアの負担が増える原因
- 窓口の一本化や履歴管理、FAQ整備など、問い合わせ対応を効率化する5つの方法
- 新しい問い合わせ窓口へ無理なく移行・定着させる5つのステップ
- 問い合わせ対応を自社で行うか、外部委託するかを判断するポイント
- 現在の問い合わせ対応に改善余地があるか確認するチェックリスト
アプリケーションの問い合わせ対応でよくある課題
利用者や問い合わせ件数が増えるにつれて、営業担当者や開発担当者による個別対応の問題が表面化してきます。
直接問い合わせが営業・エンジニアの本来業務を圧迫する
導入時の営業担当者や製品に詳しいエンジニアへ、電話やメールで直接問い合わせる方法が定着しているケースがあります。利用者にとっては、いつもの詳しい担当者に聞けば早く分かるというメリットがあります。
一方、商談や開発・保守を中断して回答すると、本来の業務に使える時間が減少します。問い合わせが増えるほど、営業担当者やエンジニアの負担も大きくなります。
問い合わせ対応が特定の担当者に属人化する
製品知識や顧客との過去の経緯が特定の担当者だけに蓄積されると、担当者の不在時に適切な回答ができず、対応が滞ったり、担当者自身が休暇を取りづらくなったりする可能性があります。
また、担当者の異動や退職が発生した場合には、サービス品質の低下や、引き継ぎ不足によるトラブルにつながるリスクもあります。
問い合わせ履歴や顧客情報を一元管理できない
個人の電話やメールに問い合わせが分散すると、「誰から・いつ・どのような問い合わせがあり・誰が・どう回答したのか」といった情報を組織で共有しにくくなります。
その結果、再問い合わせのたびに過去の経緯を確認したり、別の担当者が同じ情報を利用者に聞き直したりすることになり、対応効率が低下します。
担当者によって対応品質に差が生じる
対応ルールやナレッジが整備されていない場合、担当者の知識や経験によって、回答内容や解決までにかかる時間に差が生じます。
問い合わせ件数が増えて担当者が増員・交代した場合でも、一定のサポート品質を維持できる仕組みを作ることが重要です。
アプリケーションの問い合わせ対応を効率化する5つの方法
こうした問題を解消するためには、単に「問い合わせ件数を減らす」のではなく、問い合わせを受け付け、回答し、履歴やナレッジを蓄積する仕組みそのものを見直すことが重要です。代表的な方法を5つ紹介します。
1．問い合わせ窓口を一本化する
まず検討したいのが、問い合わせの入口を一本化することです。例えば、
- 営業担当者への電話
- エンジニアへのメール
- 会社の代表電話
- 問い合わせフォーム
など、複数の入口から問い合わせを受けている場合は、サポート用の電話番号やメールアドレス、問い合わせフォームなどに集約します。目的は、利用者からの問い合わせ方法を単純に制限することではありません。問い合わせの入口を明確にし、対応状況を組織として把握できる状態にすることがポイントです。
2．問い合わせ履歴を一元管理する
問い合わせ窓口とあわせて整備したいのが、問い合わせ履歴です。少なくとも、下記項目を記録できる状態にします。
- 利用者情報
- 問い合わせ日時
- 対象の製品・サービス
- 問い合わせ内容
- 回答内容
- 対応担当者
- 対応状況
- エスカレーション先
問い合わせ履歴を一元管理することで、担当者が変わっても過去の経緯を踏まえて回答しやすくなります。
また、問い合わせ内容を蓄積すると、「どのような問い合わせが多いのか」を分析できるため、FAQの整備や製品・サービスそのものの改善にもつなげられます。
3．FAQ・マニュアル・回答テンプレートを整備する
頻出する問い合わせについては、FAQやマニュアルを整備しておくことが有効です。利用者向けのFAQを用意して自己解決を促すだけでなく、サポート担当者向けに、FAQや回答テンプレート、トラブルシューティング、対応フロー、エスカレーション条件などを整備する方法もあります。
担当者個人が持つ知識やノウハウを組織のナレッジとして蓄積・共有することで、問い合わせ対応の属人化を防ぎ、担当者が変わっても一定の品質で対応しやすくなります。また、整理されたFAQや対応履歴などのナレッジは、将来的にチャットボットや生成AIを活用した問い合わせ対応を検討する際に役立つでしょう。
4．一次受付と専門的な対応を分ける
すべての問い合わせを専門担当者が対応する必要はありません。
例えば、利用者からの問い合わせをサポート窓口で受け付け、内容を確認します。FAQやマニュアルで回答できる問い合わせは一次窓口で対応し、高度な製品知識や技術的な調査が必要な問い合わせだけを、エンジニアなどの専門担当者へエスカレーションする体制です。
あらかじめ判断基準を決めておくことで、パスワードやアカウント、基本操作など、一次窓口で回答できる問い合わせを専門担当者が直接対応する必要はありません。一次受付と専門対応を分けることで、営業担当者やエンジニアは、専門知識が本当に必要な問い合わせに集中しやすくなります。
5．定型的な問い合わせ対応は外部委託も検討する
社内でサポート担当者を確保しにくい場合は、次のような業務の外部委託も検討できます。
- 問い合わせの一次受付
- 利用者情報・問い合わせ内容の確認
- FAQに基づく回答
- 問い合わせ履歴の登録
- 専門担当者へのエスカレーション
問い合わせ窓口を設置するだけでは効率化につながらないことも
問い合わせ窓口を設置しても、利用者が従来の問い合わせ方法を使い続け、新しい窓口の利用が定着しないことがあります。
利用を促進するためには、サポート窓口の設計・移行にあたって、利用者にとってのメリットを明確にし、伝えることが重要です。
提供企業側の業務効率化だけでなく、問い合わせ履歴が引き継がれることで同じ説明を繰り返す負担が減るなど、利用者の立場から「新しい窓口を利用するメリット」を示しましょう。また、あわせて、新しい窓口への移行を妨げる障壁への対応も必要です。
新しい問い合わせ窓口への移行で想定される3つの障壁
- 利用者への告知が難しい
契約企業は分かっても実際の利用者を把握できず、メールアドレスも一元管理されていない。 - 直接連絡が習慣になっている
いつもの担当者への連絡で解決してきたため、新窓口へ切り替える理由を感じにくい。 - 品質への不安がある
製品知識の不足、説明の繰り返し、解決までの時間の増加が懸念される。
問い合わせ窓口をスムーズに移行・定着させる5つのステップ
問い合わせ窓口を変更する場合には、一度に切り替えるのではなく、段階的に新しい窓口へ誘導する方法があります。直接問い合わせから一次窓口へ段階的に移行するイメージは、以下のとおりです。
現在の問い合わせ経路を整理する
まずは、現状を把握します。例えば、
- どの顧客・利用者から問い合わせが来ているのか
- 電話やメールなど、どの経路から連絡が来ているのか
- 誰が問い合わせを受けているのか
- どのような問い合わせが多いのか
- 誰が回答しているのか
- どこまでなら一次窓口で回答できそうか
問い合わせ件数を把握できていない場合は、まず一定期間記録し、実態を把握しましょう。
サポートサイト・問い合わせフォームを用意する
アプリケーションやクラウドサービスのように、問い合わせ先を書いたシールなどを製品本体に貼れない場合には、サポートサイトを問い合わせの入口にする方法があります。
例えば、
- 問い合わせフォーム
- サポート窓口の電話番号・メールアドレス
- 受付時間
- FAQ
- ユーザー登録
などを一つのWebサイトにまとめます。
大規模なサイトから始める必要はありません。まずは「今後どこへ問い合わせればよいのか」が利用者に伝わる状態を作ることが重要です。
既存ユーザーにサポートサイトへの登録を促す
利用者の連絡先を十分に管理できていない場合、窓口変更の一斉告知が難しくなります。この場合、窓口移行そのものを、利用者情報を整備する機会にするという考え方があります。例えば、次のような流れで移行します。
- 営業担当者が既存顧客へサポートサイトのURLやQRコードを案内する
- 利用者がサポートサイトへアクセスする
- 利用者自身がユーザー登録を行う
- 登録した利用者へ正式な問い合わせ窓口を案内する
- 登録者から順次、新しい窓口へ移行する
旧窓口と新窓口を一定期間並行運用する
新しい窓口を開設した直後から、「営業担当者への問い合わせには一切対応しない」という運用にすると、利用者の不満につながる可能性があります。そこで、一定の移行期間を設けます。旧来の問い合わせ経路も一時的に残しながら、新しいサポートサイトや窓口を繰り返し案内して、少しずつ利用者の行動を変えていきます。
担当者への直接問い合わせも公式窓口へ載せ替える
移行期間中には、新しい窓口を案内した後も、営業担当者やエンジニアへ直接問い合わせが来ることがあります。このとき、「こちらでは対応できないので、サポート窓口へ電話し直してください」と利用者へ差し戻してしまうと、利便性が大きく下がります。
例えば、「今回は私からサポート窓口へ問い合わせ内容を共有します。次回からはこちらの窓口をご利用ください」といった対応にします。直接問い合わせをすぐに拒否するのではなく、問い合わせ自体は受け止めながら、正式な受付経路へ載せ替えていくことがポイントです。
問い合わせ対応を自社で効率化するか、外部委託するか
問い合わせ件数、人員、製品の専門性などを踏まえ、自社で対応する範囲と外部委託する範囲を検討します。
-
自社対応が向いているケース
- 問い合わせ件数が比較的少ない
- 社内でサポート担当者を確保できる
- FAQ・マニュアルが整備されている
- 問い合わせ履歴を管理する仕組みがある
- 製品知識の専門性が高く、社外への切り出しが難しい
-
外部委託を検討しやすいケース
- サポート専任者を確保しにくい
- 営業・エンジニアへの直接問い合わせが多い
- 一次受付を専門担当者から切り離したい
- 問い合わせ件数が増え、既存の体制では対応しきれない
- 新しい問い合わせ窓口の立ち上げや移行方法から検討したい
例えば、一次受付やFAQに基づく定型回答は外部に委託し、製品固有の専門知識が必要な問い合わせは自社で対応するなど、役割分担も可能です。
アプリケーションの問い合わせ対応を効率化する際のチェックリスト
自社の問い合わせ対応に改善余地があるか、以下を確認してみてください。
複数当てはまっている場合、単に担当者を増やすのではなく、問い合わせの受付、回答、エスカレーション、履歴管理、ナレッジの蓄積までを含めて、サポート体制そのものを見直すことをおすすめします。
まとめ
アプリケーションの問い合わせ対応を効率化するには、営業担当者やエンジニアへの直接問い合わせを単に禁止するのではなく、利用者が使いやすい問い合わせ窓口を設け、問い合わせ内容や対応履歴、ナレッジを組織として蓄積できる仕組みを作ることが重要です。
また、新しい窓口を設置するだけで利用者が移行するとは限りません。利用者にとってのメリットを伝えながら段階的に移行することで、営業・エンジニアの負担軽減と利用者の利便性を両立することがポイントです。
営業・エンジニアへの直接問い合わせを減らしたい、一次受付の外部委託、新しい窓口への移行を検討しているが一緒に進め方を相談するパートナーをお探しであればお気軽にＪＢサービスへご相談ください。
