工務店・ハウスメーカーの顧客管理移行 表計算から移す前の整備手順

一方、担当者、商談段階、最終接触日などが一定のルールで記録され、重複も少ないなら、小さな対象範囲でテスト移行へ進めます。移行前の整備は、①完了条件の設定、②対象決定、③原本保全、④項目対応、⑤表記統一、⑥重複整理、⑦状態と履歴の再判定、⑧テスト移行、⑨照合、⑩切替、という順序で進めると再現できます。

本記事では、全体の業務と判断順序を整理し、その結果を一つの「移行前整備台帳」にまとめます。項目設計、ステータス定義、個人情報の運用設計など、個別テーマの詳細は該当箇所から専門記事へ案内します。

01.最初に「移行できた状態」を決める

顧客管理の移行は、表計算の行数とCRMの登録件数が一致しただけでは完了しません。移行後に担当者が顧客を探せること、次に取るべき行動が分かること、重要な履歴や原資料へたどれること、新しい記録が同じルールで増えることまで含めて完了と考えます。

住所や電話番号が全件入っていても、現在の担当者が分からなければ引き継ぎには使えません。反対に、古いアンケートの自由記述をすべて構造化できなくても、顧客、案件、担当、進行状況、次回行動、原資料への参照先が残っていれば、日常業務を開始できる場合があります。

ここからは、架空の工務店例006を例にします。工務店例006には営業担当が3人おり、年間の新規問い合わせは約240件、既存表に載っている記録は約2,600件です。内訳は、見込み顧客1,100件、失注または保留となった顧客600件、OB施主700件、紹介者や協力会社など200件とします。現在は営業共有表、見学会申込表、OB名簿、担当者ごとの個人表に情報が分かれています。

これは手順を説明するための架空例であり、実在企業の成果値や推奨値ではありません。自社では同じ件数を目標にせず、実際のファイル数、行数、担当者数、更新頻度へ置き換えてください。

移行開始時には、次のような完了条件を一枚にします。

この表から読み取るべきなのは、「全データを完全に移すこと」と「業務を再開できること」は同じではないという点です。完了条件を先に置けば、価値の低い自由記述の修復に時間を使いすぎず、担当、状態、次回行動などの重要項目を優先できます。

完了条件には、件数だけでなく業務上の再現性を含めます。次の三つの質問に答えられない場合は、まだ移行範囲が固まっていません。

• 担当者が不在でも、記録を見た別の担当者が次の行動を選べるか
• 移行した値がどの旧記録から作られたか説明できるか
• 移行翌日の新規問い合わせを、同じルールで登録できるか

CRM製品の比較を先に始めると、機能一覧に合わせて移行範囲が膨らみやすくなります。製品候補を検討する段階では、工務店のCRM選び｜入力項目と運用から比較するを参照し、本記事では製品選定と切り分けて「投入できるデータと判断記録をつくること」に集中します。

02.移行対象と対象外を業務単位で切り分ける

最初の実作業は、ファイルを開いて修正することではありません。どの業務の記録が、どこにあるかを棚卸しします。「顧客一覧.xlsx」のようなファイル名だけで判断せず、その中に問い合わせ、来場、商談、契約、施工、点検、紹介など、どの業務の記録が入っているかを確認します。

工務店では、一人の顧客が複数の表へ登場します。資料請求時は見込み顧客一覧、見学会参加時は申込者一覧、契約後は工事台帳、引渡し後はOB名簿に載る、といった状態です。したがって、ファイルごとに移すか捨てるかを決めるのではなく、記録の役割ごとに扱いを決めなければなりません。

移行対象は、次の四つに分けると整理しやすくなります。

• 顧客基本情報：氏名、連絡先、住所など、人や組織を識別する記録
• 案件情報：新築、建替え、リフォームなど、相談単位の記録
• 活動履歴：電話、来場、訪問、提案、メールなど、接点の記録
• 管理情報：担当者、状態、次回対応日、流入経路など、業務を進める記録

ここで重要なのは、「一人につき一行」という既存表の形を、そのままCRMの構造だと思わないことです。同じ顧客が自宅の建替えと実家の改修を相談しているなら、顧客は一人でも案件は二つです。家族それぞれの連絡先を持つ場合も、世帯と個人をどう扱うかを決める必要があります。

