AccelShift

リフォーム施工企業 様

見積作成の属人化を解消するAIを開発

ベテランの頭の中にしかなかった概算見積の勘所を、誰でも同じ手順で出せる形にした。

見積作成の変化を示す図。左はベテラン担当者ひとりが図面を見て見積を作り、他の担当者が順番を待っている状態。右は複数の担当者がそれぞれ画面で条件を入力し、金額のレンジと根拠案件を確認している状態。
企業情報
リフォーム施工企業 様/建設・設備工事
ご支援内容
AI実装・開発
使用技術
Next.js / Supabase / LLM API

チャプター 1

見積のスピードが、そのまま受注率になっていた

リフォームは、お客様が複数社に相談しているのが普通です。同じ内容で相見積もりを取り、先に金額の見えた会社から検討が進む。つまり見積を出すまでの時間が、そのまま受注率に効いてきます。

ところがこの会社では、概算見積を出せる人が限られていました。現場を長く見てきた担当者だけが、図面と現地の状況から「これならいくらぐらい」を判断できる。その人の手が空くまで、他の誰も動けない状態でした。

問題は待ち時間だけではありません。同じ条件の案件でも、担当する人によって出てくる金額が変わる。社内では誰も困っていなくても、お客様から見れば「この会社の見積は根拠がよく分からない」という印象になります。属人化は、速度と信頼の両方を削っていました。

チャプター 2

属人化しているのは「勘」ではなく、判断の順番だった

最初にやったのは、AIの設計ではなく過去の見積データの棚卸しです。金額を左右している条件は何か、ベテランがどの順番で何を見て判断しているかを、実際の案件をなぞりながら洗い出しました。

この工程を飛ばすと、たいてい失敗します。データを渡してAIに学習させれば何か出てくる、という進め方では、出てきた数字を誰も信用できないからです。なぜその金額になったのかを説明できないものは、現場では使われません。

見えてきたのは、属人化していたのは感覚ではなく判断の順番だということでした。どの条件を先に確認し、どこで場合分けするか。それが本人の中だけにあり、言語化されていなかった。ここが分かれば、あとは形にできます。

チャプター 3

既存の見積フローの中に置く

条件を入力すると、概算レンジと、その根拠になった過去の類似案件が並んで出てくる。担当者は金額だけでなく「なぜその金額なのか」を確認したうえで、必要なら調整して出せます。

作るうえで意識したのは、新しい業務を増やさないことです。別のツールを立ち上げて転記する形にすると、忙しい時期から使われなくなる。既存の見積フローの中に置き、普段どおりの手順のまま通れるようにしました。

「使われないシステム」は、機能が足りないから使われないのではありません。今までの手順に一手間を足してしまうから使われない。導入して数ヶ月で誰も開かなくなるツールは、たいていこの一手間を軽く見ています。

チャプター 4

AIが出した数字を、そのまま出さない

設計の時点で決めていたのは、最終的な金額の判断は人が持つということです。AIが出すのはあくまで概算レンジと根拠。それを見て、この案件は事情が違うと判断すれば、担当者が調整して出します。

自動化の範囲を欲張らなかったのは、見積が会社の信用に直結するからです。ここを丸ごと任せてしまうと、説明できない金額がお客様に出ていくことになります。任せる範囲と人が持つ範囲を最初に線引きしておくことが、結果として長く使われる条件になります。

経験の浅い担当者でも、根拠を確認しながら概算を出せる状態になりました。ベテランの役割は「見積を作ること」から「出てきた見積を確認すること」へ移っています。

課題
リフォームの概算見積は、現場を長く見てきた担当者の経験に依存していました。同じ条件でも人によって金額が変わり、その担当者の手が空くまで見積が出せない。結果としてお客様への回答が遅れ、商談が前に進まない状態が続いていました。
打ち手
まず過去の見積データを棚卸しし、金額を左右している条件を洗い出すところから入りました。そのうえで、条件を入力すると概算レンジと根拠になった過去案件が出るAIを開発。既存の見積フローの中に置き、担当者が普段どおりの手順のまま使えるようにしています。
その後
経験の浅い担当者でも、根拠を確認しながら概算を出せる状態になりました。ベテランの役割は「見積を作ること」から「出てきた見積を確認すること」に移っています。

お問い合わせ

AIの実装も、社内の人材育成も。まずは現状をお聞かせください。内容を確認のうえ、担当者よりご連絡いたします。

会社案内

株式会社AccelShiftの事業内容・実績・体制についてご案内しています。