問い合わせの社内連携：営業・技術・製造の情報伝達と対応SLA
1. なぜ社内連携が外部対応より重要なのか
多くのチームは外部対応の速さに力を注いでいます。5分以内の初回返信、24時間以内の見積もり、いずれも正しいことです。しかし問い合わせの成約を本当に止めているのは、外部対応の遅さではなく社内連携の遅さであることがほとんどです。営業が問い合わせを受けると、技術に仕様の実現可否を確認し、製造に納期を確認する必要があります。技術と製造にはそれぞれのスケジュールがあり、営業はその間ただ待つしかありません。
お客様はあなたの社内で何がもめているか知りません。問い合わせを送ったあと、営業が「社内で確認します」と言い、3日間音沙汰がない、それだけです。社内のプロセスが複雑だとは思わず、自分が軽んじられていると感じるだけです。社内連携の効率が、外部対応力の上限をそのまま決めます。
| 工程 | 担当役割 | 社内SLA | 成果物 | よくある詰まりどころ |
|---|---|---|---|---|
| 初回受領確認 | 営業 | 5分以内 | 受領確認と次のステップの約束 | 自動返信のあと誰もフォローしない |
| 要件整理 | 営業 | 2時間以内 | 社内の要件チケット | 要件が不明瞭で技術から質問が返る |
| 技術評価 | 技術 | 4時間以内 | 仕様表と実現可否の結論 | 技術が多忙でチケットが滞留 |
| 納期確認 | 製造 | 8時間以内 | 納期表と生産能力の確認 | スケジュールが逼迫し納期が正確に出ない |
| 見積送付 | 営業 | 2営業日以内 | 正式な見積書 | 情報が不足し修正を繰り返す |
上の表は、1件の問い合わせが届いてから見積もりを送るまでの社内フロー全体です。5つの工程を合わせたSLAの目標は2営業日です。これを超えると、お客様はほぼ確実に他のサプライヤーを探し始めています。外部への初回対応の全体像は、こちらをご参照ください。問い合わせ初回返信のSLAとコンバージョン率。
2. 営業から技術へ：技術に質問を返されない要件票の書き方
営業と技術の最大の摩擦は、営業が出す要件票がろくに書けていないことです。営業は「客先がXX製品を希望、できるか見てほしい」と一行書くだけで、技術は仕様も数量も用途も分からず、営業に聞き返すしかありません。そのやり取りだけで一日が終わり、時間はすべてコミュニケーションに消えます。
正しいやり方は、要件票を構造化することです。完全な社内要件票には、六つの必須項目を必ず入れます。顧客名、製品型番、目標数量、目標価格帯、納期要件、特殊要件。六つすべて埋まっていれば、技術は受け取った時点でそのまま評価でき、聞き返す必要はありません。一つでも欠ければ、チケットはそのまま営業に差し戻して書き直させます。
| 必須フィールド | 入力要件 | 欠けるとどうなるか |
|---|---|---|
| 顧客名 | 会社の正式名称+国 | 技術が顧客の背景を把握できない |
| 製品型番 | 「XXに類似」ではなく具体的な型番 | 技術が自分で型番を推測するしかない |
| 目標数量 | 具体的な数量または規模 | 生産能力と単価を評価できない |
| 目標価格 | 顧客が提示した目標価格または価格帯 | 高く出すか安く出すか判断できない |
| 納期の要望 | 顧客が求める納期 | スケジュールの実現可否を評価できない |
| 特殊要件 | 認証、梱包、カスタマイズなど | 記載漏れが後工程の手戻りを招く |
事例：営業の王さんにドイツの顧客から引き合いが来て、要件票には「客先がそちらのXX型番を希望、数量5000個、目標価格12ドル、納期8週間、CE認証が必要」と書かれていました。六項目すべて記入済みで、技術は4時間以内に仕様表と実現可否の結論を出し、生産は8時間以内に納期を回答。王さんは翌日には完全な見積もりを顧客に送れました。もし王さんが「ドイツの客先がXX型番を希望、見てほしい」とだけ書いていたら、技術は少なくとも三度は聞き返していたはずです。
三、技術から生産へ：実現可否の結論をどう書けば営業が安心して提示できるか
技術から営業へのフィードバックは、専門用語の羅列になりがちで、営業には理解できず、ましてや顧客に伝え直す方法も分かりません。たとえば技術が「本型番は条件Aで性能が約15%低下するため、顧客の使用条件を確認する必要あり」と書いたとします。営業はさっぱり分からず、そのまま顧客に送るしかありません。顧客も理解できず、「普通の言葉で説明してくれ」と返信してきます。
技術から営業へのアウトプットは、営業がそのまま使える版でなければなりません。要点は三つ、できるか、条件は何か、リスクは何か。技術的な細部ではなく結論を書きます。技術のアウトプットの型は「可能です。標準納期はX週間、単価は約Xドル。顧客にYパラメータの確認が必要です。リスクはZなので、事前に顧客へ伝えることを推奨します」。営業はこれを受け取れば、言い回しを少し直すだけで顧客に送れます。
| 技術アウトプットの種類 | 技術用語版（営業には渡さない） | 営業が使える版（そのまま顧客へ） |
|---|---|---|
| 実現可否の結論 | 「本型番は-20℃で性能が15%低下」 | 「-20℃の環境で使用可能、性能は正常」 |
| 納期判断 | 「現在のスケジュールは第6週、資材は輸送中」 | 「標準納期は6〜8週間、8週間以内で確約可能」 |
| リスク提示 | “この公差±0.05mmは二次加工が必要” | “±0.05mmの公差は対応可能、追加で3日必要” |
| カスタム要件 | “PCB layoutの修正が必要、再試作に2週間” | “カスタム版は対応可能、試作期間は約2週間” |
技術と営業の間の翻訳層は、社内連携が最も途切れやすいところです。技術は営業が技術を分かっていないと思い、営業は技術が分かりやすく話さないと思っています。解決方法は簡単です。技術のアウトプットは必ず”営業が使える版”のテンプレートで書き、技術的な詳細は書かず、結論と条件だけを書くこと。営業ツールキットの構築は、次を参考にしてください営業資料ライブラリの構築。
四、社内SLAの計測とエスカレーションの仕組み
計測とエスカレーションのないSLAは、ないのと同じです。各工程には必ず明確なSLA計測があり、超過すると自動的に上位の主管へエスカレーションされます。たとえば営業が依頼を出し、技術が4時間返信しなければ、システムが自動で技術主管に通知します。技術が生産に渡さず、生産が8時間返信しなければ、自動で生産主管に通知します。エスカレーションは人を責めるためではなく、止まっているチケットを誰かの目に触れさせるためです。
核心ルール：社内SLA達成率は週1回集計し、80%を下回ったら原因を探すこと。人手が足りないのか。プロセスが複雑すぎるのか。依頼書の書き方が不明確なのか。2週連続で80%を下回ったら、人員を増やすかプロセスを変えること。みんなの残業で無理に耐えてはいけません。残業で得た高いSLA達成率は持続できません。
| SLA工程 | 標準所要時間 | タイムアウト時のエスカレーション | 週次達成率目標 |
|---|---|---|---|
| 営業の初回応答 | 5分 | 10分未返信→当番主管 | 90%以上 |
| 営業が依頼書を提出 | 2時間 | 4時間未提出→営業主管 | 85%以上 |
| 技術がパラメータを提示 | 4時間 | 8時間未提示→技術主管 | 80%以上 |
| 生産が納期を報告 | 8時間 | 16時間未報告→生産主管 | 80%以上 |
| 完全な見積書を送付 | 2営業日 | 3営業日未送付→営業部長 | 75%以上 |
シナリオ例：月曜午前10時に営業が問い合わせを受け、12時前に依頼書を提出。技術は午後4時前にパラメータ表を提示し、午後6時前に生産が納期を回答。火曜午前に営業が見積書をまとめ、昼に顧客へ送付。この一連の流れは26時間未満で、2営業日のSLA内です。もし技術が火曜午後になってようやくパラメータを出したら、それは超過であり、システムが自動で技術主管に通知します。チケットシステムの技術的な実装は、次を参考にしてくださいウェブサイトのリードをCRMに連携する方法。
五、よくある社内連携の誤り
| 誤解 | 見かけの施策 | 実際の結果 | 正しい方法 |
|---|---|---|---|
| 口頭で依頼 | 営業が技術の席まで行って一言伝える | 記録がなく、忘れやすい | 必ずチケットを起票し、記録を残す |
| 依頼書の項目不足 | “顧客がXXを希望”とだけ書く | 技術が何度も聞き返す | 6項目必須、欠けたら差し戻し |
| 技術のアウトプットが専門的すぎる | 営業に専門用語を並べる | 営業が顧客に伝えられない | 技術のアウトプットは三行の結論版 |
| SLAを計測しない | みんなの自主性に任せる | 忙しくなると誰も見なくなる | チケットシステムが自動で計測とエスカレーション |
| 問題が起きると責任のなすり合い | 営業は技術が遅いと言い、技術は生産が遅いと言う | 顧客が放置される | 毎週SLA達成率を振り返り、根本原因を探す |
この五つの誤解の中で最も多いのが一つ目、口頭での依頼です。少人数のチームは全員が同じ場所にいるので、口頭で伝えれば済むと考えます。しかし口頭の依頼は記録に残らず、数日もすれば技術は忘れ、営業は技術が対応中だと思い込み、技術は営業から依頼されていないと勘違いします。チケットシステムの意義は、口頭のやり取りを書面の記録に変えることです。誰がいつ依頼し、いつ必要かが一目で分かります。問い合わせ分配の全体設計は、次を参考にしてください。問い合わせの割り当てと負荷分散。
FAQ よくある質問
問い合わせを受けてから見積もりを送るまで、どのくらいかかりますか。
営業が技術に依頼するとき、聞き返されない書き方はありますか。
技術から営業への回答が専門的すぎる場合はどうしますか。
社内SLAの計測とエスカレーションはどう行いますか。
少人数のチームにチケットシステムは不要では。
お客様に「なぜこんなに遅いのか」と聞かれたら、どう答えますか？
最後に
問い合わせの社内連携は、管理の問題に見えて実は顧客体験の問題です。お客様は社内の手続きが複雑だからといって3日も待ってはくれません。すぐに他社へ移ります。営業・技術・生産の連携がスムーズなほど、お客様が感じる対応は速くなります。同じ人員、同じ生産能力でも変わるのです。
実行は3ステップです。第一に、社内連携を5つの工程に分け、各工程にSLAの時間を定めます。第二に、依頼票は6項目を必須入力とし、欠けていれば差し戻します。技術の回答は3行の結論形式にします。第三に、チケットシステムで自動計測し、超過は自動でエスカレーション、毎週SLA達成率を振り返ります。この3ステップを終えると、見積もりが速くなり、営業は勘で動かずに済み、技術は何度も聞き返さずに済み、生産は急な割り込みに追われなくなります。
覚えておきたい一言。お客様が待っているのは営業ではなく、その背後にいる技術と生産です。社内のSLAを厳しくすれば、対外的な見積もりが速くなります。残業が増えたからではなく、責任の押し付け合いがなくなったからです。