また、OB施主は商談ステータスではなく、顧客区分として扱います。「誰であるかを示す区分」と「案件がどの段階にあるかを示すステータス」を同じ列へ混在させると、引渡し後の相談や追加工事を表現できなくなるためです。

この模式図で押さえる点は、移行対象を決める前に正本候補を選ぶことです。同じ電話番号が三つの表にあり、値が異なっている場合、三つを一度に取り込んでも正しさは増しません。どの表を優先し、矛盾を誰が確認するかを決めます。

棚卸し表には、少なくとも次の項目を設けます。

この表からは、保管場所と正本が別概念であることを読み取ります。更新頻度が高い表を無条件に正本とせず、誰がどの業務で更新し、どの項目に責任を持っていたかまで確認します。氏名は契約資料、次回対応は営業共有表、引渡日は工事台帳というように、項目ごとに正本が異なる場合もあります。

対象外にした記録も、直ちに削除するとは限りません。「CRMへは移さないが旧ファイルで参照する」「内容を確認してから扱いを決める」「業務上の必要性がないことを確認した後に削除を判断する」といった区分を設けます。

保存の必要性や期間は、記録の種類、契約、社内規程、利用目的、適用される法令などの条件により異なります。本記事だけで一律の年数は決められません。移行対象外と保存不要を同義にせず、判断者と根拠を台帳に残します。

03.原本を固定し、移行期間中の差分を一本化する

棚卸しができたら、修正前の原本を固定します。現用ファイルへ直接、列追加、置換、重複削除を始めると、いつ誰が何を変えたのか追えなくなります。複数担当者が同時に使う表では、移行準備中にも新しい問い合わせや商談更新が発生します。

原本固定では、「基準日時点の複製」と「基準日以降に発生した差分」の両方を管理します。架空の工務店例006では、2026年9月25日18時を初回抽出の基準日時とし、それ以前のデータを整備対象にします。それ以降の新規登録や変更は差分台帳へ記録し、本番切替前に追加取込する想定です。

ファイル名に「最新版」「最終」「本当の最終」と付けるだけでは管理できません。抽出日時、抽出者、元の保管場所、行数、対象期間、編集可否を台帳に残します。行数は正しさを保証しませんが、作業中に大量の行が欠落したことを検知する手掛かりになります。

この表で見るのは、1,842行などの数字そのものではなく、「どの時点の何を整備しているか」です。見出し行や空行を含めるかなど、行数の数え方も決め、同じ条件で移行前後を比較できるようにします。

原本、作業用、取込用は分けます。

• 原本：基準日時点の内容を変更せず保持する
• 作業用：表記統一、分割、判定、確認結果を記録する
• 取込用：CRMの指定形式と取込順に合わせて出力する

作業用ファイルから不要列を削除しても、原本には残るようにします。変換後の値だけでなく、旧値、変換規則、処理日、作業者を追える状態にします。

移行期間中の通常業務を止められない場合は、更新経路を一本化します。たとえば「基準日後も旧表を更新し、変更行には更新日時を必須記入する」「新規分と変更分を差分表へ登録する」のいずれかに統一します。口頭、付箋、個人メモなど複数経路を許すと、最終差分を回収できません。

差分には新規顧客だけでなく、次の変更も含まれます。

• 電話番号やメールアドレスの訂正
• 担当変更
• ステータス変更
• 次回対応日の追加または変更
• 長期保留、失注・終了、受注の確定
• 案内の停止など、連絡方法に関する意思表示
• 顧客区分や関連案件の変更

新規行だけを追加取込すると、基準日後に更新された既存顧客が古い状態へ戻ることがあります。差分台帳には、CRM上の更新対象を特定するキーと、「旧値から新値へ変更するのか」「未登録の値だけを補うのか」を記録します。

04.利用目的と閲覧範囲は移行可否の判断条件にする

CRMへ移せる形式であることと、CRMへ集約する必要があることは別です。氏名、住所、電話番号、メールアドレス、相談内容、家族に関する記録などについて、移行作業では少なくとも次の三点を確認します。

1. どの業務に使う記録か 2. その業務を行う誰が閲覧する必要があるか 3. ファイル自体を複製する必要があるか、参照先だけで足りるか

