受注管理と振り返り

見積の結果を一か所に集め、次の見積の根拠にする

木村さんは営業部の課長として、6人のメンバーが出す見積を見ている。チーム全体で月に150件ほどの見積を出しているが、完成した見積書はメンバーそれぞれのフォルダに保存され、受注・失注の結果は口頭やチャットで伝わってくるだけだ。月末になると、木村さんはメンバー一人ひとりに状況を聞いて表にまとめ、受注率を出して部長に報告する。この集計に半日かかる。

数字は出せても、なぜ失注したのかまではわからない。価格で負けたのか、納期が合わなかったのか、そもそもお客様の計画が止まったのか。メンバーに聞けば答えは返ってくるが、記録には残らない。半年後に同じお客様から似た部品の見積依頼が来ても、前回なぜ取れなかったのかを誰も覚えていないことがあった。せっかく積み上げた見積の結果が、次の見積に生かされていなかった。

そこで想定するのが、完成した見積と結果を一か所に集めるアプリだ。メンバーは見積書を提出したら、その完成版をアプリに登録する。お客様名、品目、金額、提出日はAIが見積書から読み取って入るため、手で打ち込むのはわずかだ。結果が出たら受注か失注かを選び、失注なら「価格」「納期」「仕様」などの理由を選んでひと言添える。提出から一定の期間がたっても結果が入っていない案件は、担当者に知らせが届く。

木村さんの画面には、案件ごとの状況とチームの受注率が一覧で表示され、月末の集計は不要になる。失注の理由も集計され、「この3か月は価格での失注が増えている」といった傾向が見える。AIは記録の整理と傾向の集計までを担い、その傾向をどう受け止め、価格や営業の進め方をどう変えるかは木村さんとメンバーが話し合って決める。たまった結果は、似た部品の検索や参考価格の根拠として、次の見積でそのまま参照できる。

導入から3か月たった月の会議で、木村さんは失注の理由の集計を見せながら、価格での失注が○○業界の案件に集中していることを共有した。メンバーと過去の事例を見比べると、競合の多い量産品で一律の掛け率を使っていたことがわかり、その種類の部品では参考価格を確かめてから出すことにした。月末の集計に使っていた半日は、メンバーとの案件の相談に充てられるようになった。新しく入ったメンバーも、似た案件の過去の結果と理由を見てから見積に臨める。

想定するアプリでは、主に次のようなことができる。

• 完成版の登録。見積書を登録すると、お客様名・品目・金額・提出日を読み取って一覧に加える
• 結果と理由の入力。受注・失注と理由を選択肢とメモで残し、入力漏れの案件を知らせる
• 状況の一覧。案件ごとの状況、担当者別の件数、チームの受注率を一つの画面で確かめる
• 次の見積での参照。似た案件の過去の結果と理由を、類似部品の検索や参考価格の根拠として使う

bloomがこのアプリをつくるなら、まず営業のメンバーと課長に、見積を出してから結果がわかるまでに何が起き、何が記録されずに消えているかを聞き取る。失注の理由の選択肢は、過去の案件を振り返りながら現場の言葉でつくる。記録の整理はアプリとAI、傾向の読み取りと打ち手は人という線引きにするのは、失注の背景にはお客様との会話や業界の事情があり、それを解釈できるのは担当者と課長だからだ。

入力の手間が増えると記録は続かないため、初版では登録と結果の入力をできるだけ短くすることを優先する。木村さんのチームで1〜2か月使ってもらい、入力が漏れる場面や、一覧で見たい項目を聞き取りながら直していく。