【社内問い合わせ効率化】受付記録・FAQ・担当引継ぎの整え方

社内問い合わせを効率化するには、受付先を案内し、同じ質問を分類してFAQへ戻し、担当を移す条件を決めます。回答を速くするだけでなく、聞く人が迷わず、未解決の案件が残らない流れを整えましょう。

この記事は、総務・経理・情報システムなどの窓口担当者向けです。既存のメールや共有表から始められる記録例、FAQの書き方、引継ぎメモ、効果の数え方を示します。以下の受付データ・人数・時間はすべて説明用の架空例で、実在企業の改善実績ではありません。

まず一つの窓口で受付と完了の定義をそろえる

例えば経費の質問をメールでもチャットでも担当者への口頭連絡でも受ける場合、窓口の一覧と、受けた後の記録先を決めます。緊急連絡や個別事情の相談まで一律にフォームへ閉じ込める必要はありません。別経路で受けた案件も受付IDへ対応づけ、担当者が替わっても残件を追えるようにします。

受付単位は「一つの解決したい用件」です。同じ用件の催促や追加情報は同じIDへ追記し、新しい問い合わせとして増やしません。一つのメールに経費とアカウントの別用件があれば、分けて担当と完了を管理します。既存メールを削除するのではなく、記録の正本と参照先を担当内でそろえてください。

完了も「回答を送った」と「依頼者が次の作業へ進める状態になった」を区別します。回答後の確認が必要な用件は確認中とし、不在や長期未返信を自動的な解決と決めつけません。終了扱いにする条件と、再連絡が来たときの戻し方を決めます。

問い合わせ記録は分類と次の行動が分かる形にする

最初から細かい分類を大量に作るより、窓口で処理方法が変わる少数の分類から始めます。例えば「操作案内」「規程の確認」「個別の承認」「障害の疑い」です。部署名だけで分けると、同じ回答を使える質問をまとめにくくなります。

氏名・給与・人事評価・認証情報などを、全員が見るFAQや集計表へそのままコピーしないでください。元案件への参照と、匿名化した質問の要約を分けます。閲覧できる人、保存する範囲、社内の取扱ルールに沿う保存先を決め、公開範囲の広い集計には必要な分類と件数だけを使います。

Atlassianの公式ヘルプでも、問い合わせの種類によって必要な情報を集めることと、条件で絞った作業一覧で案件を整理する機能を別々に説明しています。問い合わせ種別とFAQなどの整理、担当が処理する一覧の説明が参考になります。本記事の記入例は独自に作成したもので、その製品の導入手順ではありません。

繰り返す質問を一つ選び、使えるFAQを作る

架空の20件を分類したところ、アカウント6件、経費5件、利用権限4件、機器3件、その他2件だったとします。この件数は入力例の集計で、一般的な企業の発生割合ではありません。件数だけでなく、繰り返す同じ質問か、誤回答の影響が大きいか、手順の案内だけで解決できるかを見ます。

例えば「経費申請の添付場所」はFAQ候補ですが、「例外的な支出を認めるか」は個別判断が残ります。アカウントの質問が最多でも、本人確認が必要な再設定の処理そのものを、誰でも実行できるFAQへ置き換えることはできません。

FAQの記入例を担当者と確かめる

以下は架空の申請システムに関するFAQの骨組みです。実在する製品の画面名や操作手順を示すものではありません。自社で実際に使う画面と規程を確認して書き換えます。

• 質問 … 経費の領収書をどこへ添付しますか。
• 対象 … 通常の経費申請を作成できる社員。申請権限がない場合は窓口へ確認する。
• 回答 … 現行の申請手順の添付欄を確認し、対象の申請に領収書を付ける。実際の欄名と対応形式を自社の画面で記載する。
• 完了の確認 … 対象の申請で添付ファイルを開けることを確認する。
• 解決しない場合 … 申請の管理番号、表示されたエラー、試した操作を窓口へ伝える。パスワードや不要な領収書の画像を公開欄へ載せない。
• 管理 … 経理担当が根拠の手順と更新日を確認し、画面や規程が変わったら見直す。

FAQは件数を増やすことより、困った人がその言葉で探せることが大切です。社内の正式な機能名だけでなく、問い合わせで使われた「領収書を付けられない」などの表現を見出しや検索用の語に反映します。公開前には、その業務を担当していない人にも手順を読んでもらい、どこで迷うかを確認します。

担当を移す条件と引継ぎメモを決める

一次窓口で答えられない場合は、専門担当や判断できる責任者へ引き継ぎます。これをエスカレーションと呼びます。すべてを同じ担当へ集めず、用件ごとに受け取る担当と、不在時の窓口を決めておきます。

• 手順案内で対応できる … 一次窓口が現行FAQに沿って回答する。
• 権限付与や例外承認が必要 … 所定の承認者へ引き継ぎ、窓口の判断で許可しない。
• 同じ障害の疑いが広がる … 運用担当へ状況を共有し、同じ案内を個々に調べ直す前に共通状況を確認する。

引継ぎメモは「受付ID、困っていること、影響する範囲と期限、確認済みの手順、得られた結果、次に判断してほしいこと」でそろえます。「分かりませんでした」だけを転送せず、既に試したことを渡すと再質問を減らせます。緊急性がある場合の連絡経路は、通常の順番待ちと分けて決めます。

他担当へ移した後も、受付記録には新しい担当と次の確認予定を残します。引継ぎをした時点で解決済みにせず、担当が受け取ったかと、依頼者への返答を誰が行うかを確かめます。

件数・作業時間・未解決を同じ条件で比べる

集計では、問い合わせの件数と、窓口担当者が実際に使った作業時間を分けます。回答までの待ち時間を、そのまま作業工数へ足しません。未記録の時間は0分に置き換えず、記録できなかった件数を別に示します。

次の表は、各20件の架空データで計算の仕方を検証した例です。改善前後の実測結果や、FAQの導入効果を示す数字ではありません。ここでの一次完結は「専門担当への引継ぎや追加の往復なしで、受付期間内に解決した用件」と定義し、割合の分母を期間内の新規受付20件に固定しています。

この仮定では日々の対応時間の差は60分です。ただし、FAQ作成・確認に別途70分かけたなら、最初の比較期間では差し引き10分の追加負担になります。FAQの更新や研修の時間を除外して「60分の効率化に成功した」と結論づけないでください。

受付件数や難しさ、月末処理、担当の経験が違えば単純比較はできません。必要な承認を省いたため一次完結が増えた場合も改善ではありません。担当者の時間だけでなく、依頼者の入力負担、誤回答、差戻し、未解決の滞留を一緒に見ます。

また、FAQを表示しただけでは自己解決の証拠になりません。Atlassianの標準レポートの説明でも、記事を見て役立ったとされた回数と、記事を使った場合・使わない場合の解決を区別しています。自社でも閲覧、役立ったという回答、実際の解決を混同せず記録します。

今週から始める小さな試行

1. よく受ける一つの用件を選び、受付から完了までの範囲を決める。
2. 既存の共有表などに受付ID、分類、担当、状態、回答根拠、作業時間を記録する。
3. 同じ質問を一つ選び、FAQの対象・答え・完了確認・未解決時の連絡先を整える。
4. 通常の質問と、承認が必要な例外の両方で案内と引継ぎを試す。
5. 担当と確認日を決め、工数・差戻し・未解決を見て継続する範囲を決める。

最初は一つの窓口・一つの用件で構いません。受付の分類や引継ぎ条件が定まってから、必要に応じて専用システムやAIを検討します。既存の道具で試せる範囲を、製品の導入待ちで止める必要はありません。

Advertisement

Advertisement