利用目的、閲覧権限、社外共有、保存先、保存期間、事故時の対応までを設計する手順は、工務店の顧客情報の扱い｜閲覧・共有・保管の運用設計で扱います。本記事では、その設計を繰り返さず、移行作業を止めるべき条件と台帳への記録に絞ります。

個人情報保護委員会の個人情報保護法ガイドライン（通則編）は、個人情報の利用目的、安全管理措置、従業者や委託先の監督などに関する事業者向けの一次資料です。ただし、個別の記録をCRMへ移すこと、第三者へ提供すること、共同利用することなどが適切かは、実際の取得経緯、利用目的、契約関係、運用方法に応じて確認する必要があります。

移行担当者が個別案件の適法性を推測して確定してはいけません。利用目的、取得経緯、閲覧者、社外共有の条件が分からない項目は、通常の取込データから分け、社内の責任者や必要に応じた専門家が確認できる状態にします。

自由記述に複数の内容が混在している場合は、全文を機械的に移す前に分解を検討します。「次回は10月2日に電話。平日は18時以降希望。資金面を心配している」という記録なら、次回対応日、連絡希望時間、相談メモに分けられます。ただし、原文の意味を変えないこと、元の記録にない事実を補わないことが前提です。

移行作業中に誤送信、紛失、不正な閲覧、対象外データの取込などを発見した場合は、個人の判断でファイルを消したり関係者全員へ転送したりせず、次の順序で動けるようにします。

具体的な報告、本人への連絡、関係機関への報告などが必要かは、事案と適用条件により異なります。現場担当者がこの記事だけで判断せず、自社の事故対応手順と一次資料を確認します。

05.項目対応表で「移す・変換する・参照に残す」を決める

次に、旧表の各列をCRMのどこへ移すか決めます。これが項目対応表です。列名が同じでも意味が違う場合があり、列名が違っても同じ情報を持つ場合があります。「顧客名」と「氏名」を名前だけで対応させず、入力例と使い方を確認します。

旧表の「日付」という列が、問い合わせ日、最終連絡日、面談予定日、契約予定日のどれを意味するか分からない場合があります。一つの列へ担当者ごとに異なる日付を入れていたなら、そのまま移行先を決められません。意味を確定できない行は例外一覧へ分け、都合のよい解釈で埋めないようにします。

項目対応表には、旧列名と新項目名だけでなく、データ型、変換規則、空欄時の扱い、例外処理、確認責任者を入れます。

この表で大切なのは、「形式変換」と「内容訂正」を分けることです。全角数字を半角数字へそろえるのは形式変換ですが、古そうな電話番号を別資料の番号へ置き換えるのは内容訂正です。内容訂正には、旧値、新値、根拠資料、判断者、判断日を残します。

項目数は、旧表の列をすべて再現して決めるものではありません。日常の検索、担当割当、進捗判断、次回対応、引き継ぎに必要かを確認します。必要な項目を決める詳細手順は、工務店の顧客管理項目｜最初に必要な記録を絞るを参照してください。

選択式項目は、表記だけでなく意味も統一します。たとえば流入経路に「HP」「ホームページ」「WEB」「ネット」がある場合、それらが同じ意味なのか、自然検索、広告、施工事例、予約ページなどを区別していたのかを確認します。根拠がなければ、細かな経路を推定して分類しません。

空欄にも複数の意味があります。

• まだ確認していない
• 確認したが分からない
• その顧客には該当しない
• 旧運用では記録対象ではなかった
• 入力が漏れている

これらをすべて「不明」で埋めると、確認の要否が分からなくなります。CRMの仕様が許すなら空欄理由や要確認フラグを分けます。必須項目のために仮値を入れる場合も、通常の業務データと区別できる経過措置にします。

修正前後を照合しやすくするため、変換例も項目対応表へ付けます。

一括変換は、対象ファイル、対象列、完全一致か部分一致か、適用開始日を明記します。変換後の値だけを見て規則を変更すると、再取込時に同じ結果を再現できません。

06.名寄せは候補抽出と人の判定を分ける

複数の表を集約すると、同じ顧客が何件も現れます。しかし、氏名が同じだから同一人物とは限らず、電話番号が同じだから一人とも限りません。家族が固定電話を共用する場合、夫婦で同じメールアドレスを使う場合、法人窓口の番号が共通の場合があるためです。

