AI CRMが製造業の商談で効くのは、フォローを増やすからではなく、引き合いを正しく読むからです

この一文には、性質の違う二つの商売が隠れています。設備は9か月から18か月のサイクルで、複数部門の合議と稟議で決まります。図面支給の機械加工は、図面を前に数日で決まり、問題はサイクルの長さではなく引き合いの件数です。以下で述べる引き合いの読み取り、見極め、文書についての話は両方に当てはまりますが、購買の合議体とスコアリングの話は設備の商談にだけ当てはまります。どちらの場合も、AIが得意とする範囲は狭いままです。すでに自社が持っているテキストを組み替えること、それだけです。

汎用のCRM自動化が、長いB2B商談で機能しない理由

定番の型は、買い手が一人であること、検討が短いこと、市場が大きいこと、そしてスコアリングに意味が出るだけの案件数があることを前提にしています。そのどれも成り立ちません。設備の購入を評価するのは、サイクルタイムを気にする生産技術者、工程能力を見る品質保証の担当、予備品を気にする保全の責任者、取引条件を見る購買担当、そして設備投資予算を持つ管理職です。それぞれ登場する時期が違うため、「リード」宛てに組んだステップメールは、結局誰にも届きません。

市場そのものも有限です。対象となる企業の数は、技術者が工場を移っていくなかで同じ名前が何年にもわたって別の会社で再び現れる程度には小さく、行動モデルに学習データと呼べるだけの量が集まらない程度には小さいのです。ここでは、不快な自動送信メールは誤差では済みません。名前とともに覚えられます。

案件が失注するのは、「ご提案書はご覧いただけましたでしょうか」というメールをもう一通送らなかったからではありません。翌年度の設備投資計画が組まれる場に、役に立つものを何も持って居合わせなかったから、技術的な回答が遅れたから、あるいは要求内容が誰も動けない形でしか書き留められなかったからです。どれも送信頻度の問題ではありません。

引き合いを読み、要求内容を引き出す

見積依頼は、顧客がそのとき送りたいと思った形で届きます。PDF、表計算ファイル、図面一式、メール本文の三段落、六つの欄しか意味を持たない購買部門の定型フォーマット。テキストとして書かれているものであれば、モデルは確実に抜き出します。数量と分納の条件、日付と納入条件、要求されている認証の一覧、商務条件、本文に書かれた品番。しかもファイルを開く程度の時間で済みます。

図面の上にしかない情報は、別の種類の項目です。幾何公差、溶接記号、データムの取り方、表面粗さ、重要特性の指示。これらの読み取りは信頼できません。図面から拾った値は、技術者が確認するための未検証の候補として提示されるべきであって、そのまま見積の根拠にできる値として出してはなりません。この二種類を同じ扱いにすることが、役に立つ抽出を見積ミスに変える最短経路です。

先に権利の問題を片付けてください。顧客の図面一式は顧客の知的財産であり、たいていは引き合いが来るずっと前に結んだ秘密保持契約(NDA)の下にあります。航空宇宙、防衛、自動車の一部では、ITARやEAR、EUのデュアルユース規則による輸出管理の対象になることもあります。図面がモデルに渡る前に、NDAが処理と再委託について何を認めているかを確認してください。規制対象の仕事はオンプレミス、あるいはデータを保持せず学習にも使わない構成で動かしてください。そして、指定した顧客や品目群が最初からこの流れに入らないよう、除外の経路を用意しておいてください。

出力のうち価値が高いのは、むしろ足りていないものの側です。最初の一時間で返す質問は、自社の技術力を示す最も強い材料であり、誰も確かめていない前提のまま技術者が見積を作ってしまうことを防ぎます。

役に立つ抽出と、技術者が結局手でやり直す抽出を分ける規則が二つあります。一つは、すべての項目が出典を示すこと。表計算ファイルならシート名とセル番地、スキャン画像ならページとその上の領域です。もう一つは、モデルが推測せずに空欄のまま返すこと。これは指示すれば身につく振る舞いではなく、自社のテストセットに対して項目ごとに測る率です。空欄を返す動作は、もっともらしい既定値が存在するところで破綻します。公差や標準的な表面仕上げがそれです。空欄率が低く誤りが多い項目は、人に任せる項目だということです。

会社を拘束せずに、最初の技術回答を起案する

最初の返信で、検討の土俵に乗るかどうかが決まります。良い返信は、問い合わせへの礼を述べる代わりに用途を名指しし、理解した要求内容を言い換えて確認し、答えが変わる二つか三つの質問を投げ、次のステップを日付付きで約束します。

