商談メモから自動で埋まる項目と、手で残る項目
商談の記録から機械的に取れる項目と、担当者の判断が要る項目は分かれます。商談1件あたりに何が残るかを先に一覧で示します。
| CRMの項目 | 商談後の扱い | 担当者に残る作業 |
|---|---|---|
| 面談日と形式 | 自動で埋まる | 記録が残っていない商談だけ入力する |
| 参加者 | 名乗りがあった範囲で自動で埋まる | 名乗りが無かった人を足す |
| 商談内容の要約 | 自動で埋まる | 読んで抜けを補う |
| 次回予定とアクション | 期限が明確なものは自動で埋まる | 不要な予定を消し、担当が決まっていないものを埋める |
| 議事録の原文と録音への参照 | 自動で埋まる | なし |
| フェーズ | 判定案を出すところまで | 案と根拠を見て確定する |
| 金額の見込み | 提示済みの金額だけ候補を出す | 見込み額として確定する |
| 確度 | 埋めない | 担当者が決める |
| 決裁の関与者と競合 | 発言に出た範囲だけ候補を出す | 追加するかどうかを判断する |
| 失注理由 | 埋めない | 選択肢から選ぶ |
分け方の基準は、間違っていたときに何が起きるかです。あとから直せる項目は自動で反映し、集計や予測へ流れる項目は担当者が確定します。この形にすると、商談後に担当者が触るのは数項目に収まり、記録を探して思い出す時間が、出てきた内容を確認する時間に置き換わります。
自社のCRMで同じ形にできるかは、製品名ではなく、下書きを保持できるか、項目と選択肢を機械で取れるか、書き込む権限を分けられるか、で決まります。Salesforce、HubSpot、kintoneのそれぞれでどこを見れば分かるかは、後半の「対応できるCRM・SFAの条件を先に確かめる」で扱います。
商談の記録がCRMに残らない理由
CRMやSFAは、入力された内容の分だけ使えます。ところが商談の直後は次の準備が入り、入力は移動中や週末にまとめて行われます。そのとき手元にあるのは断片的なメモで、誰が何を言ったかは薄れています。結果として、活動履歴は日付と「訪問」だけ、次回のアクションは空欄、確度は前回と同じ値のまま、という状態になります。
入力が滞る原因を分けると3つあります。
入力の手間が商談ごとにかかります。 項目が多いCRMほど、1件あたりの入力に時間がかかります。必須項目が埋まらないと保存できない設計だと、あとで入力しようとして先延ばしになります。
判断が要る項目と、記録するだけの項目が混ざっています。 参加者や日付は記録するだけですが、確度やフェーズは担当者の判断です。同じ画面に並んでいるため、判断が決まらないと記録の側も止まります。
入力した内容が自分に返ってきません。 上への報告のために入力している感覚になると、精度も鮮度も落ちます。
自動化で解けるのは1つ目と、2つ目の一部です。商談の記録から機械的に取れる項目を先に埋め、担当者が判断する項目だけを残す形にすると、入力にかかる時間が「思い出す作業」から「確認する作業」に変わります。取り出した内容を別のシステムへ転記するという意味では、受発注業務をAIで自動化する で扱った発注メールの読み取りと同じ型です。違うのは、商談の記録には数値としての正解が無く、解釈が入る項目が多いところです。
商談の記録から取り出す項目を分ける
入力の対象になる項目を、発言や記録から機械的に取れるものと、担当者の判断が要るものに分けます。この切り分けを飛ばして「議事録からCRMを埋める」とだけ決めると、確度やフェーズの出力が毎回揺れます。
| 取り出す項目 | 記録から取れるか | 確定できないときの扱い |
|---|---|---|
| 面談日時と形式 | 取れる（会議の予定や録音の情報から） | 記録が無ければ担当者の入力を待つ |
| 参加者と役職 | 概ね取れる（名乗り、招待者の一覧、署名） | 名乗りがない参加者は空欄にし、推測で役職を付けない |
| 話した内容の要約 | 取れる | 要約できるだけの発言量が無い場合は原文を残す |
| 次回アクションと期限 | 概ね取れる（「来週までに」「見積を送る」といった発言） | 誰が持つか不明なものは担当者へ確認を出す |
| 検討中の課題と要望 | 取れる | 発言に無い課題を補わない |
| 金額の見込み | 部分的（提示した金額は取れる） | 提示前の商談では空欄。範囲で話した場合は幅のまま残す |
| 確度 | 取れない（担当者の判断） | 前回の値を据え置かず、未更新であることが分かる形にする |
| フェーズ | 条件を定義すれば判定できる | 定義に当てはまらない商談は担当者へ回す |
| 決裁の関与者と決裁の流れ | 部分的（発言に出た範囲だけ） | 出ていない部分は空欄。組織図から推測しない |
| 競合の状況 | 部分的（社名が出れば取れる） | 「他社も見ている」だけの発言を特定の社名に紐づけない |
| 失注理由 | 取れない（判断と背景の整理が要る） | 選択肢から選ぶ形にし、記録は担当者が確定する |
右列を「推測しない」で埋めた項目が多く見えますが、ここを埋めてしまうと後の判断が狂います。特に決裁の関与者と競合は、商談の記録に出ていないことを補うと、実在しない前提の上で戦略を立てることになります。空欄のままにしておけば、次の商談で確認する対象として残ります。空欄になった決裁の流れや課題は、次の提案を組み立てるときの調べる項目としてそのまま使えます。商談の前を扱う側の設計は 提案書作成をAIで自動化する で扱っています。
要約についても、何を要約するかを決めておきます。商談の全体を短くするのではなく、「顧客が言った課題」「こちらが提示した内容」「決まったこと」「持ち帰りになったこと」に分けて出す形にすると、後から読む人が使えます。一続きの文章にすると、読む側は結局元の記録を開きます。
自動で反映する項目と、人が確認して確定する項目
取り出した内容を、そのままCRMへ書き込むかどうかは項目で分けます。基準は、間違っていたときに何が起きるかです。
| 項目 | 反映の扱い | そう分ける理由 |
|---|---|---|
| 活動履歴（面談日、形式、要約） | 自動で反映 | 間違っても記録が1件増えるだけで、後から直せる |
| 参加者 | 自動で反映（名乗りがある範囲） | 名前の誤りは次の連絡で気づける |
| 次回予定とアクション | 自動で反映（期限が明確なもの） | 抜けると訪問が止まる。多めに登録して消す方が安全 |
| 議事録の原文と録音への参照 | 自動で反映 | 元の記録に戻れる経路を残す |
| 確度 | 担当者が確認して確定 | 予測に使われる値で、他部門の判断へ波及する |
| 金額の見込み | 担当者が確認して確定 | 提示額と見込み額が違う商談が多く、機械では区別しにくい |
| フェーズ | 判定案を出し、担当者が確定 | 定義に当てはまらない商談が必ず残る |
| 決裁の関与者 | 追加は提案、削除は担当者 | 一度登録した関与者を機械で消すと、経緯が失われる |
| 失注理由とクローズ | 担当者が確定 | 集計に使われ、後から直す機会が無い |
自動で反映する側は、あとから訂正できる項目です。担当者が確定する側は、集計や予測の入力になり、間違いが他の判断へ流れる項目です。この分け方だと、担当者が触るのは商談ごとに数項目に収まります。確定した項目がそのまま定例の報告に載る場合は、集計と文章の作成をどう分けるかまで含めて設計します。数値を生成させずに確定した表から引く組み方は 広告運用のレポート作成をAIで自動化する で扱っています。
確認の画面には、値の候補と一緒に「その根拠になった発言」を並べます。確度を上げる提案をするなら、なぜそう判断したか（予算の話が出た、決裁者が同席した、時期の言及があった）を発言の引用で示します。根拠が見えないと、担当者は毎回自分で議事録を読み直すことになり、確認の作業が入力と同じ手間になります。
3の照合を省くと、担当者の確認画面に「CRMが受け付けない値」が並びます。選択肢に無い競合名、廃止された商品コード、必須項目の欠けは、機械で照らせます。ここを通してから確認へ回すと、担当者は判断だけに向き合えます。
入力の手間はどこまで減るか
線引きを決めると、商談1件あたりに担当者が触る範囲が見えます。無くなるのは「記録を探して思い出し、項目の形に整えて打ち込む」ところで、残るのは判断と、その判断の材料を確かめるところです。
| 商談後の作業 | 自動化の前 | 自動化の後に残るもの |
|---|---|---|
| 面談日・形式・参加者の入力 | 予定表や名刺を見ながら打ち直す | 名乗りが無かった参加者を足すだけ |
| 商談内容の要約 | 記憶と断片的なメモから文章を書く | 出てきた要約を読み、抜けを補う |
| 次回アクションと期限 | 思い出して登録する（漏れやすい） | 不要な予定を消す、担当者が空の行を埋める |
| 選択肢と必須項目の埋め合わせ | どの値を選ぶか画面で探す | 対応表に無かった値だけ選び直す |
| フェーズと確度 | 前回の値を見ながら決める | 判定案と根拠を見て確定する（判断は残る） |
| 議事録の保管と共有 | 別途まとめて送る | そのまま残る |
減らない部分を先に見ておくと、期待の置き方がずれません。判断そのものは残ります。 確度とフェーズを担当者が確定する設計にしている以上、商談ごとに数項目へ目を通す時間はかかります。記録が無い商談は対象外です。 文字起こしも手元のメモも無い商談は、これまでと同じ入力になります。確認の画面を開く手間は新しく増えます。 根拠の提示が弱いと、確認が議事録の読み直しになり、入力にかかっていた時間が確認へ移るだけで終わります。
短くなった時間を成果として置くなら、何をもって短くなったとするかは着手前に決めます。CRMの操作ログで測るのか、担当者への聞き取りにするのかで、後から示せる根拠の強さが変わります。
フェーズの判定基準を社内の言葉で定義する
フェーズや確度の自動判定でつまずくのは、モデルの性能より前に、社内でフェーズの意味がそろっていないところです。「提案中」「検討中」「クロージング」といった名前は共通でも、どの時点でそこへ進むかは担当者ごとに違います。人が入力しても揺れている項目を機械に判定させると、揺れがそのまま増幅されます。
先に決めるのは、「何が起きたらどの段階か」です。段階の名前ではなく、観測できる出来事で定義します。
| フェーズ | 満たす条件（観測できる出来事） | 記録から拾う手がかり |
|---|---|---|
| 課題の確認 | 顧客が解決したい状態を自分の言葉で説明した | 現状の困りごとについての発言、既存のやり方の説明 |
| 要件のすり合わせ | 対象範囲と必要な機能について合意した | 「この範囲で」「まずはここから」といった範囲の確認 |
| 提案と見積の提示 | 金額を含む提案を提示し、顧客が受け取った | 見積の送付、金額への言及、内容についての質問 |
| 社内検討 | 決裁の道筋と時期が顧客から示された | 誰の承認が要るか、いつの会議にかけるかの発言 |
| 最終確認 | 契約条件の確認に入った | 契約書、開始時期、支払条件についてのやりとり |
条件は、担当者が判定できる粒度まで下げます。「顧客の関心が高まった」は判定できませんが、「決裁の道筋と時期が顧客から示された」は、発言があったかどうかで判定できます。この定義を作る手順は次の形になります。
- 直近で完了した商談を並べる。 契約に至ったものと至らなかったものを混ぜて、20件ほど選びます
- 記録を読み、段階が変わった時点を探す。 どの発言やできごとを境にフェーズを上げたかを、担当者本人に確認します
- 同じ理由でまとまるものを束ねる。 「決裁者が出てきた」「予算の枠が確認できた」のように、繰り返し出てくる境目が候補になります
- 例外を書き出す。 定義に当てはまらない商談を無理に分類せず、例外として残します。例外の割合が高いフェーズは、定義が実態と合っていません
- 判定を試し、担当者の判断とずれた商談を見る。 ずれた理由が定義の曖昧さなら定義を直し、記録に情報が無いだけなら判定の対象から外します
この過程で、社内のフェーズの数が多すぎることに気づく場合があります。判定の基準を書けないフェーズは、人が入力しても意味が揃っていない可能性が高い項目です。自動化のために定義を書き出す作業が、そのまま管理項目の整理になります。
確度についても同じ考え方で扱えますが、フェーズより難しくなります。フェーズは出来事で定義できますが、確度は将来の見込みで、同じ状況でも担当者によって差が出ます。自動で数値を置き換えるより、「フェーズと確度が食い違っている商談」「更新から時間がたっている商談」を検出して担当者に知らせる形が扱いやすいです。
対応できるCRM・SFAの条件を先に確かめる
書き込む先の制約を先に調べておかないと、動くところまで作ってから入らないことが分かります。どこまで自動で反映できるかは、使っているCRMの名前より、次の条件をいくつ満たすかで決まります。
| 確かめる条件 | どこを見れば分かるか | 満たさないときの代わり |
|---|---|---|
| 必須項目を満たさない状態で保持できる | 入力規則、下書きの扱い | CRMの外に下書きを置き、確定したときだけ書き込む |
| 項目と選択肢の一覧を機械で取得できる | 項目の設定画面、項目定義の一覧 | 一覧を書き出して対応表を手で保守する |
| 商談を一意に識別できる鍵がある | 商談レコードのIDと面談日 | 重複を弾く突き合わせを自動処理の側に持つ |
| 自動処理用の権限を分けられる | ユーザーの追加可否、権限の設定 | 更新した値に処理の出どころを残し、後から選り分ける |
| 外部から書き込む口がある | APIの提供、ファイル取込の有無 | 候補を画面に出し、担当者が貼る形に留める |
| 更新の履歴が項目ごとに残る | 履歴の設定、監査ログ | 書き込む前の値を自動処理の側で控える |
| 一度に書き込める件数の上限 | APIの利用制限、取込の単位 | 夜間にまとめて流し、日中は下書きに溜める |
書き込む口が無ければ、抽出の精度をどれだけ上げても候補の提示までで止まります。逆に、書き込む口があって権限を分けられるなら、活動履歴と次回予定までは自動で反映できます。残りの条件は、下書きをどこに置くかと、間違ったときにどう戻すかに効きます。行ごとの内容を順に見ます。
必須項目。 保存に必要な項目がそろわないと登録できません。自動で埋められない必須項目があるなら、下書きの状態で保持して担当者の入力を待つか、必須の設定自体を見直すかの判断になります。
選択肢の値。 競合名、失注理由、業種などが選択肢で管理されている場合、取り出した文字列をその値へ寄せる対応表が要ります。「A社」「A株式会社」「Aさん」が同じ選択肢を指すなら、対応表に登録します。一致しないものは新しい値を作らず、担当者へ回します。
重複の防止。 同じ商談に対して記録が二重に登録される経路を潰します。会議の予定と録音の両方から同じ商談を拾う構成だと起きやすいので、商談を一意に識別する鍵（商談レコードのIDと面談日）を決めておきます。
権限。 書き込みに使う権限を、自動処理用に分けて用意します。担当者の権限で書き込むと、更新履歴上は担当者が入力したことになり、あとで自動反映の分だけを取り消せません。
更新の履歴。 項目ごとの変更履歴が残るかを確認します。残らないシステムでは、値が書き換わった経緯を後から追えないため、自動処理の側で更新前の値と根拠を控えておく必要があります。
書き込みの口。 APIで書き込めるか、ファイルの取込か、画面への表示だけに留めるか。取込の手段が無いシステムでは、候補を提示して担当者が貼る形が現実的です。この判断は、CRM側の仕様で決まります。
書き込みの単位も決めます。項目ごとに更新するのか、商談ごとにまとめて更新するのかで、失敗したときの状態が変わります。途中で失敗して一部の項目だけ更新された状態が残ると、何が入っていて何が入っていないかが分からなくなります。まとめて更新し、失敗したら何も入れずに差し戻す形にしておくと、状態が2つに収まります。
商談を表計算ソフトや案件管理ツールで持っている場合も、条件の見方は同じです。書き込む口はあっても、権限の分離と更新履歴が弱いことが多いため、値の出どころを列として持たせるなど、CRMの機能で賄えていた部分を自分で用意することになります。
主なCRM・SFAで、どこを見れば分かるか
条件そのものは共通ですが、確認する画面は製品ごとに違います。画面の名称や設定の場所は変わることがあるため、最後は自社の管理画面と契約内容で確かめます。
| 使っているCRM・SFA | 項目と選択肢の一覧を見る場所 | 書き込みの口と権限で確かめること |
|---|---|---|
| Salesforce | 設定のオブジェクトマネージャ（項目と選択リストの値） | APIで書き込めるかは契約しているエディションと追加オプションで変わる。自動処理用の接続ユーザーを分けられるか、履歴を残す項目を指定できるか |
| HubSpot | 設定のプロパティの一覧 | 書き込みに必要な範囲をトークンの権限として指定できるか。使えるAPIの範囲がプランで変わるため契約内容も見る |
| kintone | アプリのフォーム設定とフィールドの一覧 | アプリごとに発行するトークンへレコードの追加と編集の権限を付けられるか。レコードの変更履歴を残す設定になっているか |
APIで書き込める契約であれば、どの製品でも活動履歴と次回予定までを自動で反映し、確度とフェーズは担当者が確定する形に収まります。差が出るのは、確定前の下書きをどこに置くか（CRMの中に未確定のまま持てるか、外に持つか）と、自動処理が入れた値だけを後から選り分けられるかです。書き込む口が契約に含まれていない場合は、候補を画面に出して担当者が貼る形まで下げることになります。
誤反映が起きたときに戻せるようにする
自動で書き込む以上、間違った内容が入ることは前提にします。決めておくのは、気づく手段と戻す手順です。
どこから来た値かを残す。 自動で反映した項目には、元になった記録（文字起こしのどの部分か、メモのどれか）への参照を残します。参照が無いと、値が疑わしいときに担当者が確認できません。
取り消せる範囲を分ける。 自動処理用の権限で書き込んだ更新だけを、まとめて取り消せる状態にしておきます。担当者が手で直した内容を巻き込んで戻すと、直した作業が無駄になります。
担当者からの差し戻しを受ける経路を用意する。 確認画面に「この値は違う」を返す口を置き、返ってきた内容を記録します。返せる先が無いと、担当者は自動反映を無視して自分で入力し直すようになり、二重の記録が残ります。
差し戻しの内容を規則へ戻す。 同じ誤りが繰り返されるなら、それは個別の訂正ではなく規則の不足です。特定の顧客名がいつも別の社名として取られる、期限の表現が拾えない、といったものは対応表や抽出の指示に反映します。
差し戻しには状態を持たせます。誰の手元にあるか、いつから止まっているか。商談は時間で状況が変わるため、確認待ちのまま数週間たった記録には価値がほとんど残りません。滞留している件数を見えるようにして、一定期間を超えたものは自動反映の対象から外す扱いにしておきます。
顧客の情報をどう扱うか
商談の記録には、顧客の担当者名、社内の体制、予算、他社との比較といった内容が含まれます。外部のAIサービスへ渡す設計にするなら、扱いの範囲を先に決めます。
決めるのは、どのデータをどこへ渡すか、渡した内容が学習に使われない契約になっているか、記録をどれだけの期間保持するか、誰がその記録を見られるか、の4点です。録音を扱う場合は、録音していることを相手に伝える運用も含めて整えます。
商談の記録は、社内でも扱いが分かれます。担当者と上司は全体を見られても、他部門からは金額と競合の情報を見せない、という切り分けが必要になる場合があります。CRMの権限設定でできる範囲と、自動処理が触る範囲を合わせておきます。自動処理が全社の商談を横断して読める構成にすると、CRM側で分けた権限が意味を失います。
社内で生成AIを使うときの線引きは 生成AIの社内利用ルールをどう作るか で扱っています。禁止事項を並べるだけでは運用に乗らないため、扱えるデータの範囲と、判断に迷ったときの相談先まで決めておく形になります。
入力率と鮮度で定着を測る
自動化した後に見るのは、抽出の精度そのものではなく、CRMの中身が使える状態になったかです。次の3つで見ます。
入力率。 対象の商談のうち、活動履歴と次回予定が埋まっている割合。商談の翌営業日までに埋まっているかで見ると、後追いの入力と区別できます。
更新の鮮度。 進行中の商談で、最後に更新されてからの経過日数。フェーズや確度が長く動いていない商談は、実態が動いていないのか、入力が止まっているのかを切り分ける対象になります。
担当者の訂正の割合。 自動で反映した項目のうち、あとから直された割合。項目ごとに見ると、自動反映の対象を広げてよい項目と、確認を残すべき項目が分かります。この数字は精度の指標でもあり、担当者が確認画面を見ているかの指標にもなります。訂正がゼロのまま続く場合は、精度が高いのではなく確認されていない可能性を疑います。
これらは自動化の前後で比べられるように、着手前に測っておきます。着手後にしか数字が無いと、変化が自動化によるものか、他の要因かを分けられません。測り方の組み立ては AI導入の効果測定と投資判断 を参照してください。
入力にかかる時間の短縮を成果として置くこともできますが、その場合は測り方を決めておきます。CRMの操作ログから入力にかかった時間を取れるシステムもありますが、取れない場合は担当者への聞き取りになり、前後の比較としては弱くなります。
どこから手を付けるか
範囲を広げたまま始めると、フェーズの定義でも記録の集め方でも合意が取れず止まります。狭める順序は次のようになります。
記録の種類を1つに絞る。 オンライン商談の文字起こしがある商談だけを対象にします。訪問時の手書きメモや電話でのやりとりは、後から足します。
チームを絞る。 扱う商材が同じで、フェーズの意味がそろっているチームから始めます。ここでフェーズの定義と選択肢の対応表が固まります。
反映する項目を絞る。 活動履歴と次回予定だけを自動反映の対象にします。確度とフェーズは判定案の提示までに留め、担当者の判断とどれだけ一致するかを記録します。
訂正の記録を見て広げる。 直しがほとんど出ない項目から、確認を外していきます。着手前に自動化の範囲を決め切らず、記録を材料にします。
始める前に用意するのは、対象とする商談の記録、フェーズの定義（または定義を作る場としての商談の振り返り）、CRMの必須項目と選択肢の一覧、書き込みに使える権限、そして運用を直し続ける担当です。最後の1つが決まっていないと、対応表が更新されず、選択肢が増えた時点で使われなくなります。検証から本番運用までの進め方と見積の考え方は AIエージェント開発の進め方 で扱っています。
まとめ：商談メモのCRM自動入力を設計するときの要点
- 入力が滞る原因は手間と判断の混在にある。機械的に取れる項目を先に埋め、担当者には判断が要る項目だけを残す
- 取り出す項目ごとに、記録から取れるかどうかと、取れないときの扱いを決める。決裁の関与者や競合を推測で補わない
- 自動で反映するのは後から直せる項目（活動履歴、次回予定、参加者）、担当者が確定するのは集計や予測に流れる項目（確度、金額、フェーズ）
- フェーズは「何が起きたらどの段階か」を観測できる出来事で定義してから判定させる。定義が揺れている項目は自動化しても揺れる
- 手間が減るのは思い出して打ち込む部分で、判断と確認は残る。記録が無い商談は対象外になるため、期待の置き方を先にそろえる
- 製品名で決まるのは確認する画面の場所までで、届く範囲は条件で決まる。下書きを保持できるか、項目と選択肢を機械で取れるか、書き込む権限を分けられるか、APIで書き込める契約かを先に確かめる
- まとめて更新し、失敗したら何も入れない形にする。条件を満たさない項目は下書きの提示までに留める
- 自動反映には元の記録への参照を残し、自動処理の更新だけを取り消せるようにする。差し戻しの内容は対応表や抽出の指示へ戻す
- 顧客の情報をどこへ渡すか、誰が見られるかを先に決める。自動処理がCRMの権限設定を越えて読める構成にしない
- 定着は入力率、更新の鮮度、担当者の訂正の割合で見る。着手前に測っておかないと変化の理由を分けられない
Augueでは、商談の記録や社内文書を読み取って既存システムへ反映するAIエージェントの開発に対応しており、どこまでを自動で反映しどこに担当者の確認を残すかの線引きから一緒に検討できます。自社のCRM運用を対象にできるか判断したい方は、是非ご相談ください。
関連する記事
商談の前に戻って提案書の下書きを組む側は 提案書作成をAIで自動化する、同じく文書を読み取って別のシステムへ転記する型は 受発注業務をAIで自動化する、記録した数値を定例の報告へつなぐ側は 広告運用のレポート作成をAIで自動化する、開発の進め方と見積の考え方は AIエージェント開発の進め方、効果の測り方は AI導入の効果測定と投資判断 を参照してください。
よくある質問
CRMに標準で付いているAI機能と、自社で組む場合はどう違いますか？
標準機能は追加開発なしで使える代わりに、取り出す項目とフェーズの定義が提供元の考え方に沿います。社内で使っている段階の呼び方や、業界特有の決裁の流れに合わせたい場合は、自社で組む側に寄ります。まず標準機能を試し、出力が自社の運用と食い違う箇所だけを作る形にすると、作る範囲を小さく保てます。
文字起こしの精度が低い場合でも成立しますか？
固有名詞の誤りは残る前提で組みます。社名や製品名は取引先マスタと突き合わせて置き換え、一致しないものは候補として表示するだけに留めます。金額や日付のように後工程へ影響する値は、音声だけを根拠にせず、資料や送付済みの見積と照らして確認できる形にしておきます。
対象の商談を絞って試すとき、何件くらい見れば判断できますか？
件数そのものより、担当者の直しがどの項目に偏るかが見えるまで続けるかどうかで決まります。フェーズの定義を作るのに使った商談とは別に、直近の進行中の商談を対象にして、同じ項目の直しが繰り返し出るかを見ます。直しの理由が定義の曖昧さに集まっているなら、件数を増やす前に定義を直す段階です。
商談の記録から受注の見込みを予測するところまで広げられますか？
入力が埋まっていない段階では予測の材料がそろわないため、順序としては後になります。まず活動履歴と次回予定が抜けなく残る状態を作り、フェーズの定義が担当者の間でそろってから検討する対象です。定義が人によって違うまま予測を出すと、当たっているかどうかの判断もできません。