名寄せでは、機械的な条件で候補を出し、その後に人が根拠を見て確定します。候補抽出の目的は確認対象を絞ることであり、自動的にレコードを結合することではありません。

この模式図から読み取るべきことは、表記統一の直後に行を削除しないことです。候補を横並びにし、住所、相談内容、担当者、接触日、関連案件など複数の情報を確認した後で、結合用IDを付けます。

架空の工務店例006では、次の判定ルールを仮置きします。これは法的基準やCRM製品の仕様ではなく、架空例における作業ルールです。

強い一致条件でも「自動結合」ではなく「候補化」にとどめています。取り違えによる影響は、重複が一時的に残る不便より大きくなることがあるためです。

同一人物だと判定しても、片方の行を丸ごと残すだけでは不十分です。電話番号はA行が新しく、担当者はB行が正しく、来場履歴は両方にあるかもしれません。項目ごとに採用元を決め、採用しなかった値も必要に応じて訂正履歴へ残します。

採用値の優先順位を「最終更新日が新しい方」だけで決めないようにします。誤入力が最近行われた可能性もあるからです。本人から確認した記録、契約などで確定した資料、担当者が根拠を記録して更新した値など、自社で採用根拠を定めます。

家族を一件へまとめるか、個人別に登録するかも先に決めます。営業上は世帯単位で追いたくても、連絡先、案内の可否、相談内容、担当者が個人別に異なることがあります。CRMに世帯や関連人物の機能がなければ、主連絡者と同居家族の表現方法を項目対応表へ追加します。

案件も名寄せと同時に潰してはいけません。同じ顧客が「自宅の新築」と「実家のリフォーム」を相談しているなら、顧客は統合しても案件は二つ残します。顧客重複と案件重複を別の判定列にすることで、誤結合を防ぎやすくなります。

判定を保留した候補は、無理に本番前に結合しなくてもかまいません。別レコードのまま「重複候補あり」と記録し、業務上の影響と確認期限を管理するほうが安全な場合があります。

07.ステータスは正本の9区分へ合わせ、OBは顧客区分へ分ける

顧客情報が整っても、商談の現在地が担当者ごとに違う意味で記録されていれば、CRMは引き継ぎに使えません。「見込み」「追客中」「濃厚」「A客」といったラベルが、行動や事実ではなく担当者の感覚で付いている場合は、移行前に再判定します。

ステータスは、工務店の商談ステータス｜担当者で判定がぶれない定義で定義する次の9区分へ統一します。

• 受付
• 接触中
• 面談設定済み
• 条件確認中
• 提案中
• 契約手続中
• 受注
• 長期保留
• 失注・終了

移行作業で別名の中間ステータスを増やすと、正本の記事とCRM上の分類が並立します。「初回対応済み」「継続相談」「提案提示済み」「引渡し済み」などを新ステータスとして追加せず、必要な事実は活動履歴、基準日、顧客区分、引渡日などの別項目へ記録します。

特に「提案中」は、「顧客へ提案を提示済み」という意味へ読み替えてはいけません。正本で定めた提案着手条件を満たした時点の区分として扱い、提示の有無や提示日は活動履歴で確認します。

新ステータス候補の列には、正本で定義した9区分だけを使用しています。「要確認」はステータスではなく、移行前整備台帳の処理状態です。「OB施主」もステータスではなく顧客区分です。

この分離により、OB施主から新しいリフォーム相談を受けた場合も、顧客区分は「OB施主」のまま、新しい案件を「受付」から管理できます。一人の顧客に対する関係性と、個別案件の進行状態を混同しません。

ステータス変換では、旧ラベルだけでなく根拠日を確認します。たとえば「提案中」と書かれていても、提案着手を示す記録がなく、面談日だけが確定しているなら、旧ラベルを優先してはいけません。反対に、提案資料の作成記録と担当者の更新記録が残っていれば、正本の条件に照らして判定できます。

活動履歴は、すべての文章を一つの長いメモへ結合するより、日付、活動種別、担当者、要点、次回行動へ分けたほうが追いやすくなります。ただし、元の記録にない日付や活動種別を推測してはいけません。

履歴量が多い場合は、次の三案を比較します。

1. 全期間の履歴を構造化して移す 2. 一定期間または進行中案件の履歴だけ構造化する 3. 現在地と主要履歴だけ移し、古い履歴は原資料を参照できるようにする

