時計店がオーバーホールの依頼を Make で受け、症状・型式・付属品から受付の区分を判定して、料金表から概算を添えた返信の下書きを作る

処理の起点を決める

フォームの送信を起点にします。 フォームの送り先を Make の Custom webhook の URL にし、受け取るとすぐにシナリオが動きます。Webhook は既定で並行に動くとされていますが、この構成では受付の番号を順に振りたいので、「Process data in order」を有効にして1件ずつ処理します。

シナリオの最初に Webhook response を置き、受付の番号をお客様の画面に返します。 公式のページでは、Webhook response を途中に置くとその後のエラーが送り手に伝わらないことがあるとされています。この構成で返すのは「受け付けました」と番号だけで、判定の結果は返しません。 判定の後で止まっても、お客様には受付の番号が残り、店の側には未処理として残ります。

受付台帳には、Webhook を受けた時点で「受付済み・判定前」の行を足します。 判定と下書きまで終わったら「下書きあり」に変えます。朝に「判定前」のまま残っている行があれば、途中で止まった依頼です。

メールで届く依頼は、受付の店員がフォームに写します。 経路を2つにすると、メールの依頼だけが判定されない日が出ます。電話の依頼も同じフォームに入れます。

入力データを集める

質を決めるのは、フォームの設問です。 症状は「止まる・遅れる・進む・竜頭が回らない・ガラスが曇る・その他」から選ばせ、その下に自由記述の欄を置きます。付属品は「保証書・箱・余りのコマ・替えのベルト・購入時の明細」をチェックで選ばせます。 自由記述だけにすると、AI が読む前に足りない情報が決まってしまいます。

裏蓋の型式の欄には、どこを見ればよいかの写真を添えます。 裏蓋に刻まれた番号を書いてもらえれば、型式の表で駆動の方式が引けます。書かれていなければ、聞き返す質問の筆頭になります。

過去の修理の履歴は、「他の店で修理したことがある」を選べるようにします。 メーカーへ取り次ぐときに、他店での修理の有無を聞かれることがあるからです。

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

型式の表は、AI より先に引きます。 駆動の方式と取り次ぎ先が分かっていれば、AI に渡す材料がそろいます。型式が表に無ければ、駆動の方式を「不明」として AI に渡し、AI に方式を推し量らせません。 型式の書き方の揺れ（ハイフンの有無、大文字と小文字）は、引く前に Make の側でそろえます。

料金表は、AI の後に引きます。 AI が返した症状の型と、型式の表の駆動の方式の2つで1行を引きます。引けなければ概算の欄は空のまま、区分を「現物を見てから」に寄せます。

AIへ渡す前に整形する

1. 型式の表記をそろえる … 全角を半角に、小文字を大文字にし、ハイフンと空白を外します
2. 購入の時期を年に直す … 「5年くらい前」のような書き方は、そのまま残して AI に渡します。年に直せるものだけ直します
3. 連絡先を外す … 氏名・電話番号・メールアドレスは AI に渡しません。受付の票と返信の宛先にだけ使います
4. 同じお客様の二重の送信を外す … 同じ連絡先から同じ内容が数分のうちに2回届いたら、1件として扱います

1. 自由記述の長さを確かめる … 症状の自由記述が極端に長いもの（経緯を何年分も書いたものなど）は、そのまま渡しますが、票に「長文」の印を付けて技能を持つ店員が全文を読めるようにします

3番目を軽く見ないでください。 判定に要るのは時計の情報だけです。AI に渡す本文には、受付の番号と時計の情報だけを並べます。

1番目は、型式の表の側にも同じ処理をかけておきます。 表の型式を書いた人と、依頼を書いたお客様で表記が違うのはふつうのことです。両方を同じ形にそろえてから比べれば、表を書き直さずに当たる率が上がります。

AIに処理させる

させるのは、依頼の内容から症状の型と受付の区分を判定し、足りない情報と聞き返す質問を書き出すことです。

受付の区分の決まりは、店が決めて指示に埋め込みます。

difficult は断る区分ではありません。 技能を持つ店員に回して、受けられる方法を探すか、お断りするかを人が決めるための印です。

判定の例を3つ挙げます。

3つ目のように、型式が表に無く注意の印もあるものは、迷わず inspect_first です。 判定の例を指示に入れておくと、区分の決まりの読み方が月ごとにぶれにくくなります。

指示内容を固定する

あなたは時計店の修理の受付で、オーバーホールと修理の依頼を読む担当です。
渡された依頼の内容と型式の表の情報だけを使って判定してください。

【症状の型】{symptom_types}
【受付の区分の決まり】{intake_rules}

【厳守事項】
- 依頼に書かれていることと、型式の表の情報だけを使ってください。
  書かれていない症状や故障の原因を補わないでください。
- 駆動の方式は、型式の表の値をそのまま使ってください。
  表の値が「不明」なら、方式を推し量らず intake を inspect_first にしてください。
- 金額を書かないでください。概算は別の仕組みで出します。
- 「修理できません」「お断りします」と書かないでください。
  受けるのが難しそうなときは intake を difficult にし、理由を reason に書いてください。