その骨格はモデルが一分で用意し、人が直して送ります。自動で送信することは、同じ仕組みの設定違いではなく、別の仕組みです。そして起案文は仕様を明言しません。見積に届きうる数字はすべて、それを約束する権限のある人から出ます。

取引先の履歴を要約し、CRMの記録を最新に保つ

14か月続いた案件は、百通のメール、三回の訪問、二度の試作、そして失敗したトライアルに散らばっています。履歴は存在していますが誰も読まないので、担当営業が辞めた時点で実質的な価値はゼロになります。そのやり取りを読んで次の担当者に説明するモデルは、本当に役に立ちます。

同時に、要約は情報を落とします。そして落ちやすいのは、途中に埋もれた一行の約束です。譲った公差、期間を切って据え置いた価格、電話で合意した適用除外。ほぼ正しいのに譲歩の一行だけを黙って落とした要約は、要約が無いより悪いものです。したがって要約はやり取りへの入口として扱い、記述のすべてを出典のメールに紐づけ、約束した事項は出典付きの別リストとして抜き出してください。

同じ機能が、CRMで最も古い問題に効きます。営業が記録を更新しないのは、更新が何も返してこないデータ入力だからです。答えは現場に対するものと同じで、要求するのではなく提案することです。商談の後、アシスタントが記録を起案し、フェーズの変更と次のアクションを提案します。あくまで提案のままにしてください。値や受注予定日を黙って書き換えるアシスタントは、CRMが備えるべき唯一のもの、つまり人が信じられる記録を壊してしまうからです。

AI CRMは既存のシステムを置き換えるのか、その上に乗るのか

たいていは上に乗ります。取引先、案件、受注の記録は今ある場所に留まります。Salesforce、Dynamics、HubSpot、Odoo、あるいはERPのCRMモジュールのいずれであっても同じです。アシスタントはその記録と、メールボックス、過去見積、文書管理システムから読み取り、書き戻すのは三つだけです。記録のメモ、項目変更の提案、そして担当者と期日の付いたタスク。いずれも誰が出したか辿れて、取り消せる形でなければなりません。

つまりプロジェクトの本体はモデルではなく連携です。そしてたいてい壊れるのは、CRMとERPと文書管理システムのあいだを渡らなければならない識別子です。CRMの取引先コードとERPの得意先番号が、そもそも突き合わされたことがないからです。CRMが無いのなら、まずCRMが先です。存在しない記録を、アシスタントが最新に保つことはできません。

AIが不得意なこと、そしてそれが損失になるところ

モデルは自社の実力を知りません。その公差は出せるが第二工程でしか出せないこと、その合金は自社の条件ではかじりを起こすこと、記載された年間数量はその分野が発注してきた実績の数倍であること。商売上の結果に対する感覚もないので、リードタイムについて断定的な一文も、含みを持たせた一文も、同じ気軽さで書きます。どちらも文章としては正しく成立するからです。そして、文書を渡した後に何が変わったかも知りません。だから文書を最新に保つことは、初期設定の作業ではなく運用上の責任になります。

技術者を相手にした案件の見極め：スコアリングは見極めではない

スコアリングは行動から点数を付けます。閲覧したページ、開封したメール、ダウンロードした資料。実際の買い手がこれほど少ない市場では、それが測っているのはたいてい好奇心です。そして最も確実に高得点が付くのは、自社の資料を読んでいる競合他社の技術者です。

見極めが答えるのは別の問いです。自社の設備が合う用途があるか、そしてそれは確認できるだけ具体的に書かれているか。予算はあるか、どの期のものか。誰が決めるのか、そして誰が止められるのか。そして、何もしなかった場合に何が起きるのか。

アシスタントが役に立つのは、技術者が答えたいと思う質問をする場合だけです。技術者は品番、材質、数量、サイクルタイムなら進んで教えてくれますが、従業員規模の区分や予算レンジを求めるフォームは途中で閉じます。最も過小評価されている出力は、早く断ることです。合わない引き合いのコストの大半は、そもそも合っていなかったと誰かが確かめるまでに費やされる技術検討の工数だからです。

でっち上げではなく、自社の資料から答えるAIチャットボット

言語モデルに製品の質問をすると、学習した内容から答えます。その文章は自社の資料とまったく同じ調子で読め、断定の強さと内容が正しいかどうかのあいだには何の関係もありません。技術的な商談では、これが最悪の壊れ方です。誤った回答はスクリーンショットを撮られ、転送され、会議で引用して突き返されるからです。

これを耐えられるものにするのが、自社文書に根拠を置くことです。質問が自社の文書から該当箇所を検索し、モデルはそこからだけ答えて出典を示します。これにより、よくある壊れ方が「資料の中に見つけられませんでした」に変わります。作業の大半は文書の側にあります。どの文書が正なのか、どれが旧版でインデックスから外さなければならないのか、そしてどれが社外秘なのか。旧版は品質手順が要求するとおり文書管理システムには残しつつ、アシスタントからは届かない状態にします。

