Amazon Connectで「営業日/休業日」「受付時間内/受付時間外」を判定する手法4選

「うちのコールセンターは24時間365日運営だから！」という方には関係ありませんが、そうでない方の参考になれば幸いです。

#Amazon Connect

#コールセンター

#AWS Systems Manager Change Calendar

#AWS Systems Manager（SSM）

#AWS

青柳英明

2022.04.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

みなさん、こんにちは！
福岡オフィスの青柳です。

「Amazon Connect」を使ってコールセンターなどお客様からの電話を受け付けるサービスを構築する際に、曜日や時間によって「営業日/休業日」「受付時間内/受付時間外」を判定したいということは多々あると思います。

今回は、Amazon Connectで「営業日/休業日」「受付時間内/受付時間外」を判定する手法として、4つのパターンを紹介します。

パターン1： Amazon Connectの「オペレーション時間」を使って判定する
パターン2： Amazon ConnectからLambdaを使って「設定ファイル」を読み込み、判定を行う
パターン3： Amazon ConnectからLambdaを使って「設定データベース」を読み込み、判定を行う
パターン4：「Systems Manager Change Calendar」を使って判定する

2022/11/27追記：
本記事の続編を執筆しました。本記事を読み終わりましたら、こちらも併せてチェックしてみてください。

パターン1： Amazon Connectの「オペレーション時間」を使って判定する

Amazon Connectの標準機能として「オペレーション時間」の設定があります。

オペレーション時間とは、曜日毎に「電話を受け付ける時間帯」を定義することができるものです。

営業日 (上図の例では「月～金」) については、各曜日の受付時間を定義します。
曜日によって異なる受付時間を定義することもできます。

ここに定義していない曜日は、終日受け付けを行わない「休業日」となります。

オペレーション時間を使って「営業日/休業日」「受付時間内/受付時間外」の判定を行うには、コンタクトフローで「オペレーション時間を確認する」ブロックを配置します。

電話が着信した時刻が「オペレーション時間」の範囲内か範囲外かを判定して、後続の処理を分岐することができます。

上図の例では、オペレーション時間の「時間内」と判定された場合には「キューへ転送」ブロックへ進み、オペレーターへ電話を繋ぎます。
「時間外」と判定された場合には「プロンプトの再生」で受付時間外であるメッセージを再生した後、電話を切ります。

このように、特にプログラム処理などを用意しなくとも、Amazon Connect標準の機能で「営業日/休業日」「受付時間内/受付時間外」を判定することができます。

ただし、オペレーション時間の定義内容は毎週固定であり、祝日や夏期休業など特定の日付を臨時休業にしたり、一時的に受付時間を長くしたり短くしたり、といったことはできません。

パターン2： Amazon ConnectからLambdaを使って「設定ファイル」を読み込み、判定を行う

「オペレーション時間」で定義できる1週間の決まったパターンでは対応できない場合は、Amazon Connectの「Lambda連係」機能を使って判定処理を実装することになります。

最もシンプルなパターンとして、「営業日/休業日」「受付時間内/受付時間外」の定義をテキストファイルに記述して、これをLambda関数を使って読み込むという手法があります。

Lambda関数の処理概要は以下のようになります。

S3バケット上の設定ファイルから休業日や受付時間の情報を読み込む
現在の日時を取得する
現在の日時が「営業日」「受付時間」の範囲に入っているか、範囲外であるのかを判定する
結果を返す

このLamda関数をAmazon Connectインスタンスへ登録して、コンタクトフローから呼び出せるようにしておきます。

パターン1のコンタクトフローで「オペレーション時間を確認する」ブロックを使って判定していた部分を、「AWS Lambda関数を呼び出す」「コンタクト属性を確認する」の各ブロックに置き換えます。

これで、設定ファイルで定義した「営業日/休業日」「受付時間内/受付時間外」の情報を使って判定を行うことができます。

下記ブログ記事で、実際にLambdaを使って祝日等の判定を実装する方法が紹介されています。
参考にしてください。

パターン3： Amazon ConnectからLambdaを使って「設定データベース」を読み込み、判定を行う

