お問い合わせフォームの内容をタスク化して抜け漏れを防ぐ

WordPress でコーポレートサイトを運用していると、大抵の場合フォームからのお問い合わせをメールで受け付けるような設定が多いと思われる。
中小企業でもそれなりの人数になってくると、「誰かがやっているだろう」「メールが多くて未読ばかり」といった感じになってくることがある。

DX の基本として、Teams を導入し社内メールを原則禁止とはしたものの、お客様とのやり取りに配布メールが含まれていたりして、毎日何十通ものメールが届くことを回避することはできない。
そこにフォームからのお問い合わせメールが届いたとしても、そもそも開いてもいなかったり、誰が返答したかもわからなかったりと、気が付くと抜け漏れが発生していることがあるため、フォームからのお問い合わせを Planner でタスク化し管理することとした。

なお、追加で 2 営業日を土日祝日判定して期限日を決めるフローと、 Teams のタグへメンションする方法も実装している。

前提条件

お問い合わせフォームは複数のメールアドレスに同時に送信できるプラグイン等を使用している
Teams が導入済み
Teams に専用のメールアドレスで投稿が可能（管理者が禁止している場合もあり）

事前準備

まずは Teams にお問い合わせフォームからのメール投稿を受け付ける専用のチャネルを用意した。チャネル名の右側三点リーダー（ … ）から「メールアドレスを取得」で Teams に投稿可能なメールアドレスを取得しておく。
次に、同じ専用チャネルのタブで「 Planner および To Do タスク Tasks」を開始し、お問い合わせを管理する Planner を作っておく。

WordPress のお問い合わせフォームには Contactform 7 を利用していたため、送信先のメールアドレスは複数設定することが可能であった。既存のメールアドレスに追加して先ほど取得したメールアドレスを設定、実際にフォームに投稿し Teams に自動的に投稿されることを確認しておく。

実装

ちょっとフローが多いが、完成形は以下のようになっている。

クリックして開く

タスクを作成する際に「宛先」と「対応期限」（2営業日）を処理しているため、少し複雑な処理が加わっている。フォームからの宛先がひとつで、対応期限にも特にこだわりがなければ省いてもよい。

まずはトリガーであるが、今回はフォームから Teams へのメール投稿が実施されたことをキーとして実行することにした。フォームからのメールは、お問い合わせの内容により各事業部のメールアドレスへ振り分けて送信されるため、メールを受け取ったことをキーにはできなかったためだ。
「チャネルに新しいメッセージが追加されたとき」をトリガーとして開始。最初に作っておいたチャネルを指定しておく。

次に投稿されたメッセージ内容から情報を取得する。「メッセージ詳細を取得する」フローを配置して、メッセージにはトリガーから取得できる「メッセージ ID 」を設定する。

メッセージの種類は「チャネル」とし、チームと先ほど作成したチャネルを指定しておく。
次に取得したメッセージから本文を抜き出す。今回は「Html からテキスト」フローを利用した。

Teams に投稿された本文は html で記述されているため、処理しやすくするためにテキスト化して取得している。html の方が処理しやすいのであれば変換は必要ない。

次に、投稿された Teams のタイトルはメールフォームから送られてくるメールタイトルそのままになっているため、場合によってはタスク名として使えない。そのため、本文から適切にタイトルとして使えそうな文言を抜き出すこととする。
ついでにタスク本文にメール本文の必要な箇所のみを転記するために、本文からも一部を抜き出す処理を追加する。

まずは宛先として文字列を抜き出すが、そのための本文中にある文言の文字位置を検索して抜き出す。「テキストの位置の検索」フローを追加して、テキストに先ほど html からテキスト化した本文を指定する。

検索テキストは、今回メール本文開始部分に「事業部にお問い合わせがありました。」との文言から始まっているため、「お問い合わせがありました。」を検索テキストに指定している。
これで「事業部に」の「に」の部分の位置が取り出せた。

ちなみに、「に」から選択していない理由は、現在のフォームの仕様により、「事業部にお問い合わせがありました。」のパターンと、「その他のお問い合わせがありました。」と業務内容に関する問い合わせのパターンが存在しているため、両方に対応するためである。このような特殊な事情でない限り検索テキストは適切な文言を設定すればよい。

