「営業に AI を入れたい」という相談は、たいてい同じ形で来ます。議事録の自動作成を試した、提案書のたたき台を作らせてみた、担当者は面白がっている、でも受注が増えた実感はない。しばらくすると使う人が減っていく。当社に届く相談を見るかぎり、そこで効いているのは AI の性能より、営業の仕事を一つのかたまりとして扱っていることです。案件の進み具合を記録することと、見積の金額を決めることと、商談で聞いた話を残すことと、提案書の文章を書くことは、必要なデータも、間違えたときの損害も、確定してよい人も違う。まとめて「営業支援 AI」と呼んだ瞬間に、どこまで任せるかを決められなくなります。
この記事は、営業の業務に AI を入れて本番まで持っていく手順を扱います。ハブ記事で書いた FDE（Forward Deployed Engineer）型の進め方は、要件定義書を作らず、現場に入って動くものを先に出し、本番稼働と引き継ぎまで運ぶ。営業でそれをやるときに答えるのは3つ。案件管理・見積・商談記録・提案書の4つに業務を割り、それぞれ AI がどこまでやり人がどこで確定するかをどう決めるか。その前提になる案件データ（ステージ・確度・活動記録）をどう直すか。顧客の名前や取引条件をどこまで AI に渡してよいか。このうち最初の手直しは、いま使っている案件管理システムの標準機能と社内の運用変更で片づく範囲が大きい。外注が要る条件は最後の節に書きました。Anthropic と OpenAI のエージェント設計の公開資料、kintone と HubSpot の公式ヘルプ、個人情報保護委員会の注意喚起、総務省・経済産業省の AI 事業者ガイドラインと、当社が経理 AX・kintone・案件管理システム刷新・Claude 導入で本番稼働まで伴走した経験を一般化して書いています。
営業の AI 化は「営業支援」というひとかたまりでは進まない。案件管理・見積・商談記録・提案書の4業務に割り、AI の出力は未確認の下書きで止め、確定は人が押す。前提は案件データで、ステージ定義・確度の決まり方・活動記録の置き場所の3点が揃わないと材料がない。顧客名と取引条件の入力範囲は情シスと法務が先に決める。
この記事の要約
定着を妨げる主な要因——4つの業務が混ざっている
営業の現場で AI を試すとき、最初に手が伸びるのは商談の文字起こしと提案書の下書きです。どちらも一人で試せて、その日のうちに結果が見える。ところが、この2つは他の誰の判断も要らない部分です。要らないから一人で試せる。そして要らないから、社内の仕組みに何も残らない。担当者が異動すれば、その工夫も一緒に無くなります。
一方で、案件の進み具合の記録と見積の作成は、他の人の判断が絡みます。ステージを進めるのは営業本人でも、値引きを認めるのは上長で、粗利を見るのは管理部門。ここに AI を入れるには、誰がどのボタンを押すのかを決め直す作業が要る。面倒なので後回しになり、結果として「試したけど本番に載らない」状態が残ります。FDE の失敗パターン10に挙げた、担当者の手元で終わる試作の典型例がこれです。
当社は営業の業務を4つに割ってから話を始めます。案件管理（ステージ・次の行動・確度の更新）、見積（構成・金額・値引きの承認）、商談記録（録音・要約・決まったことの抽出）、提案書（構成案・本文・過去案件の流用）。割る理由は、間違えたときの損害がまるで違うからです。提案書の言い回しが少し変でも送る前に読めば直せるが、見積の金額を1桁間違えて先方に出せば、取り消すのに社内の承認をもう一度回すことになる。
定着しない要因は一つではありません。当社が相談を受けて詰まっている箇所を並べると、業務を割らずに始めること、業務ごとに必要なデータが揃っていないこと、人の作業へ戻す手順が決まっていないこと、の3つに集まります。必要なデータも業務ごとに違う。商談記録の要約は録音か手元のメモで動きますが、見積の構成候補は過去の見積が、ステージ更新の候補は案件レコードの活動記録が要ります。
エージェントを設計する側の資料も、同じ順序を勧めています。Anthropic の開発者向け記事は「単純なプロンプトから始め、評価をしっかり作って改善し、単純な方法で足りないと分かったときに初めて多段のエージェント的な仕組みを足す」と書く。同じ記事は、あらかじめ決めたコードの経路で LLM と道具をつなぐものを「ワークフロー」、LLM 自身が手順と道具の使い方を決めるものを「エージェント」と定義し、ワークフローは「定義がはっきりした作業に対して、予測しやすさと一貫性を与える」と説明しています。営業の4業務のうち、案件管理と見積はワークフローで足りる。エージェント的な動き方が要るのは、社内の複数の資料を探しに行く提案書の下書きくらいです。順番を逆にすると、同じ記事が書くとおり「作業の出来と引き換えに待ち時間と費用を差し出す」側だけが増えます。実際の月額の積み上がり方は本番 AI の月額費用を見積もるに書きました。
線引きの原則——AI は下書きまで、確定は人が押す
線引きの原則は1つです。AI の出力は未確認の下書きにとどめ、確定は人がボタンを押す。しかも、そのボタンが押された記録が残る場所で押す。この形なら、AI の精度が目標に届かない間も業務を回せます。逆に、AI の出力がそのまま先方や他の担当者に届く経路を作ると、精度が上がるまで本番に入れられません。
確定を「残る場所」で行うのが要点です。kintone を使っているなら、公式ヘルプが説明するプロセス管理がその場所になります。プロセス管理は「業務プロセスに沿った進捗管理ができる機能」で、レコードの進捗段階を表すステータス、各ステータスでレコード操作を実行する作業者、ステータスを遷移させるアクションの3つで組み立てる。アクションは「ボタンをクリックするだけで確認や承認をしたり、次の担当者にフローを回せる」と書かれています。押した事実と、そのとき何が変わったかは、編集後のレコードで変更履歴のアイコンから確認できる、と公式ヘルプにあります。kintone×AI を FDE 方式で入れるで書いた作り方と同じです。
危ない操作の前で止める仕組みは、エージェントの設計側でも標準の部品です。OpenAI の Agents SDK のガイドは、入力・出力・道具それぞれに対する保護と「中断して再開できる承認の流れ」を挙げ、「危険な作業が続く前に、処理を止めるか一時停止させたいとき」に使うものだと書く。Anthropic の記事も、エージェントは「区切りの時点、または行き詰まったときに人の判断を待って止まる」べきだとしています。営業でこの「区切り」に当たるのが、先方に出る直前と、金額が動く直前の2か所です。
| 業務 | AI にやらせること | 人が確定すること | 確定の場所（記録が残る形） |
|---|---|---|---|
| 案件管理 | 商談記録からステージ変更の候補と次の行動を出す。更新が止まっている案件を洗い出す | ステージを進めるか戻すか。次の行動の期日 | 案件レコードのステータス操作。誰がいつ変えたかが履歴に残る |
| 見積 | 過去の類似案件から構成（項目・数量・単価）の候補を出す。入力漏れと計算の食い違いを指摘する | 金額。値引き率。有効期限。先方に出す版 | 見積レコードの承認アクション。値引きが基準を超えたら上長のアクションを挟む |
| 商談記録 | 録音の文字起こし、要約、決まったこと・宿題・次回日程の抽出。結果は未確認の下書き欄に置く | 案件への紐づけ。社内の共有範囲。先方に送る議事録の文面 | 下書きから案件レコードへのコメント登録と、議事録の送信操作 |
| 提案書 | 過去の提案から構成案を出す。本文の下書き。図表の素案 | 数値（金額・期間・体制）。約束の文言（納期・成果の書き方）。差し込んだ社名と役職 | 提案書ファイルの版管理と、送付前の上長確認 |
表の4行目、提案書の「約束の文言」を人が確定するのは、そこに書いた条件が後で見積・注文書・契約書と突き合わせられるからです。過去の提案書を読ませて下書きを作らせると、別の案件で書いた条件がそのまま入ることがある。稼働時間、対応範囲、いつまでに何を出すかは、下書きの段階で毎回空欄にし、人が埋める運用にすると書き間違いを見つけやすくなります。当社は下書き用の指示文に「金額・期間・体制・納期は空欄のまま、埋めるべき箇所として印を付けて出す」と書き込んでいます。契約上どう解釈されるかの判断は、この線引きの外にあるので法務に回します。
精度の目標をどこに置くかは、業務ごとに別々に決めます。この決め方は生成AIの評価設計に書いたとおりで、テストセットに対する一致率の目標は現場が、誤りの許容は経営が、権限と記録の条件は情シスが決める。注意したいのは正解の作り方です。先月の商談記録と、そのとき担当者が付けたステージ・次の行動は、そのままでは正解になりません。書き直す前の定義で付いた値と、担当者の判断違いが混ざっているからです。当社は、営業責任者に新しいステージ定義と現行の取引条件で1件ずつ見てもらい、正しい値を確定させてから正解にします。測る対象も一致率だけにしません。決まったこと・宿題・次回日程の抜けや誤りが何件か、直すのに何分かかったかを合わせて記録すると、精度が上がったのか手間が減ったのかを分けて判断できます。
案件データの持ち方——ステージ・確度・活動記録の3点を先に直す
営業に AI を入れる仕事の半分は、AI の設定ではなく案件データの手直しです。読ませる材料が案件レコードにしか無いのに、その中身が「ステージ＝提案中のまま3か月」「確度＝担当者の気分で 50%」「商談の内容はメールと個人のメモ」だと、何を作らせても当たりません。当社が最初の2週間で見るのは3点です。
| 直す対象 | 崩れている状態 | 直したあとの形 | AI がそれで何をできるか |
|---|---|---|---|
| ステージの定義 | 「提案中」「検討中」「調整中」が並び、担当者ごとに使い分けが違う | 各ステージを「誰が何をした状態か」という動作で定義する（例 見積を先方に提出済み）。証拠になる書類か日付を1つ紐づける | 商談記録からステージ変更の候補を出せる。証拠が無いステージ移動を指摘できる |
| 確度の決め方 | 担当者が手で入力し、月末に一斉に上がる | ステージごとに確度を固定し、ステージを動かすと自動で入る。手入力を残す場合は理由を必須にする | 受注見込み額を機械的に計算できる。確度の手入力の偏りを可視化できる |
| 活動記録の置き場所 | メール本文・個人のメモ・チャットに散っている | 案件レコードに紐づくコメントか子レコードに集約する。日付・相手・決まったことの3項目を必須にする | 案件の経緯を要約できる。過去の類似案件を引ける（提案書と見積の下書きの材料になる） |
ステージと確度の関係は、CRM の公式ドキュメントが一つの型を示しています。HubSpot のヘルプは、パイプラインを「ステージを通して業務の流れを見えるようにするもの」、ステージを「レコードが業務のどこにいるかを示す段階」と定義し、既定の取引パイプラインに「アポイント設定 20%」「有望と判断 40%」「プレゼン設定 60%」「決裁者の合意 80%」「契約書送付 90%」「受注 100%」「失注 0%」の7段階と確度を置いている。重み付けした金額は「各ステージの合計金額にそのステージの確度を掛けて計算する」と書かれています。数字そのものを真似する必要はありません。参考になるのは、確度が担当者の感覚ではなくステージに紐づいて決まる構造のほうです。
当社が支援に入るときは、既存のステージ名を変えずに定義文だけ書き直すところから始めます。名前を変えると過去の案件と比較できなくなる。定義文を「誰が何をした状態か」で書き直し、証拠になる日付か書類を1つ決める。「提案中」を「提案書を先方に提出し、提出日が入っている状態」と定義すると、提出日が空のまま提案中になっている案件が一覧で出てきます。ここまでは AI が要りません。AI が効くのはその次、商談記録を読んでステージ変更の候補を出す段階からです。
活動記録の集約は、営業担当者にとっては手間が増える話なので、入力項目を増やさずに始めます。当社が使う形は、商談の録音を文字起こしして要約し、その要約を担当者本人しか見えない未確認の下書き欄に保存するところまでを仕組み側でやる。担当者は内容と紐づけ先の案件と共有範囲を確認し、登録のボタンを押して初めて案件レコードのコメントになります。自動で案件レコードに貼らないのは、確認前の要約が他の担当者の目に入り、そのまま提案書や見積の材料として引かれる経路をふさぐためです。日付・相手・決まったことの3項目を必須にするのは、後から検索できる最小の単位だからです。ここを埋めずに録音の全文だけを溜めると、量は増えるのに引けなくなります。
顧客情報をどこまで AI に渡すか——入力の線引きを先に決める
営業のデータは、他部門と比べて外に出せない情報の割合が高い。先方の担当者の名前と連絡先、まだ公表していない取引条件、競合の状況、社内で共有していない値引きの経緯。何も考えずに外部のサービスへ入力すると、後から止めるのが難しくなります。入力の範囲は試作を始める前に決めます。
公的な資料が求めていることは2つに整理できます。個人情報保護委員会が令和5年6月2日に出した「生成 AI サービスの利用に関する注意喚起等」は、個人情報取扱事業者に対して、生成 AI に個人情報を含む指示文を入力する場合は「特定された当該個人情報の利用目的を達成するために必要な範囲内であることを十分に確認すること」を挙げ、続けて、あらかじめ本人の同意を得ずに個人データを含む指示文を入力し、そのデータが応答結果の出力以外の目的で扱われる場合は「個人情報保護法の規定に違反することとなる可能性がある」として、提供事業者が「当該個人データを機械学習に利用しないこと等を十分に確認すること」を求めています。つまり、確認すべきは「何のために入れるか」と「入れた先で学習に使われないか」の2点です。
もう1つは、総務省・経済産業省の「AI 事業者ガイドライン」（第 1.0 版が令和6年4月19日公開、第 1.2 版が令和8年3月31日公開）です。AI を使う側の重要事項として、安全性の項目に「AI の出力について精度及びリスクの程度を理解し、様々なリスク要因を確認した上で利用する」、プライバシー保護の項目に「AI システム・サービスへ個人情報を不適切に入力することがないよう注意を払う」、セキュリティ確保の項目に「AI システム・サービスに機密情報等を不適切に入力することがないよう注意を払う」が並びます。これは法令ではなく、事業者が自主的に取り組む指針です。営業のデータは機密情報と個人情報が同じレコードに同居するので、この2つの項目は同時に効きます。
| データ | 外部の生成 AI に渡すときの条件 | 渡す前にやること（確認する人） |
|---|---|---|
| 商談の録音・文字起こし | 先方の発言が入るため、渡す経路と目的を情シス・法務が承認した範囲に限る | 録音することを先方に伝える運用にする。文字起こしと要約を行う経路を、入力が学習に使われない契約の環境に限定する（承認は情シス、契約条件の確認は法務） |
| 先方担当者の氏名・所属・連絡先 | 要約や提案書の下書きには不要なので、渡さない | 指示文に入れる前に伏せる。伏せ漏れがないかを送信前に担当者が本文で確認する。要約後の文面に社名・氏名を差し込むのは人の作業にする |
| 取引条件（金額・値引き・支払条件） | 見積の下書きには必要になる。渡してよい項目を案件の機密度ごとに事前に列挙する | 過去案件の単価を渡すか、金額を伏せて構成だけ渡すかを案件の機密度で分ける。列挙にない項目が要るときは営業責任者に確認する |
| 競合の情報・社内の検討経緯 | そのまま渡さない | 提案書の下書きに要る部分だけを、担当者が要約し直して渡す |
| 自社の標準提案書・料金表 | 社内資料でも無条件ではない。未公開の料金表・他社名の入った事例は外す | 渡す資料の一覧と最終更新日を情シスが管理する。一覧に載っていない資料を渡すときは情シスの承認を挟む |
表を「渡してよい・渡さない」の2択で作らないのが要点です。社内資料でも、未公開の料金や他社の名前が混ざっていれば、外に出た時点で機密情報の入力になる。文字起こしを社内で処理しても、要約から先を外部のモデルに投げるなら氏名や取引条件が渡る経路は残ります。欄は「渡す条件」と「渡す前に誰が何を確認するか」で埋めます。
この表を作る作業自体は情シスと法務の仕事で、FDE は判断材料を並べる側です。並べ方は顧客データを外に出さずに AI を本番で使うに書いた6項目と同じで、営業に固有なのは録音と先方担当者の情報が増える点です。
90日で本番に載せる進め方——見積から入るか、記録から入るか
FDE の90日ロードマップに書いた週次の進め方を、営業に当てはめます。90日で4業務すべてを本番に載せるのは無理があるので、順番を決める。当社の判断軸は3つです。正解が今日そろっているか（営業責任者が確認したテストセットを作れるか）。間違えたときの損害が軽いか。確定のボタンを押す人が1人で済むか。
この3つで見ると、多くの会社は商談記録の要約から入ることになります。先月の商談と、そのとき担当者が残したメモを営業責任者が確認すれば正解を作れる。間違えても担当者が直すだけで済む。確定を押すのは担当者1人。次が見積の構成候補で、正解は過去の見積そのもの、損害は重いが、確定に上長の承認を挟めば止められる。提案書は正解が一つに定まらないので、一致率ではなく「そのまま使えた割合」を担当者が申告する形で測ります。案件管理のステージ更新の候補出しを最後に回すのは、商談記録が案件レコードに溜まっていないと材料が無いからです。この順番を守らないと、ステージ更新の候補が当たらない理由が AI ではなく入力の空欄だった、という結末になりやすい。
ただし、この順番が当てはまらない会社もあります。訪問先の都合で録音できない、商談の件数が月に数件しかない。この場合は見積から入ります。過去の見積は文書として残り、項目と単価という形も決まっていて、正解を作り直す手間が小さい。逆に、見積の様式が案件ごとにばらばらな会社は、記録から入って形を揃えるほうが早い。判断は「どちらの正解が今日そろっているか」です。両方そろっていない会社は、AI の投入を後ろに置き、第1〜2週の案件データの手直しを先に終わらせます。
最初の会議の中身も決めます。出るのは営業責任者、案件管理システムの管理者、営業担当者数名、法務は入力範囲の議題のときだけ。持ち込むのは、現行のステージ一覧と定義、直近3か月の案件一覧、過去の見積と提案書を各数件、外部サービスとの契約書。決めるのは、書き直したステージ定義、外部に渡すデータの一覧、最初に入れる業務1つ。次に進む合格基準は、ステージ定義が全段階について動作の形で書けていること、正解を確認済みのテストセットが業務1つ分そろっていること、データの一覧に情シスと法務の承認が付いていること。この3つが埋まらないうちは、AI の設定に進んでも測るものがありません。
| 期間 | やること | 終わりの状態 | 測る数字 |
|---|---|---|---|
| 第1〜2週 | 案件データの棚卸し。ステージ定義の書き直し。外部に渡すデータの線引きを情シス・法務と決める | ステージ定義と入力範囲の一覧が1枚ずつある。営業責任者が正解を確認したテストセットが業務1つ分そろう | 定義が動作で書けたステージの数。空欄のまま進んでいる案件の件数 |
| 第3〜6週 | 商談記録の文字起こしと要約を、担当者の下書き欄に保存するところまで本番投入。担当者が直した箇所を毎週数える | 対象部署の担当者が日常の中で使っている。要約の手直しが短時間で済む（当社が目安に置くのは1件あたり5分前後） | 要約をそのまま使えた割合。決まったこと・宿題の抜けの件数。確認と手直しを含めた1件あたりの作業時間 |
| 第7〜10週 | 見積の構成候補と入力漏れの指摘を投入。値引きの承認アクションを組み替える | 見積の作成時間が短くなり、基準を超える値引きが承認を通らないと出せない | 構成候補の項目一致率。承認を経ずに先方へ出た見積の件数（0 件を目標にする） |
| 第11〜13週 | 提案書の下書きを投入。ランブック・権限表・変更手順を引き渡す | FDE が抜けても、担当者の交代と資料の差し替えを社内でできる | 下書きをそのまま使えた割合。運用担当が自分で直せた変更の件数 |
13週目に何を渡して終わるかはFDE が抜けた後も回る引き継ぎに書きました。営業で固有に足すのは2つです。下書きの指示文をどこに置き誰が直してよいかを決めること。営業の言い回しは商材が変われば変わるので、指示文はいちばん頻繁に触る資産になります。もう1つは外部に渡すデータの一覧の更新責任者を決めること。新しい AI 機能が営業ツールに追加されるたび、渡る先が1本増えます。
着任からの最初の1週間で何を見るかはFDE は初日に何をするのかと同じですが、営業の場合は同行が最短です。当社は着任した週のうちに商談へ同席させてもらうようにしています。案件レコードに書かれていることと、担当者が実際にやっていることの差は、レコードを何百件読むより1件の同行で分かる。差が大きい会社ほど、AI より先に直す対象がはっきりします。
本番後に見る数字と、止めるときの条件
本番に載せたあと、営業の AI で見る数字を挙げます。1件あたりの作業時間（導入前と、導入後の確認・修正を含めた時間を同じ条件で比べる）。抜き取り確認で見つかった誤りの件数（担当者が「そのまま使えた」と申告した要約から毎週数件を営業責任者が読み直す）。承認を経ずに先方へ出た書類の件数。次の活動予定日を過ぎても記録が入っていない案件の割合。月額の利用料と、投入した人件費を足した総額。
1つ目と5つ目を並べるのは、投資を続けるかを判断するのに片方だけでは足りないからです。作業時間が減っても、削れた時間より費用が上回れば止めます。2つ目を抜き取り確認にしているのは、「そのまま使えた割合」が、担当者が中身を見ずに登録しても上がる数字だからです。申告だけを追うと、読まれなくなった時期に数字が良くなる逆転が起きます。
4つ目を日数ではなく「次の活動予定日を過ぎたか」で測るのは、商談の間隔が商材によって違うからです。月に一度しか動かない案件で7日の停滞を数えても意味がない。週次で見て、割合が上がった週にその担当者へ理由を聞きに行く。当社が聞き取った範囲では、理由の多くは AI の出来ではなく、入力の1手間が業務の流れと合っていないことでした。
止めるときの条件も先に決めます。承認を経ずに先方へ出た書類が出たら、その業務だけ人の作業に戻す。抜き取り確認の誤りが2週続けて基準を超えたら、指示文の見直しが済むまで要約の生成を止める。戻す手順が1つの操作で済むように作っておくのが FDE の仕事で、設定を10か所直さないと戻せない作りにすると、誰も止めなくなります。
費用の見方は本番 AI の月額費用を見積もるに書いたとおりですが、営業は月内の偏りが大きい。月末に商談と見積が集中し、その週だけ利用量が跳ねます。上限は月合計だけでなく日あたりでも置くと、指示文の誤りで同じ処理が繰り返される事故を早く止められます。
ここまでの作業のうち、外に頼まないと進まない部分は多くありません。ステージ定義の書き直し、確度の自動計算、活動記録の必須項目の追加は、kintone や HubSpot の設定画面でできる範囲です。文字起こしと要約も、案件管理システムや会議ツールの標準機能で足りる会社があります。外部の支援が要るのは3つの場合です。既存機能が案件管理システムをまたぐ処理に対応していない。承認の流れを組み替えるために権限設計と既存の運用の両方を触る。テストセットを作って測る担当者を社内に置けない。どれにも当たらないなら、まず社内で試すほうが速く、費用も小さく済みます。
外に頼むと決めた場合は、着手前に4点を書面で合わせます。対象業務（4業務のうちどれを何週目までに）、費用の上限、受け入れの基準（何がどうなったら完了か）、引き継ぎの範囲（指示文・権限表・変更手順のどれを誰に渡すか）。FDE 型は要件定義書を先に作らない進め方ですが、この4点まで決めないという意味ではありません。曖昧なまま始めると、動くものは出ても、いつ終わったのかが決まらなくなります。
まとめ
順番を1行ずつ並べます。案件データを直す（ステージを動作で定義し、確度をステージに紐づけ、活動記録を案件レコードに集める）。業務ごとに線を引く（AI の出力は未確認の下書きまで、確定は人が押し、その操作が変更履歴に残る場所で行う）。外部に渡すデータの条件と確認者を、情シス・法務と決める。投入順は、正解が今日そろっているほうから決める。本番後は、作業時間・抜き取り確認・事故・活動予定に対する停滞・総額を週次で見て、基準を割ったら人の作業に戻す。
定着を妨げる要因として挙げた3つは、この順番でそれぞれ潰れます。業務を割らずに始めることは線引きで、データが揃っていないことは案件データの手直しで、戻す手順が無いことは止める条件を先に決めることで。案件データの手直しは AI を入れなくても効く改善なので、外注を決める前に社内で着手できます。
FDE を募集しています（会計FDE／FDE・業務システム）
経理の月次をAIで本番まで持っていく「会計FDE」（会計士・経理責任者・管理部門経験者）と、要件が固まる前に動くものを出して本番まで運ぶ「FDE（業務システム）」（ITコンサル・PM/PL・情シス出身者）を正社員で募集しています。応募でなくても構いません。まず30分の「キャリア相談」から。採用のお問い合わせフォームに「キャリア相談希望」と書いて送ってください。
営業の案件管理・見積・商談記録・提案書に、AI を本番で入れます
案件データの棚卸しとステージ定義の書き直し、AI と人の線引き、外部に渡すデータの範囲決め、商談記録の要約から見積・提案書までの投入順、引き継ぎまでを、貴社の営業の流れと既存の案件管理システムに合わせて設計します。kintone・Salesforce・スプレッドシートのいずれで案件を管理していても、まず既存機能と社内の運用変更で済む範囲を切り分けたうえで、いま動いているものを止めない進め方を組みます。