コロナ禍で急速に求められたテレワーク移行。その中でも最もネックになったのが、チームで受ける電話対応でした。
本記事では、Amazon Connectを使ってコールセンター機能をクラウド化し、構想からわずか1週間で本番運用に乗せた社内事例を紹介します。単なる成功談ではなく、「なぜ他の選択肢を捨てたのか」「実際にどの作業を1週間でやったのか」「運用で詰まったポイントは何か」まで踏み込み、再現性のある判断材料としてまとめています。
コロナ禍によって生じた課題と対策
ディーネットでは、テクニカルサポート部隊が24時間365日体制でお客様のWEBインフラを支えています。
導入内容
ディーネットでは、テクニカルサポート部隊が24時間365日体制でお客様のWEBインフラを支えています。
全体概要
お客様へ公開している、テクニカルサポート用の電話番号を変更するわけにはいきません。ここを変更してしまうと、お客様への影響が大きくなりすぎてしまいます。そこで、お客様が発信する番号はそのまま維持し、「Amazon Connect」へ転送させることにしました。
転送された「Amazon Connect」では、ルールに従い担当者への割り振りを行います。
反対にテクニカルサポートからお客様へ発信するときは、以前のようにテクニカルサポート用の番号は使えません。その代わりに、「Amazon Connect」から払い出されるIP電話の番号が発信元となります。
お客様の携帯電話へ着信した時の電話番号が変更になってしまいますが、発信元の番号が統一されることで、お客様からの折り返し電話をチームで受けることが可能です。ここについては、お客様へ影響が出る部分となるので、周知を行っています。
着信フロー
導入前は、受電があると対応可能なメンバーが電話にでていました。これは、メンバーが一か所に集まっていないとできません。
「Amazon Connect」では、着信フローを組むことができるので、対応者の優先順位を考慮してフローを組み立てました。
電話対応を最優先で行うのは、テクニカルサポートメンバーとしました。受電があると、「Amazon Connect」がオンライン中のテクニカルサポートメンバーを探します。オンラインメンバーがいた場合、そのメンバーのソフトフォン（ブラウザ上で操作するAmazon Connect専用の電話端末ソフト）が鳴り、そのまま電話対応を行います。
オンラインメンバーが複数人いた場合は、待機時間が長いメンバーが優先的に鳴動します。これによって、対応者の偏りを減らすことができます。
もし、オフラインだった場合は、第二優先のテクニカルサポート以外のエンジニアを対象にオンライン判定を行います。オンラインのエンジニアがいればそのエンジニアが対応し、オフラインであれば「混雑中」の自動応答が流れる仕組みです。
導入効果と懸念点
実際に、テクニカルサポート業務に導入してみて、大きなメリットを感じることができました。反対に多少のデメリットも存在しているのでまとめてみます。
利用料金
「Amazon Connect」で発生する主要な料金は次の通りです。ディーネットの実績としては、毎月1万円以内に収まっています。
| 項目 | 単価 | 単位 |
|---|---|---|
| 電話番号の開通 | $0.1 | 日 |
| 通話料金 発信 | $0.1 | 分 |
| 着信 | $0.003 | 分 |
| AmazonConnect利用料金 | 0.0180(発信/着信の合算) | 音声1分ごとに |
| S3利用料金 | $0.023 | GB（音声録音データがある場合） |
関連するFAQ
Q. なぜ転送サービスやクラウドPBXではなくAmazon Connectを選んだのですか？
A. 転送サービスは特定の担当者に着信が偏りやすく、チームで均等に受ける運用に向きませんでした。クラウドPBXはベンダー選定や導入リードタイム、仕様調整の不確実性があり、緊急対応には不向きでした。Amazon Connectは自社で即時構築でき、待機時間ベースの自動振り分けなど柔軟な制御が可能だった点が決め手です。
Q. 「1週間で導入」の具体的な内訳は？
A. 概ね以下の流れです。
• Day1：要件整理・構成決定（既存番号転送＋簡易フロー）
• Day2：Amazon Connect環境構築・電話番号払い出し
• Day3：着信フロー作成（オンライン判定・優先順位・混雑応答）
• Day4：既存番号の転送設定・発信テスト
• Day5：通話録音・履歴確認・権限設定
• Day6：運用ルール整備（ステータス管理・シフト時の確認手順）
• Day7：全体テスト後、本番切替
シンプルな構成に絞ったことが短期化のポイントです。
Q. 月額1万円以内に収まった条件を教えてください
A. 少人数のテクニカルサポートチームで、通話時間が極端に長くない前提です。課金は「通話分数＋利用分数」の従量制のため、通話量と同時接続数が増えると比例して上がります。本事例は常時大規模ではない運用だったため、この水準に収まりました。
Q. 着信から対応までの流れはどうなっていますか？
A. 既存番号→Amazon Connectへ転送→オンラインの担当者を検索→複数いれば待機時間が長い人へ着信→不在時は第2優先へ→全員不在なら自動応答、という流れです。これにより在宅でも偏りなく分配できます。
Q. 実際に起きた運用トラブルは？
A. 代表的なのは以下です。
• ステータス更新漏れ：オンラインのまま離席し、着信が滞留
• VPN切替時の音声不通：受話後に音声が届かないケース
• 環境依存の音質劣化：ヘッドセットや回線品質の影響
いずれも「運用ルール明確化」「事前チェック」「機器見直し」で徐々に改善しました。
Q. ステータス管理の課題はどう対処しましたか？
A. 手動更新が前提のため、シフト交代時のチェックや離席時のルールを明文化しました。導入初期は交代タイミングで疎通テストも実施し、人的ミスを減らしています。
Q. 小規模チームでも現実的に運用できますか？
A. 可能です。むしろ本事例のように少人数・シンプル構成のほうが短期間で立ち上げやすく、コストも抑えやすいです。拡張も段階的に行えます。
まとめ
コロナ禍の影響によるテレワーク対応として「Amazon Connect」の導入実績をご紹介してみました。
準備期間が短かったこともあり、極力シンプルな問い合わせフローを迅速に構築しました。
ディーネットでは、お客様向けに「Amazon Connect」の導入サポートを提供しています。シンプルな使い方以外にも、「CTI」との統合や、50名以上のエージェント数がいる大規模コールセンターの実績があります。Amazon Connectに興味がある方はぜひご相談ください。