それでも壊れ方が消えるわけではありません。文章としての一致度が高いという理由で、検索が旧リビジョンを返すことがあります。正しい文書を返したのに、モデルがその中の表を読み違えることがあります。関連するものが見つからず、それでも学習内容から答えてしまうことがあります。出典表示は、そのいずれも悪化させます。文書名の付いた誤答のほうが、強く信じられるからです。

したがって制約は、運用ルールの文書ではなく仕組みの側で強制してください。公開済みの資料からのみ答える。使った文書名とリビジョンを明示する。仕様に関する質問は推論せずに断る。価格とリードタイムは決して出さない。そして答えられなかった質問はすべて記録してください。その記録は、自社が公開してこなかったものの一覧を、顧客が書いてくれたものだからです。

すでに持っているデータと、それを使える状態にするための作業

思っているより多く、思っているより状態は悪いものです。メールボックスには何年分もの引き合いと技術的なやり取りがあり、見積履歴には何をいくらで提示したかがあります。そして失注理由には、誰かが正直に書いていたのであれば、社内で最も価値のあるデータが入っています。ERPにはリードタイムと納入日があります。信用する前に確かめる価値があります。計画と実績を突き合わせること、そして回答納期が遅れるたびに上書きされていなかったかどうかです。

次に、その状態です。同じ顧客が表記違いで三件登録されていて、ドイツの子会社は親会社への紐づけのない別の取引先になっているため、そのグループがすでにラインを二本買っていることが誰にも見えません。そして失注理由は、ほとんどの記録で「価格」です。本当の理由が回答の遅さだったとき、人が選ぶのがその選択肢だからです。

この作業は地味で、そしてプロジェクトの大半を占めます。取引先を名寄せする。企業グループの親子関係をデータで表現する。資料の正となる置き場所を一つに決め、リビジョンの欄を明示的に持たせる。自由記述の失注理由を、営業が正直に選べる短い選択肢に置き換える。このデータの上に作られたモデルは、すべての誤りをそのまま受け継ぎ、それを自信ありげに差し出します。

人への引き継ぎと、悪い引き継ぎが価値を消してしまう理由

アシスタントが止まり、人が引き取る瞬間に、顧客はシステム全体を評価します。顧客が用途を詳しく説明し、二日後に営業が電話をかけてきて同じ質問を最初からやり直す。自動化で稼いだものは、その一分で使い果たされます。

機能する引き継ぎは、案件に紐づいた会話そのもの、エスカレーションの原因になった質問、共用のメールアドレスではなく名前のある担当者、そして誰かが責任を負う回答時間を伴います。アシスタントが何であるかは正直に伝えてください。技術者は数往復で見抜きます。そして仕様の確約、価格、クレーム、および顧客が同じことを二度聞いたときは、自動的にエスカレーションしてください。

正直に測る：送信数ではなく、回答時間と有望案件の量

この種のシステムの報告は、たいてい自分自身の活動量を測っています。送信したメッセージ数、対応した会話数、ベンダーが用意した係数で計算した削減時間。これらはどれも、何かが良くなったかどうかとは無関係に増えます。代わりに、引き合いの着信から最初の実質的な技術回答までの時間から始めてください。実質的とは、受領の連絡ではなく用途に踏み込んだ回答を指します。次に、対応対象として受け付けた引き合いについて、引き合いから見積提出までの時間と、そのうち実際に見積に到達した割合です。ここに、技術者の待ち行列の中で死んでいく案件が現れます。

断った引き合いは別の軸で測ってください。断るまでに何日かかったかです。早く断ることが下げようとしているのは、まさにその数字だからです。両方を一つの分母にまとめた見積提出率は、断れと言ったばかりの引き合いに見積を出せ、という指示になります。続いて、有望案件の量を、プロジェクト開始前に書いておいた「有望」の定義に照らして測ります。そしてアシスタントが答えられなかった質問の件数です。足りていなかったものを公開していけば、この件数は下がるはずです。

GDPRと、欧州の製造業の買い手が求める水準

B2Bの営業連絡に必要な法的根拠は、欧州の中でも一様ではありません。ePrivacy規則の国内法化は国ごとに異なり、加盟国によっては、法人の担当者宛ての同意なき営業メールが、よく言われる「正当な利益」という要約が示唆するよりはるかに厳しく扱われます。市場ごとに法務と決めてください。そして、書き直しなしで国ごとにルールを変えられるようにシステムを作ってください。

