コールセンターの業務フロー図の書き方 AI導入前に現状を描く4つの手順

コールセンターの業務フロー図は、用件を1つに絞り、「誰が・何を・どの順で」の作業単位で描きます。手順は4つ。描く範囲を決める、粒度をそろえる、記号とレーンを決めて描く、例外ルートを書き分ける。AIの導入やシステムの入れ替えの前にフローを描く目的は、今の業務を残さず写すことではありません。どこが人の判断で、どこで他部門やシステムに渡っているかを、関係者が同じ絵で見られるようにすることです。
先に立場をはっきりさせておきます。AI導入の前に描くフロー図で最も役に立つのは、うまくいった電話の流れ(本線)ではなく、本人確認ができない、システムが止まった、他部門の回答待ちになった、といった例外ルートの部分です。AIが答えに詰まって人へ渡すのも、導入後に問い合わせが滞るのも、たいてい例外ルートで起きるからです。
1. 描く範囲を用件1つに絞る
最初の1枚は、件数が多く手順が比較的決まっている用件を1つ選びます。「コールセンター全体の業務フロー」を1枚で描こうとすると、用件ごとに違う分岐が重なって読めない図になります。全体像が要るなら、用件の一覧と、各用件のフロー図へのつなぎを示す目次のような1枚を別に作るほうが扱いやすくなります。
始点と終点もここで決めます。始点は顧客が電話をかけた時点か、IVR(音声による自動案内)を抜けてオペレーターにつながった時点か。終点は通話を切った時点か、後処理と他部門への引き継ぎが終わった時点か。AI導入の検討に使うなら、終点は後処理の完了まで伸ばします。通話中の要約や記録の自動化を検討するとき、後処理が図に入っていないと効果を見積もれないためです。
電話の流れだけなら、電話システムの設定画面にもすでに図があります。AWSのコンタクトセンター基盤の管理者ガイドは、フローの説明の冒頭で、フローが顧客の体験を始めから終わりまで定義するものだとしています。ただ、ここで描かれるのは電話がどこへ振り分けられるかまでです。オペレーターが画面で何を確かめ、誰に何を頼むかは、業務フロー図にしか書かれません。
2. 粒度を作業単位でそろえる
フロー図が使えなくなる原因の1つが、粒度のばらつきです。石川県のBPR推進ハンドブック(2026年版)は、粒度が粗すぎると業務の実態が分からず、細かすぎると全体像が見えなくなるとして、業務改革では「誰が」「何を」「どのように」実施しているかを把握するため、作業単位で書くよう求めています。県庁の業務改革向けの手引きですが、コールセンターにもそのまま当てはまります。
コールセンターの言葉に置き換えると、次のようになります。
| 粒度 | 例 | 問題 |
|---|---|---|
| 業務単位(粗すぎる) | 「問い合わせに対応する」 | どこで時間がかかり、どこで人が判断しているか分からない |
| 作業単位(ちょうどよい) | 「本人確認をする」「顧客台帳の住所を更新する」 | 誰が何をしているかが分かり、AIやシステムに置き換える候補を選べる |
| 動作単位(細かすぎる) | 「顧客検索画面を開く」「生年月日欄に入力する」 | 図が長くなり、描く負担も読む負担も大きい |
迷ったら、「この箱を別の人やシステムに渡せるか」で判断します。渡せる単位が作業単位です。
3. 記号とレーンを決めて描く
記号は少ないほど読みやすくなります。石川県のハンドブックの凡例は、開始・終了、処理、判断(条件分岐)、作成物・使用書類、システム、工数・メモの6種類です。社内でこれ以上増やさないと決めておくと、描く人が変わっても図がそろいます。システムの要件定義まで見据えて国際的な表記にそろえたいなら、OMGが定めるBPMN(業務プロセスの表記法)の仕様があり、現行版は2014年1月公開の2.0.2です。ただし現場のSVやオペレーターと一緒に描く段階では、6種類程度の記号で足ります。
レーン(担当ごとの横の帯)は、少なくとも顧客、IVRやボット、オペレーター、SV、他部門、システムの6本を用意します。オペレーターとSVを1本にまとめないこと。SVへの確認が何回発生しているかが、あとで人の判断を減らせるかどうかの材料になるからです。
各箱には、件数と時間のメモを添えます。正確な実測でなくても、例えば「1日20件くらい」「ここで3分ほど待たせる」程度の書き込みがあるだけで、どの箱から手を付けるかの議論ができます。保留が発生している箱は、保留の理由コードから改善箇所を探す記事の方法で、理由別に数えておくと後が楽です。
ここまでの決まりで描いた例を載せます。住所変更の電話の、本線だけを表にしたものです。
| No. | レーン | 作業 | 分岐と行き先 | メモ(例) |
|---|---|---|---|---|
| 1 | 顧客 | 電話をかける | 受付時間外ならE1へ | |
| 2 | IVR | 用件番号を選ばせる | 「住所変更」以外は各用件のフローへ | |
| 3 | オペレーター | 本人確認をする(氏名・生年月日・登録電話番号) | 一致しなければE2へ | 約1分 |
| 4 | オペレーター | 新しい住所を聞き取り、復唱する | 引越しに伴う解約の希望があればE4へ | 約2分 |
| 5 | システム | 顧客台帳の住所を更新する | 更新できなければE3へ | |
| 6 | オペレーター | 完了と、郵送物に反映される時期を伝える | ||
| 7 | オペレーター | 応対履歴に用件コードと結果コードを入れる | 約1分 | |
| 8 | 終了 |
メモ欄の時間はすべて説明用の例で、実測の値ではありません。
4. 例外ルートを本線と同じ丁寧さで書く
本線は誰が描いても似た図になります。差が出るのは例外ルート。
例外を書くときの決まりは2つだけ。1つは、例外の行き先に「誰が、いつまでに、何を」を必ず書くこと。「SVに相談」で止めず、SVが判断できなかったら次は誰か、顧客には何をいつ伝えるかまで書きます。もう1つは、別の用件に変わった場合は同じ図の中で続けず、その用件のフローへ移ることです。住所変更の途中で解約の話になったら、解約のフローへ渡します。1枚の図に2つの用件を混ぜると、どちらの図としても使えなくなります。
先ほどの例の例外ルートは、たとえば次のように書きます。
| 記号 | 例外 | 行き先と対応 |
|---|---|---|
| E1 | 受付時間外の入電 | 時間外の音声案内を流し、受付時間を伝えて終了 |
| E2 | 本人確認が一致しない | 書面またはWebでの手続きを案内し、結果コード「対応不可」で記録 |
| E3 | 顧客台帳が更新できない | SVに報告し、受付票に記録。システム担当が復旧後、受付当日中にオペレーターが更新して完了を折り返す |
| E4 | 引越しに伴う解約の希望 | 住所変更を終えてから解約のフローへ移る |
| E5 | 大声や暴言が続く | 別に定めたカスタマーハラスメント対応のフローへ |
例外ルートを書き出すときの手がかりとして、自治体のコールセンターの仕様書は参考になります。千葉市の高齢者予防接種コールセンターの仕様書は、受付時間外の入電に専用の音声案内を流す機能、受付時間内でもやむを得ず応対できない場合の案内、委託者への電話転送の機能を、受託者が用意する設備の条件にしています。毎日提出させる書類には折り返し対応の一覧表も含まれます。発注する側が最初から例外の行き先を条件に書いている例です。
描き終えたら、関係者と見比べて実態とのずれを直します。石川県のハンドブックも、作成したフローを関係者で確認し、手順の過不足や認識のずれを直すことを作成手順の1つに挙げています。オペレーターに見せると、描いた人が知らなかった例外が出てきます。それを書き足した図が、現状の図です。
AI導入やシステム更改の前に、フロー図で確かめること
描いた図は、AIやシステムに任せる範囲を決める材料になります。確かめることは3つあります。
まず、各箱に「AIやシステムに置き換える候補か、人が残るか」の印を付けます。本人確認や台帳の更新のように手順が決まっている箱は候補になり、例外ルートの行き先にある判断の箱は人が残ることが多くなります。業務ごとの向き不向きの考え方は自動化の向き不向きを整理した記事にまとめています。
次に、AIが人へ渡す地点を図の上で決めます。例外ルートの入口がそのまま候補です。E2やE3のような地点でAIが人に渡すとき、それまでに聞いた内容を引き継げるかどうかで、顧客が同じ説明を繰り返すかどうかが決まります。渡し方の設計はAIから人へ渡す設計の記事で扱っています。
最後に、置き換えたあとの図(改善後の図)を同じ記号で描きます。石川県のハンドブックも、現状の図をもとに改善策を反映した改善後の図を作ることで、役割や手順と現状との差分が明確になり、効果を見積もりやすくなるとしています。現状の図と改善後の図を並べれば、ベンダーの提案がどの箱を置き換え、どの例外を人に残すのかを、提案書の言葉ではなく自社の図の上で確かめられます。
まとめ
- 業務フロー図は用件1つにつき1枚。始点と終点を決め、AI導入の検討に使うなら後処理の完了まで含める
- 粒度は作業単位。「別の人やシステムに渡せる単位か」で判断する
- 記号は6種類程度に絞り、オペレーターとSVのレーンは分ける。箱には件数と時間のメモを添える
- 例外ルートには「誰が、いつまでに、何を」を書き、別の用件に変わったら別の図へ移る
自社のフロー図で、「SVに相談」の先が空白になっている箱はいくつあるでしょうか。
よくある質問
業務フロー図はどのツールで描けばよいですか。
表計算ソフトや図形描画ツールで十分です。大事なのは、記号の種類とレーンの並びを社内で決めておき、描く人が変わっても同じ形になることです。
業務フロー図とトークスクリプトはどう違いますか。
業務フロー図は誰がどの順で何をするかの流れを示し、トークスクリプトは各場面で顧客に何をどう話すかを示します。フロー図の1つの箱に、スクリプトの1場面が対応する関係です。
どの用件から描けばよいですか。
件数が多く、手順が比較的決まっている用件から描きます。最初の1枚で記号と粒度の決まりを固めると、2枚目以降が速くなります。
BPMNを使わないといけませんか。
現場と一緒に描く段階では必須ではありません。システムの要件定義やベンダーとの仕様の受け渡しで表記をそろえる必要が出たときに、BPMNへ描き直す方法があります。
注記: 本稿は2026年10月16日時点で確認した公開情報(確認日: 2026年10月16日)と、編集部の実務設計案によるものです。住所変更のフローと例外ルートは説明用の例で、実在の企業の業務を示すものではありません。自治体の資料は、業務フローの書き方と例外ルートの扱いの参考として引用しています。本稿はAI著者によるデスクリサーチであり、特定の製品やサービスの推奨ではありません。
出典
- 石川県「石川県BPR推進ハンドブック(2026年版)」
- 千葉市「令和8年度高齢者予防接種コールセンター運営業務委託 仕様書」
- Object Management Group「Business Process Model and Notation (BPMN)」
- AWS「Flows in Connect Customer(Amazon Connect 管理者ガイド)」
この記事はCC AI LabのAI著者(相馬 迅/相原 ことは)が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。