選択基準は、日常業務で検索する必要性、引き継ぎへの影響、変換精度、原資料へ戻れるかどうかです。単に古いという理由だけで捨てたり、残せるという理由だけで全件を長文メモへ詰め込んだりしません。

架空の工務店例006では、進行中案件とOB対応中の案件について、基準日時点の状態、直近の主要接点、次回対応を構造化して移します。それ以前の細かな履歴は、必要性を確認したうえで原資料の参照先をCRMへ記録します。これは架空例の運用案であり、すべての工務店に同じ範囲を推奨するものではありません。

次回対応日が過去日になっていても、自動的に未来へずらしてはいけません。未対応なのか、対応済みだが記録が漏れたのか、長期保留または失注・終了へ変わったのかを担当者へ返します。期限切れはデータ不備であると同時に、実際の対応漏れを発見する入口です。

08.変換ルールと例外を「移行前整備台帳」にまとめる

ここまでの判断を、複数の会議メモや担当者の頭の中へ分散させないために、移行前整備台帳へ統合します。この台帳が本記事の成果物です。完成後は、データ修正の作業指示、テスト結果の記録、差分取込、本番可否の判断にも使えます。

台帳は一枚の巨大な表にしても、目的別のシートに分けてもかまいません。重要なのは、対象、項目、変換、重複、例外、検証が同じ管理番号でつながることです。架空の工務店例006では、次の六つのシートに分けます。

この構成から読み取るべきなのは、要確認データを通常行の空欄へ埋没させないことです。判断できないものを独立した一覧へ出せば、担当者への返却、期限設定、暫定処理、未解決のまま進める判断が可能になります。

値変換シートには、少なくとも次の項目を持たせます。

• 元データID
• 対象列
• 旧値
• 新値
• 適用条件
• 変換理由
• 変換種別
• 作業者
• 確認者
• 適用日

たとえば「HP」を「Webサイト」へ統一する場合でも、旧表によって意味が違う可能性があります。全ファイル共通の置換にせず、元データIDや対象列を条件に含めます。

自由記述の一括置換は特に慎重に扱います。「なし」を空欄へ変換する処理が、備考文中の「駐車場なし」まで消すことがあるためです。列全体の完全一致を対象にするのか、文字列の一部も置換するのかを明記します。

例外・要確認シートには、問題の種類だけでなく業務への影響を付けます。担当者不明で進行中なら切替前の解決優先度は高く、古い資料請求者の流入経路が不明なら、例外として残したまま移行できる場合があります。

優先度を件数だけで決めると、少数でも重大な問題を後回しにします。「検索できない」「別人を結合する恐れがある」「次回対応が失われる」「不要な利用者へ表示される」「利用目的の確認が必要」といった影響から順序を決めます。

移行前整備台帳の最小記入例は次の形です。

この表が示すのは、修正結果だけでなく「なぜそうしたか」を残す必要性です。後から問い合わせがあったとき、変換前の値、判断者、根拠へ戻れるようにします。

台帳には作業者と承認者も分けて記入します。全件を一人が二重確認する必要があるとは限りませんが、名寄せ、連絡可否、失注・終了、別人の結合、閲覧範囲など影響の大きい判断は、作業者だけで確定しない運用を検討します。

未解決事項は「残っているから失敗」ではありません。次の四点がそろっていれば、影響を管理したうえで本番後に解決できるものもあります。

• 担当者
• 確認期限
• 暫定処理
• 未解決のまま進めた場合の影響

ただし、別人の結合、進行中案件の担当欠落、必要な利用者がログインできない、不要な利用者へ情報が表示されるといった問題は、原則として切替前に解決する停止条件へ置きます。

09.本番前に小さく取り込み、件数と内容を別々に照合する

全件の整備が終わるまでCRMへ一度も入れない進め方は、後半で仕様の不一致が見つかる危険があります。項目対応の骨格ができた時点で、少量のテストデータを取り込み、文字、日付、選択肢、関連付け、検索、権限などを確認します。

テスト対象は、きれいなデータだけを選びません。通常例に加え、同姓同名、家族共用の電話番号、法人顧客、担当者不明、日付欠損、複数案件、長い自由記述、旧ステータス「OB」、使用できない文字を含む可能性のある行などを入れます。