残りは、調達に影響するエンジニアリング上の判断です。買い手の質問票は、引き合いの文面がどこで処理されるのか、EUの外に出るのか、誰かのモデルの学習に使われるのか、どれだけの期間保持されるのかを聞いてきます。最初の選別を通過するには、短い回答が四つあれば足ります。処理はEU域内、顧客のコンテンツは学習に使わない、保持期間は定めてある、アクセスは記録している。その奥には、締結済みのデータ処理契約(DPA)、再委託先の一覧、技術的・組織的な安全管理措置、そしてたいていはISO 27001かSOC 2の認証が控えています。引き合いが来る前に揃えておいてください。

引き合いを断る判断には、必ず人を経路に入れてください。それは設計として正しく、同時に自動化された意思決定をめぐる議論に決着を付けます。法律を離れても、欧州の製造業の買い手は、専門家として扱われることを期待しています。そして「先日のお打ち合わせの件で」というありもしない書き出しは、参加者の少ない技術市場では、何も送らないことより大きな損害を与えます。

どこから始めるか：営業における最初のAIプロジェクト

ワークフローは一つ、期間は8週間から12週間、営業と技術にそれぞれ名前のある責任者を一人ずつ、そして何かを作り始める前に成功の定義を文書にしておくこと。着信する引き合いの処理から始めてください。価値がそこに集中しており、しかも壊れ方が最初に見えるのが社外ではなく自社の人間だからです。

最初の2週間は、直近2年の実際の引き合いを50件、何をいくらで見積もり、その後どうなったかとセットで集めることに使ってください。その50件がテストです。これが無ければ、作った側が選んだデモを見て評価することになります。次に、抽出と不足情報リストを作り、要求内容が結局何だったのかと突き合わせて技術者にレビューさせます。顧客と直接話すアシスタントは最後です。人の監督なしに顧客と話すのは、それだけだからです。

受入基準は着手前に書いてください。対象を決めた顧客セグメントでの初回返信までの時間、引き合い1件あたりの技術工数、そして先の正解セットに対して採点した抽出精度。項目ごとの適合率と、とりわけ見積リスクを負う項目についての再現率です。承認率は受入基準ではなく定着の指標として扱ってください。それが評価対象だと技術者が知った時点で、どちらとも言える細かな修正はされなくなりますし、本当に問題になる誤りは、整った一覧を流し読みするレビュアーには見つけられない欠落だからです。何をやらないかも事前に決めてください。大量のアウトバウンド送信、人が確認せずに送信するもの、法的根拠やNDAの扱いが未決着のまま動かすこと。

Meta Smart Factoryはどこに入るか

MSFのMETA CRM Botは、このプラットフォームの営業側にあたる製品です。当サイトの他のモジュール、すなわちMES、APS、MRP、品質、保全、倉庫は工場を動かします。私たちはその両側を作っています。だからこそ、ここまでの議論は機能ではなく、順序とデータ品質の話になっています。

ぼかさずに名指ししておくことが一つあります。その製品は当サイトでは多言語で24時間動くメッセージングとして紹介されていますが、技術的な商談では、そこを最初に立ち上げるべきではありません。ここまでで主張してきた抑制は、宣伝文句ではなく設定です。モデルが起案し人が送ること、仕様・価格・納期の確約が出たらエスカレーションすること、同じ名前が繰り返し現れる市場に大量のアウトバウンドを流さないこと。トライアルの際にこれらを要求してください。

考える価値があるのは継ぎ目のほうです。製造業の引き合いを支配する問いは二つあります。この特性をこの生産速度で維持できるのか、そして第34週に届くのか。どちらもアシスタントが答えるべき問いではありません。一つ目は、特定の特性、特定の機械、特定の治具についての工程能力の話であり、公差帯の半分を食い潰さないゲージR&Rが前提になります。しかも新規部品には、答えの根拠になる履歴がありません。二つ目は、日々変わる受注残に対する将来の能力の問いです。過去の納期遵守率は能力ではありませんし、今日の能力は第34週の能力ではありません。

アシスタントにできるのは、根拠を集めて、答える人の前に置くことです。最も近い類似部品の実測サイクルタイムとスクラップ率は、その引き合いが工程能力調査に見合うかどうかを技術者に判断させます。APSの受注残は、第34週が成り立つかどうかを計画担当者に判断させます。日付は依然として計画担当者から出ます。生産実績が信用できないものであれば、その上に載せたAIの営業レイヤーは、それでもその数字から見積を出します。

したがって、最初の打ち合わせとして有益なのはデモではありません。自社の直近の引き合いと、その一件ごとに何が起きたかを振り返ることです。それなら半日で、商談のどこで時間を失っているかが分かります。そして時にその答えは、失っている場所はソフトウェアで直せる部分ではない、というものです。