Makeで問い合わせ台帳に返信候補を用意する設計例
広告／PR：この記事にはMakeの紹介リンクが含まれます。リンク経由で有料契約が成立すると、筆者に紹介料が入る場合があります。
問い合わせが届くたびに、相手の名前を台帳へ写し、相談内容を読み直し、返信の書き出しを作る。件数が増えると、文章を考える前の整理にも手間がかかります。
今回は、この作業を「問い合わせの記録 → 返信候補の作成 → 人による確認」の順に分け、MakeとGoogleスプレッドシートでつなぐ設計例を紹介します。
ここで扱うのは架空データを使った設計です。実運用での効果や動作はまだ検証していません。何分短縮できるかを約束するのではなく、導入前に決めることと、試すときの確認点をまとめました。
最初に対象を絞る
想定するのは、小規模な制作・事務支援の窓口に届く見積相談や打ち合わせの問い合わせです。
一度に複雑な返信まで完成させようとすると、価格や納期、空き時間についての判断も必要になります。まずは次の作業を対象にします。
- 問い合わせを同じ項目で記録する
- 相談種別に合った定型文を選ぶ
- 必須項目の空欄を確認する
- 返信候補と確認状態を一覧にする
金額の提示、納期の確約、日程の確定、契約条件の回答は担当者が判断します。苦情や返金の相談なども、定型の返信候補から外して個別確認に回します。
自動化の対象や人に残す判断が決まっていない場合は、AI業務効率化サービスを選ぶ前に確認したい7つの条件で、導入前の条件を整理できます。
台帳を先に決める
今回は、問い合わせが台帳の新しい行として登録された後の処理をMakeの担当範囲にします。入口のフォームやメール連携は、利用している窓口に合わせて後から決めます。検証では架空の問い合わせを手入力するだけで十分です。
台帳に用意する入力項目は、問い合わせID、受付日時、名前、メールアドレス、相談種別、相談内容です。処理を始めてよいかを示す「入力確定」も加えます。
出力欄には、返信件名、返信候補、確認状態、確認理由、テンプレート版を用意します。担当者用の修正欄は別にし、機械が作った候補と混ぜません。
問い合わせIDを付けるのは、同じ相談を繰り返し処理したり、別の行に書き込んだりする事故を見つけるためです。行番号だけで相談を識別する運用にはしません。
Makeを検討する目安
問い合わせの件数が増え、同じ項目の確認や定型文の準備を繰り返しているなら、Makeで処理をつなぐ価値を検討できます。担当者が候補の確認とエラー対応を続けられることも前提です。
一方、件数が少ない場合や、毎回個別の判断が多い場合は、台帳と定型文を整えるだけの運用から始めましょう。外部サービスに情報を渡せない場合も同様です。この例で自動化するのは、台帳に入力された後の処理です。フォームやメールからの転記を自動化する入口は含めません。
Makeが担当する処理
Makeの公式Google Sheetsモジュールには、新規行の取得、行の検索、行の更新が用意されています。この設計では、それらを使う構成を検討します。具体的な設定や動作は、利用する環境で確認が必要です。
処理の順番は次のとおりです。
- 新しく登録された問い合わせを取得する
- 入力確定、必須項目、問い合わせIDの重複を確認する
- 相談種別に応じて用意した定型文を選ぶ
- 同じ問い合わせの出力欄に返信候補を保存する
- 確認状態を「確認待ち」にする
この最小構成では、返信文を生成AIに作らせる必要はありません。決めた文章に名前などを差し込めば、内容と確認箇所を揃えやすくなります。
メールの送信処理は組み込みません。返信候補は台帳の中に置き、担当者が元の問い合わせを読んで修正します。送信は確認を終えた人が普段のメール画面から行う想定です。
架空の問い合わせで完成形を確認する
問い合わせID：DEMO-001
名前：デモ利用者A
メールアドレス：demo-a@example.com
相談種別：見積相談
相談内容：問い合わせ一覧を毎週まとめる作業を相談したいです。対象は月40件ほどです。
この入力に対して、用意する返信候補は次のようなものです。
件名：お問い合わせ内容の確認
デモ利用者A 様
お問い合わせありがとうございます。
お見積もりに必要な内容を確認するため、現在の受付方法、一覧にまとめたい項目、ご希望の開始時期をお知らせください。
いただいた内容を確認のうえ、対応範囲をご相談できればと思います。
この文面は説明用の候補です。実在の相手に送ったメールではなく、料金や対応可否も確定していません。
台帳には「確認待ち」と表示し、担当者が、すでに相談文に書かれていることを聞き直していないか、追加で必要な質問はないかを確認します。定型文を使っても、読み直しは必要です。
うまく処理できない行の置き場所を決める
運用で困りやすいのは、必要な情報が欠けている問い合わせや、判断しづらい相談です。
- 宛先や相談内容がない：返信候補を作らず「入力確認」
- 相談種別が「その他」：返信候補を作らず「個別確認」
- 同じ問い合わせIDが複数ある：自動更新を止めて重複を確認
- 人がすでに修正した行：修正内容を上書きしない
- 処理中に入力が変わった：元の内容のまま候補を保存しない
また、新規行の取得方法には注意が必要です。Makeの公式資料では、Watch New Rowsの対象シートに空白行があると、その後の行が処理されないと説明されています。入力データの間に空白行を挟まないことも検証項目に入れます。
新規行の取得だけでは、後から入力確定をYESに変えた行や、相談内容を編集した行を再処理できるとは限りません。確認担当者が未処理行と変更行を点検し、再処理へ回す方法を決めます。実装時にこの経路が動くことを確認するまでは、本番の問い合わせを任せません。
公式資料：新規行の取得とGoogle Sheetsモジュールの制約
時短効果は実際に測る
処理を動かせることと、毎日の仕事が楽になることは別に確認します。
同じ架空データを使い、手作業の場合と、この設計を実装した場合を比べます。記録するのは、転記や候補作成の時間、確認と修正の時間、誤り、処理から漏れた件数です。初期設定やトラブル対応の時間も残します。
確認や修正にかかる時間が増えるなら、項目や定型文を見直す必要があります。件数が少ない場合は、台帳と定型文を整えるだけで足りるかもしれません。
試す前のチェック
最初は実在の顧客情報を使わず、架空データを使います。このサイトの問い合わせ窓口や実在の顧客台帳へ接続済みという意味ではありません。
正常な問い合わせだけでなく、メールアドレスが空欄のもの、同じIDのもの、個別判断が必要なものも用意します。停止した後に再実行しても、人が直した文面が消えず、同じ問い合わせが増えないかを確認します。
本番の問い合わせを接続する前には、社内や取引先のルールに沿って、外部サービスで扱える情報、保存先、接続権限を確認してください。実行履歴にどのような内容が残るかも確認対象です。
外部へ実装を依頼する場合は、法人向けAI導入支援で失敗しやすいポイントも参考に、入力・候補作成・最終確認・障害対応を誰が担当するか決めておきましょう。
次に進めること
まずは、普段の問い合わせを一種類選び、台帳の項目と返信候補を紙やスプレッドシートに書き出してみてください。
その形で運用できそうなら、Makeでつなぐ対象を決めます。この記事で紹介したGoogle Sheets連携の仕様を確認し、架空データから検証を始めるのが次の一歩です。
無料・有料の範囲に加え、利用量の上限と実行間隔も確認してください。この設計のために有料契約が必要かどうかは、実際の構成と利用量を見て判断します。