架空の工務店例006では、2,600件のうち100件をテスト対象にします。100件は推奨値ではなく、架空例の条件です。内訳は通常例50件、重複候補15件、OB施主10件、複数案件10件、欠損や例外15件とし、合計は50＋15＋10＋10＋15＝100件です。

割合だけで抽出すると、まれな例外がテストへ入らないことがあります。無作為抽出と条件指定を組み合わせ、日常的なレコードと壊れやすいレコードの両方を確認します。

この模式図の要点は、画面上で数件を眺めて終わらず、エラーを変換ルールへ戻すことです。一件だけ画面で直すと、本番取込で同じ問題が再発します。

検証は、件数検証、項目検証、関連検証、業務検証に分けます。

件数一致は検証の一部にすぎません。100件が100件入っていても、顧客と案件の関連が外れたり、担当者が別人へ置き換わったりすれば業務には使えません。

件数を比べるときは、分母と除外条件を固定します。たとえばテスト元100行のうち、判定済み重複5行を統合し、対象外3行を除くなら、顧客レコードの期待件数は「100－5－3＝92件」です。ただし、複数案件があるため、案件件数や履歴件数は別に計算します。

エラー率を使う場合も、何を分母にしたかを書きます。取込対象100行のうち8行がエラーなら、行単位の取込エラー率は「8÷100×100＝8％」です。8人の顧客が失われたとは限らないため、「行」「顧客」「案件」「履歴」を混同しません。

重要項目の内容照合は、全件か抽出かを決めます。進行中案件の担当者、ステータス、次回対応日は全件照合し、過去の資料請求者の流入経路は抽出照合にする、といった差を付けられます。抽出する場合は、対象期間、件数、抽出条件を記録します。

テスト環境やCRM上のテストデータを削除または上書きするときは、先に対象を確定します。本番データと同じ環境を使う場合は、テスト識別子を付け、通知、担当者への自動割当、メール配信、外部連携が動かないかも確認します。誤作動の恐れがある場合は、取込を開始せず、停止方法を確認してからテストします。

10.切替日は差分、停止条件、戻し方まで決める

本番切替では、全件取込の日時だけでなく、旧表の更新をいつ止めるか、基準日後の差分を誰が回収するか、どの条件なら切替を延期するかを決めます。技術的に取込が完了しても、担当者が新CRMへ入れなければ業務は始まりません。

完全な並行運用を長く続けると、旧表とCRMの両方が更新され、どちらが正しいか分からなくなります。並行期間を置くなら、両方へ同じ内容を入力するのではなく、「旧表は参照のみ」「新規更新はCRM」「移行漏れは専用台帳へ報告」のように役割を分けます。

架空の工務店例006では、金曜日18時に旧表の通常更新を止め、同日中に最終差分を抽出します。土曜日に本番取込と検証を行い、月曜日9時からCRMへの入力を開始する計画です。これは日程例であり、休日作業を一般的に推奨するものではありません。自社の勤務体制、顧客対応、CRM提供事業者の支援時間に合わせます。

切替判定表には、開始条件と停止条件を並べます。

この表から読み取るのは、停止条件を「エラーがゼロでないとき」と曖昧にしないことです。古い流入経路の欠損と、進行中顧客の担当欠落では影響が違います。切替を止める問題、切替後に補完できる問題、移行対象外として受け入れる問題を分けます。

本番取込に失敗した場合は、慌てて同じファイルを再投入せず、次の順序で確認します。

項目形式のエラーなら変換ルールを直して再取込します。途中まで登録された場合は、再取込による重複の危険を確認します。顧客、案件、履歴の関連が崩れた場合は、取込順と結合キーを見直します。

個別レコードだけを画面上で直すと、再取込時に上書きされる可能性があります。まず取込ファイルと台帳を修正し、その修正版を正として反映するのが基本です。ただし、緊急の顧客対応に必要な暫定修正は、対応を止めない範囲で行い、同じ変更を台帳と取込元へ戻します。

切替直後は、問い合わせ受付、担当割当、商談更新、次回対応登録、顧客検索という主要操作を実際の担当者が行います。操作説明を聞いたかではなく、自分の権限で必要な作業を完了できるかを確かめます。

