Webの修理受付に届く住宅設備の修理依頼を、症状・保証・地域で仕分け、返信の下書きをつけて担当の窓口へ回す

処理の起点を決める

受付の共有アドレスに届いたフォームのメールに、ラベルが付いたことを起点にします。 Gmail のフィルタで、フォームの送信元のアドレスと決まった件名のメールに「修理受付」のラベルを付けます。Zapier の New Labeled Email でそのラベルを見張ります。 フォームのメール以外（お客さまからの直接のメールや、拠点からの連絡）にはラベルが付かないので、仕分けに入りません。

1件ずつ、届いた順に動かします。 1日1回まとめて仕分けると、朝に届いた安全に関わる依頼が夕方まで品質保証に届きません。安全の印を早く付けることが、この構成でいちばん大事な仕事なので、届いたたびに動かします。

Zapier の Gmail のトリガーは、一定の間隔で新しいメールを確かめる形です。届いてから Zap が動くまでに数分の差があります。 安全に関わる依頼には、品質保証へ知らせたうえで人が電話をかけるので、数分の差は運用で吸収します。

入力データを集める

質を決めるのは、型番の一覧の「よくある症状と案内の文」の列です。 「乾燥が終わらない → フィルターの掃除の手順」「エラーE3 → 給水の確認」のように、案内で済む症状を型番ごとに並べておくと、AIの区分と結び付けて、使い方の案内に回せます。 この列は、経験のある担当者が頭の中に持っている知識を書き出したものです。

安全に関わる症状の語は、品質保証部が決めます。 受付の担当者やAIが決めるものではありません。語の一覧をAIに渡し、それに当たる記述があるかを判定させます。

データの取得方法を決める

型番は、AIが書かれたとおりに取り出したものを、読み替え表で直してから引きます。 型番の一覧で引けなければ、読み替え表で引き直します。それでも引けなければ、似た型番を探すことはせずに、受付の担当者へ回します。 似た型番をAIに推測させると、別の製品と取り違えます。

保証の終わりの日は、Formatter の Add/Subtract Time で出します。 式（Expression）に「+12 months」のように保証期間を入れ、購入日に足します。今日の日付は {{zap_meta_human_now}} で入れられます。 AIに日付の計算をさせません。

AIへ渡す前に整形する

1. フォームのメールの本文を項目ごとに分ける … フォームのメールは「型番：」「症状：」のように項目名と値が並んでいます。項目名をそのまま残してAIに渡し、どの値がどの項目かを取り違えないようにします
2. 購入日の書き方を確かめる … 「2024年3月」「去年の春」「新築のとき」のように書かれます。AIには書かれたとおりに写させ、年月日として読めるものだけを日付にします
3. 電話番号と住所はAIに渡さない … 判定に要るのは郵便番号の上3桁までです。氏名、電話、住所の番地は、AIに渡す本文から落とします
4. 同じお客さまの再送を確かめる … 送信が2回届くことがあります。受付の台帳を、郵便番号と型番と届いた時刻で引き、10分以内の同じ組み合わせは重複の印を付けます
5. 型番の読み替え … 取り出した型番を、読み替え表で正しい型番に直します

3番目を省かないでください。 症状の判定に、お客さまの名前や電話番号は要りません。AIに渡す範囲を、判定に要るものだけに絞ります。 拠点への連絡と返信の下書きには、Zap の中でフォームの元の項目を差し込みます。

AIに処理させる

させるのは、症状の区分を1つ選ぶこと、安全に関わる症状の有無を判定して根拠を写すこと、型番と購入日を書かれたとおりに取り出すことだけです。

安全に関わる症状だけは、迷ったら「あり」に倒します。 ほかの判定は、迷ったら「その他」や空に倒し、受付の担当者へ回します。安全の判定を誤って「なし」にすると、焦げたにおいの依頼が出張修理の列に並び、拠点の日程の調整を待つことになります。 「あり」に倒して品質保証が電話をかけ、何も無かったという空振りは、受け入れられる誤りです。

4行目は、とくに大事です。 安全に関わる依頼を受けたあと、それが製品事故に当たるか、報告が要るかを判断するのは品質保証です。AIには「安全に関わる記述がある」という事実だけを返させ、事故かどうかの言葉を使わせません。

指示内容を固定する

あなたは住宅設備メーカーの修理受付で、Webのフォームから届いた依頼を読み、
決まった項目に判定と取り出しの結果を入れる立場です。
渡したフォームの項目だけを見て判定してください。推測で補わないでください。

【症状の区分】次から1つだけ選んでください。
電源が入らない／エラーの表示／水漏れ／異音・振動／動作の不良／
部品の破損・紛失／使い方・設定の質問／その他
迷ったときは「その他」を選んでください。

【安全に関わる症状】
次の語の一覧に当たる記述が、症状・エラーの表示・設置場所の欄にあるかを判定してください。
{safety_terms}
- 当たる記述があれば safety を "yes" にし、safety_evidence に記述をそのまま写してください。
- 言い換え（「こげくさい」「ぼや」「プラスチックが溶けた」など）も当たるものとしてください。
- 迷ったときは "yes" にしてください。
- 「事故」「欠陥」「危険」という言葉を、判定の結果に書かないでください。