次に「部分文字列」フローを追加して、テキストは変換後の本文、開始位置は最初なので「 0 」を指定、長さは上記特殊な事情がなければテキストの位置の検索で取得した位置をそのまま当てはめればよい。

今回は特殊な事情を考慮し、長さの部分にsub()関数を用いて「 1 」を引いている。

sub(outputs('テキストの位置の検索（宛先）')?['body'],1)

続けて本文を抜き出す。「テキストの位置の検索」フローを追加して変換後の本文を指定、フォームから送られてくるメールのお客様情報部分に「【お客様情報】」との記載があるため、そのまま検索テキストとして利用している。

文末まで取得しても良いが、Contactform 7 からのメールには、送信先が分かるようにサイトの情報が文末に含まれている。これを除去するためにもうひとつ「テキストの位置の検索」フローを追加して変換後の本文を指定、文末についてくるコメントの目前にある「 -- 」を検索テキストとして指定する。

さて実際に本文を抜き出す作業になるが、まずは「honbun」「matsubi」「mojisuu」の変数を用意した。

それら変数を設定していくが、まずは本文の変数について、値にはadd()関数を使用し 7 を足している。

add(outputs('テキストの位置の検索（本文）')?['body'],7)

これは「【お客様情報】」の文字数が「 7 」文字のためこの文字列を排除するためだ。もちろん必要がなければ普通に指定して頂いて問題ない。

次に末尾の変数だが、ここはsub()関数で「 1 」を引いている。余計な文字が入らないようにするためだ。

sub(outputs('テキストの位置の検索（末尾）')?['body'],1)

最後に文字数の変数だが、sub()関数で末尾から本文を引くことで作り出している。

sub(variables('matsubi'),variables('honbun'))

これらの数値を使用して「部分文字列」フローにて本文を抜き出す。

テキストには変換後の本文を指定、開始位置は「honbun」の変数、長さは「mojisuu」の変数を指定している。

さて、情報が揃ったことから、 Planner のタスクを登録していく。「タスクを作成する」フローを追加して、事前に作成していた Planner のグループ ID 、プラン ID 、バケット ID を記載していく。

タイトルには「部分文字列（宛先）」で抜き出した本文を使用し、分かりやすく文章にしてみた。
開始日時は Teams に投稿された際の作成時間をそのまま指定している。
期限日時が入っているが、これは別途オプションとして説明するためここでは触れない。

最後に「タスクの詳細の更新」フローを利用して、抜き出した本文をタスク内にも記載していく。

タスク ID には「タスクを作成する」フローで作られた ID をそのまま利用、説明には「部分文字列（本文）」で抜き出した本文を指定した。

これでフォームから送られてくるメールを Teams に投稿し、さらに Planner でタスクを作成するところまで完成した。

Teams にタスクが登録されたことを @メンションで通知する（オプション）

ここからはタスク作成には必須ではないが、同様に抜け漏れを防ぐための方法として、 Planner のタスクが登録されたことを Teams の投稿されたメッセージに返信する形で、さらに事業部毎に作られたタグ宛てに @メンションして通知するフローを追加してみる。

まずは抜き出した「部分文字列（宛先）」を利用してメンション先を取得することから始める。「スイッチ」フローを追加してオンに「部分文字列（宛先）」の本文を指定する。

次にスイッチ先を事業部の数だけ用意してメンションタグを取得する。 Teams にタグを用意していることが前提条件となる。

ケースには次の値と等しいに「部分文字列（宛先）」で取得できる事業部名を入れている。
タグのメンションを取得するには「タグの @mention トークンを取得する」フローを追加してタグを指定して取得している。

チームとタグ ID を指定するだけでメンショントークンが取得できる。
このメンショントークンを元に「チャネル内のメッセージで応答します」フローを追加して返信を投稿する。

投稿者は「User」でないとメンションはできないと思われる。今後のアップデートで可能になるかもしれないが、現時点ではフローを動作させているユーザーでの自動投稿となるだろう。
投稿先は「Channel」で、メッセージ ID には取得した Teams の投稿から Messageid を指定する。