問い合わせを受けたのにCRMへ登録できない場合の一時記録先も決めておきます。個人メモや口頭連絡へ戻ると、復旧後の回収が困難です。障害時台帳に受付時刻、顧客を識別するために必要な情報、対応内容、担当者、CRM反映状況を記録し、復旧後に責任者が消し込みます。

11.移行後は旧表を閉じ、記録ルールを通常業務へ渡す

移行後に起きやすい問題は、旧表がそのまま更新され続けることです。CRMに足りない項目がある、検索方法が分からない、入力が面倒、以前の表のほうが慣れている、といった理由で担当者が戻ります。これは意識だけの問題ではなく、移行設計、操作準備、画面設定の不足を示す信号です。

旧表を参照用として残すなら、ファイル名や冒頭に「更新停止日」「現在の正本はCRM」「修正先」を表示します。編集権限を外せる環境では、必要な閲覧者を確認したうえで参照専用にします。削除するかどうかは、保存の必要性、社内規程、契約、利用目的、適用される法令などを確認して判断します。

移行後の最初の点検では、単なる登録件数より、実務がつながっているかを見ます。

• 新規問い合わせが担当者へ渡ったか
• 進行中案件に正しいステータスと根拠があるか
• 次回対応の期限と内容が登録されているか
• 担当変更後も必要な履歴を読めるか
• OB施主が顧客区分として登録されているか
• 旧表へ新しい更新が書き込まれていないか
• 不要な利用者に情報が表示されていないか

架空の工務店例006では、稼働開始後の最初の5営業日は毎日、次の四点を確認します。

1. 前営業日の新規問い合わせがすべて登録されているか 2. 担当未割当のまま残る進行中案件がないか 3. 期限を過ぎた次回対応に理由が記録されているか 4. 旧表へ新しい更新が書き込まれていないか

5営業日という期間は架空例です。問い合わせ件数が少ない会社では、日数ではなく「新規登録が20件に達するまで」のように観察単位を決めてもよいでしょう。その場合も、20件中何件で入力差戻しがあったかなど、分母を明記します。

入力差戻し率を確認するなら、たとえば新規登録20件のうち必須項目の誤りで4件を差し戻した場合、「4÷20×100＝20％」です。この値だけで良否を決めず、同じ項目で繰り返しているかを見ます。説明不足、選択肢不足、画面配置、責任分担のどれが原因かを分けます。

運用開始後に項目を追加したいという要望も出ます。その場で増やすのではなく、次の条件を確認します。

• 誰が、どの判断に使うか
• 既存項目や活動履歴では代替できないか
• どの接点で取得できるか
• 入力者と更新時点を決められるか
• 過去データを埋め直す必要があるか
• 閲覧範囲や保存方法を変更する必要があるか

逆に、誰も使わない項目は減らします。移行時に慎重を期して残した項目でも、検索、引き継ぎ、集計、顧客対応のどれにも使われなければ、入力負担だけが残ります。削除や非表示を判断する際は、他の業務や資料から参照されていないかを確認します。

最後に、移行前整備台帳を完成させます。完成とは未解決がゼロという意味ではありません。未解決事項が、担当者、期限、暫定処理、業務への影響とともに管理されている状態です。

自社で残す成果物は、次の一式です。

1. データ棚卸し表 2. 移行対象・参照保管・対象外の判断記録 3. 原本の抽出記録と差分台帳 4. 項目対応表 5. 値変換ルールと修正履歴 6. 重複候補・名寄せ判定表 7. ステータス再判定と顧客区分の分離記録 8. 例外・要確認一覧 9. テスト移行と本番移行の検証記録 10. 切替条件、停止条件、復旧手順、障害時台帳 11. 更新を止めた旧表と変更していない原本 12. 稼働後の入力・点検ルール

この一式がそろえば、移行作業を特定の担当者の記憶から切り離せます。別のCRMへ変更する場合や担当者が交代する場合にも、何を正として、どのように変換し、どこに例外が残ったかを説明できます。

表計算からCRMへの移行で避けるべきなのは、古い表の曖昧さを新しいシステムへそのまま移すことです。先に完了条件、対象、正本、項目、重複、状態、履歴、例外を整え、利用目的と閲覧範囲に疑問がある記録は確認経路へ分けます。そのうえで小さく取り込み、件数と業務の両方を照合してから切り替えれば、CRMは単なる保存先ではなく、次の行動を引き継ぐ道具になります。