【取り出し】
- model_raw：型番の欄を、書かれたとおりに写してください。直さないでください。
- purchase_raw：購入日の欄を、書かれたとおりに写してください。
- purchase_date：年月日として読めるときだけ YYYY-MM-DD で書いてください。
  年と月しか無いときは、その月の1日にしてください。読めなければ空にしてください。
  「去年」「新築のとき」などから日付を計算しないでください。
- error_code：エラーの表示を、書かれたとおりに写してください。

【厳守事項】
- どの窓口に回すか、保証期間内かどうかを書かないでください。
- 修理の費用、訪問の日程を書かないでください。

【フォームの項目】{form_fields}

「年と月しか無いときは、その月の1日にする」と決めているのは、保証の見込みを控えめにするためです。 月の1日にすると、保証の終わりの日がいちばん早く出ます。保証期間内と案内したのに期間外だった、という誤りの側に倒れないようにします。 それでも期間の終わりの前後1か月に入る依頼は、規則の側で「保証の確認が要る」にします。

「事故」「欠陥」という言葉を書かせないのは、台帳と社内の連絡に残るからです。 判定の結果が「事故」と書かれた行が台帳に並ぶと、事実を確かめる前に社内でそう扱われてしまいます。 返させるのは「安全に関わる記述がある」という印と、その記述だけです。

出力形式を固定する

AI by Zapier の出力の項目（Output Fields）として、次の項目を決めておきます。 「必ず返す」の印を付けた項目が空で返ったときは、Paths の Fallback で受付の担当者へ回します。

項目に分けて受ける1つ目の理由は、Paths の規則でそのまま使えることです。 safety が yes なら品質保証、category が「使い方・設定の質問」で型番の一覧に案内の文があれば使い方の案内、という規則を、項目の値と条件の組み合わせで書けます。

規則は次の順に評価します（Paths の各分岐の条件）。

2つ目の理由は、保証の見込みを日付の規則で決められることです。 Zapier のフィルタと分岐の規則には、日付が別の日付より後かを確かめる (Date/time) After があります。保証の終わりの日が今日より後なら「保証期間内の見込み」、前なら「保証期間外の見込み」、購入日が空なら「保証の確認が要る」とし、返信の下書きの文を切り替えます。

Paths は1つのグループに10本まで分岐を持て、入れ子は3段までです。 窓口の分岐の中に、保証の見込みの分岐を1段入れる形で収まります。

システムへ連携する

お客さまへの返信は、送らずに下書きにします。 Create Draft Reply は届いたメールへの返信の下書きを作るだけで、送るのは受付の担当者です。 フォームのメールの返信先がお客さまのアドレスになっていることを、最初に確かめます。

返信の下書きの文は、窓口と保証の見込みの組み合わせごとに、決まった文の型を用意します。 型には、受付の連絡、修理の流れ（拠点から訪問の日程の連絡が行くこと、部品を送ること）、保証の見込みの書き方を入れます。保証の見込みは「保証期間内と思われます。保証書を拝見して確定します」のように、見込みであることを必ず書きます。

人が確認する

安全の分岐に回った依頼は、品質保証の担当がすぐに電話をかけます。 ここは自動にしません。

1. 品質保証は、安全の根拠の写しを読む … フォームの元の文と一緒に読み、電話で状況を聞いて、使用の中止を案内します
2. 受付の担当者は、返信の下書きを読んで送る … 窓口と保証の見込みが、フォームの内容と合っているかを確かめます。型番と購入日は、元の文と見比べます
3. Fallback の依頼を読む … 型番が引けない、区分が「その他」の依頼は、受付の担当者が読んで窓口を決めます
4. 判定を直したら台帳に残す … 区分や回した先を変えたら、元の判定と直した先を記録します

2番目の見比べを省かないでください。 型番の読み替えで別の型番に直っていないか、「2024年3月」が「2024-03-01」になっているかを、1件数秒で確かめられるよう、台帳には元の文と取り出した値を並べて書きます。

目標は、600件をならして1件2分です。 返信の下書きを読んで送るだけの依頼は1分前後、Fallback の依頼は数分かかります。Fallback が全体の1割を超える月は、型番の読み替え表か、案内の文の列が足りていません。

例外に対処する

上の3行が、Fallback の大半です。 どれもAIの問題ではなく、表の整備の問題です。 台帳の Fallback の行を月に1回見て、読み替え表と割り当て表に足します。

記録を残す

• フォームのメールの受け取った日時と、Zap が動いた日時
• AIに渡した本文（氏名・電話・住所の番地を落とした後のもの）
• AIが返した項目の全文（category、safety、safety_evidence、model_raw、purchase_date）
• 型番の読み替えの有無、引いた製品の種類・修理の方法・保証期間、保証の終わりの日
• 回した窓口と拠点、Paths のどの分岐を通ったか
• 人が判定や窓口を直した記録
• 品質保証が連絡した日時と、その後の対応の記録（品質保証の側の記録へのつなぎ）

5つ目と6つ目は、規則を直す材料になります。 使い方の案内に回したのに、結局出張修理になった依頼が続く症状があれば、型番の一覧の案内の文が足りていないか、間違っています。

最後の行は、品質保証が別の記録で管理します。 受付の台帳には、連絡した日時までを残し、その後の事実の確認や報告の判断は、品質保証の記録の側に残します。