- 迷ったときは inspect_first を選んでください。shop を選ぶのは、
  決まりのすべてに当てはまるときだけにしてください。
- 水が入った、落とした、他の店で修理した、部品を替えた、のいずれかが
  書かれていれば、flags に入れてください。
- 聞き返す質問は、お客様が時計を手に取って答えられる形にしてください。
  （例：「裏蓋に刻まれている英数字を教えていただけますか」）
- 判定の根拠にした依頼の言葉を evidence に写してください。

【依頼の内容】{request}
【型式の表の情報】{model_row}

「迷ったときは inspect_first」が、この指示でいちばん効く一文です。 shop を広く取ると、受けられないものに概算つきの返信が出ます。「現物を見てから」に寄せて困るのは技能を持つ店員の確認の件数が増えることだけで、お客様との食い違いは生みません。

「金額を書かない」を明記するのは、症状を読むと AI が相場を書きたがるからです。 書かせてしまうと、料金表の幅と食い違う数字が返信の下書きに混ざります。

出力形式を固定する

次の形の JSON で受け取ります。

{
  "request_id": "W-2026-1103",
  "symptom_types": ["stopped"],
  "intake": "shop | maker | inspect_first | difficult",
  "reason": "",
  "missing_info": ["case_back_number"],
  "questions": ["裏蓋に刻まれている英数字を教えていただけますか"],
  "flags": ["water_entry"],
  "evidence": ["「洗面所で水がかかってから止まった」"]
}

1つ目の理由は、intake でルーターを分けられることです。 Make のルーターは各ルートを順に評価し、どれにも当たらないものはフォールバックのルートで処理されるとされています。shop・maker・inspect_first の3つのルートを置き、difficult と想定外の値はフォールバックで技能を持つ店員の確認の一覧に落とします。

2つ目は、missing_info があれば返信を聞き返しに切り替えられることです。 型式が足りなければ、概算を書かずに questions だけの返信の下書きを作ります。聞き返しを1通にまとめられるので、往復が1回で済みます。

3つ目は、evidence で技能を持つ店員の確認が速くなることです。 票を開く前に、何を根拠に区分を選んだかが一覧で読めます。

返信の下書きは、区分ごとのひな形に値を差し込んで作ります。

どの下書きにも、「正式な見積はお預かりして確かめてからお出しします」の一文を固定で入れます。

システムへ連携する

返信は下書きまでにします。 送るのは受付の店員です。型式の表と料金表には書き込みません。 表を直すのは技能を持つ店員の仕事にします。

人が確認する

1. shop と maker の下書きを確かめて送る … 受付の店員が、型式と概算の幅が依頼と合っているかを見て送ります
2. inspect_first と difficult の票を見る … 技能を持つ店員が、根拠を読み、返信の方針（来店を勧める、メーカーへ取り次ぐ、お断りする）を決めます
3. 判定を覆したら記録する … どの区分から、どの区分に変えたかと理由を受付台帳に残します
4. 型式の表に無かった型式を足す … 確認のついでに表に1行足します

2番目で「お断りする」と決めた返信は、技能を持つ店員が自分で書きます。 下書きのひな形を作らないのは、お断りの理由が時計ごとに違い、決まった文面では伝わらないからです。

1番目で見るのは、概算の幅が依頼の時計に合っているかです。 料金表の行は駆動の方式と症状の型で引くので、型式の表の方式が誤っていると、別の方式の料金が出ます。受付の店員は、下書きの概算の横に出ている方式の名前と、依頼のブランドと型式が合うかだけを見ます。

3番目の記録は、型式の表と区分の決まりを直す材料になります。 同じ型式で shop から maker に変えることが続いたら、表の取り次ぎ先を直します。

目標は、240件をならして1件3分です。 shop と maker は確かめて送るだけで1〜2分、技能を持つ店員の確認の票は数分かかります。

例外に対処する

上の3行が大半を占めます。 どれも AI の問題ではなく、型式の表と料金表の行が足りないことの問題です。 毎月、表に無かった型式を足していくと、inspect_first の割合が下がっていきます。

水が入った時計は、急ぐ必要があります。 中で錆びが進む前に開けたほうがよいので、この区分の票は確認の一覧の上に出し、その日のうちに返信します。

記録を残す

• 受付の番号、受け取った日時、依頼の内容（連絡先は受付台帳にだけ）
• 型式の表で引いた行と、料金表で引いた行
• AI が返した JSON の全文
• 送った返信の区分と、送った店員
• 技能を持つ店員が区分を覆した記録と理由
• 時計を預かった後の正式な見積と、受付の区分との違い

最後の行が、この構成を育てる材料です。 shop で概算を返したのに正式な見積が大きく違ったものを月に一度見て、料金表の幅か症状の型の分け方を直します。

型式の表と料金表を直したときは、直した日と中身を表の別のシートに残します。 ある依頼にどの版の表で概算を返したかが分からないと、お客様から「最初の返信と違う」と言われたときに確かめられません。AI の JSON と一緒に、引いた行の値そのものを票に写しておくのが確実です。