前回は、WordPressで受けた問い合わせを整理しやすくする仕組みの全体像をまとめました。
この記事では、その仕組みをどう設計したのかについて書いていきます。
何をどこで担当させるかを分けて考えると、扱いやすいものになると思います。
問い合わせ整理アシスタントの構成の流れ
↑Slackに来る通知↑
下記のようなが流れで動きます。
- WordPressで問い合わせを受ける
- 通知メールとして受け取る
- GASで内容を取り出して整える
- Difyで問い合わせ内容を整理する
- Google Sheetsへ保存する
- Slackへ通知する
今回使うものとしては、次の組み合わせになります。後述しますが、問い合わせフォームなどの窓口は今後広げる想定で設計しています。
- WordPress
- Gmail
- GAS
- Dify
- Google Sheets
- Slack
それぞれに何を担当させるか
WordPress
WordPressは、問い合わせの入口です。
必要な情報を受け取るところに役割を絞ります。
Gmail
Gmailは、通知メールの受け皿です。
問い合わせ内容を一度メールとして受けることで、その後の処理につなげやすくなります。
GAS
GASは、中継と整形を担当します。
- メール本文から必要な情報を取り出す
- 共通の形に整える
- Difyへ送る
- 結果を保存する
- 通知する
今回の仕組みでは、GASがかなり重要な役割になります。
Dify
Difyは、問い合わせ内容の整理役です。
- 要約
- 分類
- 優先度の整理
- 推奨対応
- 返信要否の判断
- 返信文のたたき台
といった部分を担当させています。
Google Sheets
Google Sheetsは、記録と一覧化のための保存先です。
元の問い合わせ内容と整理結果をまとめて残しておくと、後から見返しやすくなります。
Slack
Slackは、気づくための通知先です。
新しい問い合わせが来たことを見落としにくくします。
なぜ役割を分けるのか
問い合わせ整理のような仕組みは、AIに全部やらせようとすると、かえって分かりにくくなることが多いです。
たとえば、
- メールのどこから情報を抜くか
- それをどんな形に整えるか
- 何をAIに判断させるか
- どこへ保存するか
これらをすべてAIに任せてしまうと、どこでズレたのか追いにくくなります。
そのため「問い合わせ整理アシスタント」では、
- 取り出す
- 整える
- 判断する
- 残す
- 通知する
という流れにして、役割を分けています。
このように役割を分けると、仕組みそのものが分かりやすくなるだけでなく、後から直しやすく、拡張性も広がります。
今回の設計で重要なところ
下記の点を重要視しています。
- フォームそのものに依存しすぎない
- 入力と整理の役割を分ける
- 問い合わせ内容を共通の形にそろえる
- あとから広げやすくする
共通データ構造を先に決める
今回の設計でかなり大事なのが、共通データ構造です。
たとえば、最終的に問い合わせ内容を次のような項目にそろえるイメージです。
- 名前
- メールアドレス
- 問い合わせ種別
- 問い合わせ本文
- 受信日時
入力元が何であっても、最終的にこの形へそろえられれば、Difyに渡す整理ロジックは流用しやすくなります。
逆に、フォームごとに作り方を変えすぎると、あとで別の入口へ広げにくくなります。
なぜこの考え方が大事なのか
今はWordPressの問い合わせフォームを起点にしていますが、みんながみんなWordPressの問い合わせフォームを使っているわけではありません。
- Googleフォーム
- Gmailへ直接届く問い合わせ
- LINE
- SNSのメッセージ
- 別のWordPressフォーム
こうした入口が増えても、最終的に同じ項目へそろえられれば、整理の仕組み自体はあまり変えずに窓口を増やすことが可能です。
変わりやすいのは「取得方法」で、変わりにくいのは「整理したい内容」です。
Difyの役割はAIが得意な整理、分類、要約
↑Difyのノードはとてもシンプルです↑
Difyには、下記のような役割を持たせています。
- 問い合わせ内容の要約
- カテゴリ分類
- 優先度整理
- 優先度の理由
- 最初に取りやすい対応
- 返信が必要かどうかの判断
- 返信文のたたき台
ここで意識しているのは、Difyは整理と判断の担当にすることです。
メール本文から必要項目を抜き出すような処理までAIに持たせるのではなく、まずは扱いやすい形に整えてから渡すほうが安定します。
GASを中継役にする理由
今回の構成では、GASが非常重要です。まさに司令塔です。
役割としては、
- Gmailから対象メールを取る
- 本文から情報を抜く
- 共通の形に整える
- Difyへ送る
- 返ってきた結果を保存する
- Slackへ通知する
という役割をまとめて持たせています。
保存先をGoogle Sheetsにしている理由
今回は保存先をGoogle Sheetsにしています。
まずは一覧で見やすく、確認しやすい形を優先しました。
- 元の問い合わせ内容を見返しやすい
- 整理結果と並べて見やすい
- エラー時に確認しやすい
- 後でNotionやCRMへ広げる前段として使いやすい
この設計で広げやすくなること
今回の設計にしておくと、今後は次のような広げ方がしやすくなります。
- 返信下書きの精度を上げる
- 別チャネルの問い合わせも整理対象にする
- 通知先を分ける
- 担当者別の運用につなげる
- 顧客管理へ広げる
つまり、今は小さく始めつつ、必要に応じて少しずつ育てやすい構成です。
まとめ
今回の設計で大事にしたのは、ツールを並べることではなく、役割を分けることでした。
問い合わせ対応の流れを、
- 受ける
- 整える
- 判断する
- 残す
- 気づく
に分けて考えると、仕組みはかなり整理しやすくなります。
特に、今後フォームや窓口が増える可能性を考えるなら、入力方法と整理方法を分けておくことは重要なポイントだと思います。
次回は、この仕組みを実際にどう組んでいくのか、設定や流れをもう少し具体的にまとめます。
- 問い合わせ業務を改善したい
- 抜け漏れを減らしたい
- 自社の運用に合う形で仕組みを考えたい
という方がいれば、無料相談・お問い合わせからお気軽にご連絡ください。
今の運用に合わせて、どこまで自動化するのがちょうど良いか、一緒に整理できればと思います。
コメント