あとはチームとチャネルを指定して、適切な本文を記載すればよい。本文には「タグの @mention トークンを取得する」で取得した「@mention タグ」を指定すればタグにメンションを送ることができる。

土日祝日判定を含めた 2 営業日を期限日に設定する（オプション）

せっかくタスクが自動作成されても、対応を行わなければ意味がない。タスクに管理者が担当者を割り振れば最初に通知が届く。しかしその後担当者がうっかり忘れてしまうとやはり抜け漏れにつながってしまう。

Planner では期限日が設定されていれば、期限切れに対して担当者に通知が届く。初期お問い合わせに対する返答は、少なくとも 2 営業日以内に返すのがよいと個人的に思っているので、作られたタスクにも登録日から 2 日後を設定していた。
ところが、金曜日にタスクが作られると日曜日が期限日になってしまうため、いろいろと都合が悪い。そこで、土日判定および祝日判定を実施して 2 営業日を割り出すこととした。

まずは土日祝日ではない営業日を判定する変数「holiday」と、土日祝日を判定する変数「weekday」を用意した。

営業日を判定する「holiday」にはとりあえず「 0 」を設定している。
土日祝日を判定する「weekday」は種類が「ブール値」だ。値としてただ「false」を指定している。

次に、まず最初の 1 日目が土日でないかを判定するところから開始する。その後のループを簡易にするために最初の土日判定は個別に設定した。土日を判定するために「スイッチ」フローを利用している。オンには Teams に投稿された日付情報を元にaddDays()関数を使用し +1 日で計算をしている。さらにその日付からdayOfWeek()関数で曜日の数値を取得した値をスイッチのデータとして利用した。

dayOfWeek(addDays(triggerOutputs()?['body/createdDateTime'],1))

この曜日の数値データを元に土日の判定を行っている。土曜日の場合「 6 」が返ってくるため次の値と等しいに「 6 」を指定する。

翌日が土曜日の場合（つまりお問い合わせは金曜日）最初の 1 営業日目は 3 日後になるため、変数「holiday」の値を「 3 」に設定する。

次に日曜日の場合であるが「 0 」が返ってくるため次の値と等しいに「 0 」を指定する。

翌日が日曜日である場合（つまりお問い合わせは土曜日）最初の 1 営業日目は 2 日後になるため、変数「holiday」の値を「 2 」に設定する。

ケースの「既定」には翌日が土日でなかった場合の設定を行っておく。

翌日が「土日ではない」と仮定して、最初の 1 営業日目は 1 日後として変数「holiday」の値を「 1 」に設定する。

ここから土日祝日判定をループで実施していく。「Do until」フローを追加して変数「weekday」が「true」になるまで繰り返す設定とする。最初に変数「weekday」を無条件で「false」に設定しているため、ここは必ず 1 回以上ループする。

祝日判定には Google カレンダーを利用する。「カレンダーのイベントの一覧を表示する」フローを追加し、Google のアカウントと連携したら、カレンダー ID を「日本の祝日」とする。

最小時間と最大時間は共に変数「holiday」の値を参照でいいのだが、まったく同じ時間を設定してしまうとデータを取得できなかった。そのため最小時間にはyyyy-MM-ddT00:00:00とフォーマットの指定で対象日の 0 時、最大時間にはyyyy-MM-ddT23:59:59と対象日の 24 時ギリギリ前を指定して設定している。

最小時間（ UTC 変換の必要があったためコードを修正）
~~addDays(triggerOutputs()?['body/createdDateTime'],variables('holiday'),'yyyy-MM-ddT00:00:00.0000000Z')~~

convertTimeZone(addDays(triggerOutputs()?['body/createdDateTime'],variables('holiday'),'yyyy-MM-ddT00:00:00'), 'Tokyo Standard Time', 'UTC')

最大時間（ UTC 変換の必要があったためコードを修正）
~~addDays(triggerOutputs()?['body/createdDateTime'],variables('holiday'),'yyyy-MM-ddT23:59:59.0000000Z')~~