パターン2の方法によってAmazon Connect標準機能の「オペレーション時間」では実現できない「祝日」などの判定が行えるようになりました。

しかし、テキストファイル形式の設定ファイルを用いる方法であるため、以下のような課題も見えてきます。

テキストファイルの編集時に、書式を誤って保存してしまうと、Lambda関数がエラーとなる
「テキストファイルを編集してS3バケットにアップロードする」という作業は、比較的簡単とは言え、ある程度のITスキルが必要
他のシステムが持っている営業日・受付時間の情報との連係が難しい

そこで、テキストファイル形式の設定ファイルの代わりに、DynamoDBやRDSなどの「データベース」を用いる方法を検討してみます。

テキストファイルからデータベースへ変更することで、改行コードの問題やCSVの「カンマ」の記述漏れなどによるエラーを回避することができます。
また、データベースのテーブル定義でデータ値の「型」を明確にすることもエラー回避に有効です。

加えて、データベースを用いることによって、以下のようなことも行い易くなります。

管理者や運用担当者に向けて「データ管理画面」を用意することで、データベースの知識が無いスタッフでもデータの管理を行えるようにする
データベースの情報を基にWebサイト等へ営業日や受付時間を掲示することで、エンドユーザーへ案内できるようにする
他システムとの間で営業日・受付時間の情報連係を行う

Lambdaとデータベースを用いた判定の具体的な実装方法については紹介を省略します。
みなさんで試してみてください。

パターン4：「Systems Manager Change Calendar」を使って判定する

最後のパターンは少しアプローチを変えてみます。

AWSにおいて「カレンダー」や「スケジュール」を取り扱うことができるサービスとして、「AWS Systems Manager (SSM)」の「Change Calendar」という機能が用意されています。

上記のブログ記事で紹介している通り、基本的にChange CalendarはSystems Managerの各種機能から利用することを前提としていますが、AWS SDKを使うことでLambda関数など外部プログラムやアプリケーションから利用することもできます。

このことを利用して、「営業日/休業日」「受付時間内/受付時間外」の判定を「Systems Manager Change Calendar」に登録した情報を使ってLambda関数で行います。

「Systems Manager Change Calendar」を使うパターンには、以下のようなメリットがあると考えます。

「Systems Manager Change Calendar」はAWSのマネージドサービスであるため、設定ファイルやデータベースを実装する必要なくカレンダーを利用できる
「祝日データ」「受付時間データ」といった異なるカレンダーを用意しておき、複数のカレンダーを組み合わせて判定を行うことができる
Systems Managerで既に「Change Calendar」を使ってサーバーやAWSリソースのスケジュール管理を行っている場合、同じカレンダー情報を使ってAmazon Connectの営業日判定が行える

具体的な利用方法についてですが、偶然にも本日坂巻が「Change Calendar」を使ってAmazon Connectで休業日判定を行うブログ記事を公開していました。

是非、こちらを参照してみてください。

おわりに

Amazon Connectで「営業日/休業日」「受付時間内/受付時間外」を判定する手法の「4つのパターン」を紹介しました。

それぞれのパターンの使い分けは、以下のように検討すると良いのではないかと思います。

パターン1： Amazon Connectの「オペレーション時間」を使って判定する
- Amazon Connectの標準機能のみで実現できる
- 祝日などを考慮せず1週間の決まったパターンで対応可能な場合は、この方法が最もシンプル
パターン2： Amazon ConnectからLambdaを使って「設定ファイル」を読み込み、判定を行う
- 祝日などを考慮しなければならない場合、テキストファイルベースでシンプルに実装できる
- 小規模・中規模のシステムで、IT管理者が電話受付時間の管理も行うような場合には有効な方法
パターン3： Amazon ConnectからLambdaを使って「設定データベース」を読み込み、判定を行う
- 大規模なシステムで、非IT部門の運用担当者が電話受付時間の管理を行う必要がある場合、この方法を検討
- 他システムとの連係や、エンドユーザーへの受付時間案内など、いろいろな応用も考えられる
パターン4：「Systems Manager Change Calendar」を使って判定する
- Systems Managerで既にスケジュール管理を行っている場合や、今後スケジュール管理をSystems Managerへ集中したい場合などに検討