convertTimeZone(addDays(triggerOutputs()?['body/createdDateTime'],variables('holiday'),'yyyy-MM-ddT23:59:59'), 'Tokyo Standard Time', 'UTC')

なお、対象日の取得にはaddDays()関数を用いて Teams の投稿時間をベースに、変数「holiday」の値を足している。変数にはその前の土日判定で 1 ～ 3 の数値が入っている。また、カレンダーからデータを取得するには UTC で日時を指定する必要があるためconvertTimeZone関数を用いて UTC 時間に変更している。

次に取得した祝日の情報を元に「条件」フローを追加して判定を実施している。empty()関数を用いて「カレンダーのイベントの一覧を表示する」フローから「イベントリストアイテム」を取得してブール値を得る。

empty(outputs('カレンダーのイベントの一覧を表示する（1営業日目）')?['body/items'])

次の値に等しいとしてfalseを比較対象とし、はいといいえの分岐処理につなげている。

判定が祝日だった場合、「変数の値を増やす」フローで変数「holiday」の値を 1 増やす。さらに「変数の設定」フローで変数「weekday」のブール値をfalseと設定している。

判定が祝日でなかった場合にも同様に「変数の設定」フローを追加している

設定で変数「weekday」のブール値をtrueと設定し、ループ終了の値を設定しておく。

次に「条件」フローを追加して土曜日であるかの判定を実施している。

お問い合わせが木曜日で金曜日が祝日だった場合、翌日が土曜日になってしまう。祝日は 1 日分しか判定していないため、祝日判定で日曜日になってしまうことはない、土曜だけ判断すれば問題はない。
判定にはdayOfWeek()関数で「 6 」の場合を取得すればよいので、addDays()関数により Teams の投稿時間から変数「holiday」の値を足して、equals()関数でブール値に変換している。

equals(dayOfWeek(addDays(triggerOutputs()?['body/createdDateTime'],variables('holiday'))), 6)

次の値に等しいでtrueだった場合は土曜日と判定する。

祝日判定で 1 追加されている場合で、さらに次の日が土曜日だった場合は、次の営業日は月曜日となる想定のため、「変数の値を増やす」フローにて変数「holiday」を「 2 」増やしておく。

なお、この時点ではまだ月曜日が祝日ではない判定ができていないため、「変数の設定」フローを追加して、変数「weekday」をfalseにしておくことを忘れてはいけない。

条件フローで土曜日でなかった場合は空にしておく。ループが繰り返されて、次の営業日が祝日でないかつ土曜日でもないとなった場合にtrueとなってループを抜ける。

2 営業日目の判定はループから開始している。まずは変数を調整するため「変数の値を増やす」フローを追加して変数「holiday」に「 1 」を足している。これは目前のループで 1 営業日目までの日数を作っているため、 2 営業日目となる +1 日を作っている。さらに変数「weekday」のブール値をfalseに戻して次のループに対応している。

変数が用意できたら「条件」フローを追加して先に土曜日判定を行う。これを行うことで 2 営業日目のループも 1 営業日目のループと同じ内容で作成できる。

判定条件も 1 営業日目のループ内で実施した土曜日判定と同じだ。

違うのはループ内ではないため、「変数の値を増やす」フローで変数「holiday」を +2 するだけで変数「weekday」の変更は実施しない。

そして「Do until」フローを追加して変数「weekday」がtrueになるまで繰り返す。

内容は 1 日目の判定と同じだ。まずは「カレンダーのイベントの一覧を表示する」フローを追加して情報を取得。次に「条件」フローを追加して祝日かどうか判定を行う。最後に「条件」フローを追加して土曜日判定を実施して繰り返しだ。

2営業日目までの日数が判定できたら「変数を初期化する」フローを追加して変数「timelimit」を設定する。

addDays(triggerOutputs()?['body/createdDateTime'],variables('holiday'))

値はaddDays()関数を使用して Teams の投稿時間に最終的に決まった日数の変数である「holiday」を足して日付データとして設定する。
この変数をタスク作成時の「期限日時」に設定すれば 2営業日後を期限としたタスクが作成可能となる。