工務店・ハウスメーカーのCRMの選び方 入力項目・検索・権限・移行を実務で比較する

CRMは、機能の一覧ではなく、「自社の重要な業務を、候補の製品で最初から最後まで再現できるか」で選びます。顧客情報をまとめられても、次に連絡する相手を探せない、担当が替わると約束が伝わらない、解約するときに履歴を取り出せないのでは、困りごとは残るからです。

進め方は三段階です。まず、いまの困りごとがCRMで解決する種類のものかを切り分けます。次に、自社の業務から要件と合否の基準を作ります。最後に、同じ架空データを全候補に入れ、登録、検索、担当変更、権限、出力、移行までを同じ手順で試します。この記事では、そのために作る表を順に示します。

会社、人物、顧客、日付、件数は、断りのない限りすべて説明用の架空例で、実在企業の運用実績でも、特定製品の検証結果でもありません。製品の仕様と料金は各社の最新資料と契約条件で、個人情報の扱いと保存期間は自社の管理責任者や専門家と確かめてください。

01.先に、CRMで解決する問題かどうかを切り分ける

「顧客管理を効率化したい」のままでは、製品の説明を聞いても自社に合うかを判断できません。実際に困った場面を一つ取り上げ、何が足りなかったのか、誰の仕事が止まったのかを書き出します。困りごとは、情報がない、更新されない、検索できない、引き継げない、の四つに分かれます。

原因が入力場所や担当の曖昧さなら、表計算や今の道具の使い方を直せば足りることがあります。共有する担当者が限られ、入力場所が一つで、必要な検索と引き継ぎを表計算でできるなら、先に列名をそろえ、担当者、次回行動、期限を入れて、不在の人の案件を別の人が確かめられるかを試します。それでも、同時編集で変更がぶつかる、見せる範囲を分けられない、履歴が上書きされる、毎回手作業で対象者を抜き出している、といった制約が残るなら、その制約がCRMの必須要件になります。現状維持も、直す手間と残る負担を含めた比較の対象です。

CRMに入れる範囲も決めます。問い合わせ元、検討状況、接触履歴、担当者、次回行動は候補ですが、図面の版、工事原価、契約書の原本までCRMに集めるかは別の判断です。今の管理先を正本として残し、CRMには参照先と確認担当者だけを書く方法もあります。法的な判断や建物の安全に関わる結論を営業のメモだけで確定させず、担当者が元の資料に戻れるようにしておきます。

経営者が見たい集計と、現場が入力できる情報がずれることもあります。流入経路別の状況を知りたくても、初回接客の時点では詳しいことが分かっていません。項目を増やす前に、「どの会議で、どんな判断に使うか」「いつなら正確に分かるか」を確かめます。最初に知った媒体と、今回問い合わせた窓口は別の情報です。本人に確かめられないことは推測で埋めず、集計する側が「未確認」という区分を受け入れます。使わない集計や細かすぎる分類を経営側が減らすことも、調整の一つです。

導入の目的は、試用の結果を見て合否を言える言葉に直します。

直した目的には確認する人を付けます。誰も合否を判断できない目的は、まだ具体化が足りません。

02.自社の業務から、要件と合否の基準を作る

候補各社の説明資料に合わせて評価表を作ると、紹介された機能だけが比較の対象になります。先に自社の表を作り、製品の説明はその空欄を埋めるために聞きます。

出発点は、問い合わせが届いてから誰が読み、どこへ写し、誰に対応を頼んでいるかという、実際の受け渡しです。紙、メール、個人のメモなど、情報が途中で止まる場所も書きます。受け渡しは入力で終わりではありません。受付担当が登録しても、営業担当が割り当てに気付かなければ対応は始まらないので、次の人が受け取ったと分かるところまでを一行にします。

表の一行を現場の担当者に説明してもらうと、実際には別の人が補っている作業が見つかります。商談が進まなくなった案件の扱いも書きます。顧客が検討を続けながら時期を待っているなら保留、案件を終えると確かめられたなら失注、と自社の定義で分け、返事がないだけで失注にするかどうかを担当者個人の判断に任せません。

引き継ぎの弱いところを探すには、担当者がいない状態を想定します。別の担当者が記録だけを読んで、「最後に何を約束したか」「次に誰が何をするか」「連絡してよい方法は何か」を答えられるかどうかです。足りないものが見つかったら、長い引き継ぎ文書を足す前に、普段の履歴や行動の欄で書けないかを考えます。休職中の一時的な代行と、退職による担当の変更は分けて、案件の担当、未完了の行動の担当、通知先、アクセス権をそれぞれ確かめます。

必須・希望・対象外に分ける

要件には、使う場面、確かめ方、合格の条件、確認者、根拠を付けます。必須要件は、満たせなければ重要な業務が成り立たない条件。希望要件は、なくても承認済みの代わりの手順で回せる条件。対象外は、今回は評価しない範囲です。すべてを必須にすると、優先順位が見えなくなります。

その機能が標準なのか、追加の設定、別契約、手作業での補完なのかも分けて書きます。必須と希望を入れ替えたときは、理由と承認した人を残します。

試して確かめることと、書面で確かめること

検索の結果や入力のしやすさは、試用で確かめます。契約終了後にデータを取得できる期限、サービス側のバックアップの範囲、追加費用は、画面を触っても分かりません。契約書、仕様資料、書面の回答で確かめる項目として分けます。根拠の欄には、資料名、該当箇所、確認日、対象のプランを書きます。デモで見た機能が、契約する予定のプランで使えるとは限りません。回答が口頭だけ、将来対応の予定、試用環境では未確認、といった状態はそのまま残し、「説明を受けた」と「自社の条件で動作を確かめた」を同じ印にしません。

使いやすさは、作業を決めて観察します。新規の問い合わせ登録なら、入力の開始から保存後の確認までを同じ範囲とし、かかった時間、画面の移動、迷った箇所、やり直した回数を記録します。説明を受けている時間や通信待ちを含めるかも、候補間でそろえます。速さだけでなく、必要な情報が残ったか、誤入力に気付けたか、次の担当者に伝わったかを見ます。デモ担当者の慣れた操作と、初めて触る自社の担当者の操作は別の記録にします。許容する時間や手順の数は、今の業務を基準に自社で決め、他社の目安をそのまま合格の線にはしません。

費用の比較には、利用料以外の作業を入れます。初期設定、項目の整理、データ移行、教育、問い合わせ対応、定期点検、解約時の出力、次のシステムへの再移行です。社内の作業は「担当者数×一人当たりの作業時間」で人時にそろえ、初期の作業と毎月の作業を足すときは、評価する利用期間を候補間で同じにします。金額に直すなら、使った社内単価を明記し、実際に支払う費用とは分けます。追加機能、容量、支援の範囲、契約更新の条件は、候補ごとの見積書で確かめます。

03.入力項目は、次の行動に使うものに絞る

項目を増やせば分析が進むわけではありません。何の判断に使うか、いつ分かるか、誰が更新するかを説明できる項目だけを残します。入力項目台帳は、入力欄の一覧ではなく、情報を使う目的と管理の責任を決める表です。項目の絞り方そのものは顧客管理項目の記事で扱っています。

まず、顧客、案件、行動、履歴を分けます。顧客は「誰とやり取りするか」、案件は「何を検討しているか」、行動は「次に誰が、何を、いつまでにするか」、履歴は「いつ何があったか」です。一つの自由記入欄にまとめると、新しい相談が来たときに前の経緯を上書きしてしまいます。たとえば顧客C001に新築の相談P001があり、後から別の物件の改修の相談P005が加わった場合、連絡先は顧客に、検討内容と担当は案件に持たせ、相談ごとの履歴を分けて追えるかを確かめます。家族の連絡先も、本人、同席者、連絡の窓口を混ぜずに記録します。氏名や住所が同じというだけで、別の人や別の案件を一つにしない設計にします。「担当者」も、顧客の主担当、案件の担当、次回行動の実行者が同じとは限りません。

台帳には必須か任意かの区分も足します。必須にするのは、次の対応を安全に引き渡すのに要る情報です。受付の段階では、相手を識別できる情報、相談の概要、割り当て先。初回対応の後に、接触の結果と次回行動、という形が考えられます。予算や土地の状況を初回登録で必須にすると、分かっていないのに仮の値が入り、後の集計を狂わせます。「不明」「未確認」「該当なし」を区別し、空欄をなくすためだけの入力はさせません。登録を止めるべき不足と、後から確かめればよい不足を分け、試用で両方の動きを見ます。匿名の問い合わせや連絡先が分からない問い合わせをどう扱うかも、業務として決めておきます。

連絡の希望と停止は、状態とは別の欄に持つ

連絡の希望は「平日夕方は電話可」「資料はメール希望」のように、方法と条件を分けて残します。停止の意思を受けたときは、受けた日時、経路、対象の範囲、記録した人を残し、次の担当者が検索と一覧で分かるようにします。顧客全体に持たせるのか、案件ごとに持たせるのかも決めます。

意思が曖昧な場合は、担当者の解釈を確定の情報として扱いません。案内の停止と、既存の契約に関わる必要な連絡の扱いは、社内の方針と専門家への確認を踏まえて決めます。確認と記録の方法は連絡希望の確認で扱っています。

ステータスは進行、タグは属性

ステータスは案件がいまどこにあるか、タグは属性や関心の分類です。「対応中」と「平屋に関心」を同じ選択肢に並べると、進み具合と関心を同時に集計できません。次は試用データで使う簡略な状態の例です。名前と段階の数は自社の業務に合わせます。状態の決め方は商談ステータスの記事で扱っています。

状態には、名前だけでなく、入る条件と出る条件を決めます。保留には理由と再開の条件を、失注には終わったと判断した根拠を残します。連絡が取れないことと、他社への依頼が決まったことは同じではありません。期限を置けない保留に形だけの日付を入れず、「条件待ち」として抜き出せるかを見ます。状態を変えた日時と理由を後から見られるかも、試用で確かめます。

連絡の停止と再連絡の希望は、状態とは別の軸です。「保留だから連絡しない」「対応中だから連絡してよい」と状態だけで判断すると、停止の意思を見落とします。状態を変えても意思の記録が消えないか、同じ顧客に複数の案件があるときに、全体への停止と特定の案件だけの条件を書き分けられるかを確かめます。記録どうしが食い違っていたら、都合のよいほうを採らず、確認の対象として止めます。

タグは、平屋への関心、土地探し中、見学会参加など、検索に使う分類です。参加日で抜き出したいなら、タグより参加の履歴と日付のほうが合います。自由入力を無制限にすると「平屋」「ひらや」「平屋希望」に分かれるので、名前、定義、付ける条件を一覧にし、追加は管理担当者が確かめます。本人が話した関心と、担当者が推測した関心は同列にしません。「見込み大」のような感覚の言葉も、次回の約束があるかどうかといった確かめられる事実とは分けて扱います。家族や資金に関する詳しい情報は、取る必要があるかと、誰に見せるかを慎重に決めます。タグを付けられるからといって、使い道のない個人情報を増やさないようにします。

項目を追加したい人には、使う判断、入力できる時点、更新の責任者、検索や集計での使い方を書いてもらいます。「後で使うかもしれない」だけなら、今ある項目で足りないかを先に見ます。見直しは入力率だけで決めません。全部埋まっていても、検索にも会議にも顧客対応にも使われていない項目は負担です。逆に、使う頻度が低くても、引き継ぎや管理に要る項目は残します。廃止するときは、保存済みの検索、帳票、外部連携、過去の集計への影響を調べてからにします。

04.同じ架空データを入れて、全候補を同じ手順で試す

候補ごとに違うデータを使うと、結果を比べられません。同じデータを、同じ順で操作します。登録だけで終わらせず、履歴の追加、次回行動、担当変更、検索、出力までつなげると、途中で情報が欠ける場所が分かります。実在の顧客の情報や写真は持ち込みません。外部への送信や通知が起きる操作は、試用環境の仕様を確かめ、社内で管理するテスト用の宛先に限ります。

共通データには、正常な案件だけでなく、停止の希望、期限の未設定、担当の不在を入れます。検索の期待結果を先に決められる量に絞ります。

検索の基準日は2026年10月10日とします。顧客の氏名は「試用顧客A」のような架空の名前にし、実在しそうな電話番号は作りません。この表を原本として保管し、候補間で初期状態がずれないようにします。

P001を最初から登録する流れでは、操作のたびに、何が残れば合格かを決めておきます。クリックできたことと、業務に要る記録ができたことは別です。

担当変更では、案件の担当者名のほかに、行動の実行者、通知先、担当別の一覧、見られる範囲がどう変わるかを見ます。過去の履歴に残っている対応者の名前まで、後任に書き換わっていないかも確かめます。後任の役の人に、「直近の約束」「次の作業」「連絡の条件」を記録だけから説明してもらい、前任の役の人が口で補わないと分からなかった点は、そのまま課題として残します。情報はあるのに複数の画面を探し回る場合は、一覧の列や並び順の設定で直るかを確かめ、直ったなら、その設定の作業も導入の負担に数えます。

この流れを終えたら、次の検索テストの前に原本の状態へ戻し、戻したことも記録します。前の操作の結果が、次の試験に混ざらないようにするためです。

例外も試します。結果を切り分けられるよう、原本の複製か追加のレコードで行い、削除や統合を伴う操作は、試用環境でも元に戻せる条件を先に確かめます。

製品の側で対応できない場合は、手作業で補う方法と実行する人まで書きます。その手順を現場が続けられるかも評価に入れます。

デモでは実現の方法を教わり、その後に自社の担当者が、普段使う端末と、想定している権限で操作します。管理者しか使えない操作を、営業担当の使いやすさとして数えないためです。記録には、操作した人、端末、権限、説明を受けたかどうか、結果、困った点を残します。試せなかった機能は、資料で確かめた部分と未確認の部分を分け、候補各社に同じ追加の質問を送ります。

05.検索は、期待するIDを先に書いて照合する

「検索できます」という説明だけでは足りません。条件の組み合わせ方、空欄の扱い、案件と顧客のどちらで数えるかが違えば、欲しい一覧にならないからです。営業担当と責任者が普段取り出したい一覧を挙げ、一覧を見た後にすることが決まる検索から先に試します。条件を書き、期待するIDを先に決めます。データは原本の状態、基準日は2026年10月10日です。

件数が合っていても、対象が入れ替わっていることがあります。期待したIDと実際のIDを照らし、入るべき対象と、外れるべき対象の両方を見ます。案内を止めているP004が案内候補に入ったら、件数に関係なく条件を見直します。最終接触日が古いというだけで連絡の対象にせず、連絡の希望と停止を別に確かめます。期限の未設定は、期限超過と混ぜずに、別の不足として取り出します。

日付の条件は境目で差が出ます。「より前」と「以前」の違い、時刻とタイムゾーン、空欄の扱いです。接触状況の点検では、最終接触日がちょうど10月1日のP001が外れることを確かめます。基準日当日が期限のレコードを足せば、期限超過の境目も確かめられます。一覧が案件単位か顧客単位かも記録します。同じ顧客に案件を足したときに何行になるかを見ておくと、集計と出力での数え違いを防げます。

一覧の列は、検索の目的に合わせます。期限超過の確認なら、案件ID、顧客の表示名、担当者、次回行動、期限、連絡の条件です。並び順は、期限の古い順や担当者順など、作業を進める順にします。長い行動内容が途中で切れても確かめやすいか、スマートフォンでも読み違えないかも試します。個別の画面を開かないと判断できない項目があれば、開く回数も負担として記録します。見やすさのために、要らない個人情報まで一覧に広げることはしません。

検索条件を保存できるなら、個人用、チーム用、全社用のどの範囲で共有できるかを見ます。共有した検索でも、見る人の権限によって結果が変わるかを試します。検索を共有することと、全データを見せることは別です。「今日」「今月」という条件が毎回動くのか、保存した日の日付で固定されるのか。「担当者本人」という条件と、特定の担当者名を指定した条件の違いも確かめます。保存した条件を誰が変えられるか、誤って変えたときに戻せるかも見ます。

重複の検出は、氏名の表記違い、電話番号の書式違い、同じ世帯を分けて試します。似た情報を見つけることと、同じ人だと決めることは別で、決める前に両方の案件、連絡先、履歴、停止の情報を見比べられる必要があります。統合の後は、残るIDと消えるID、案件との関係、履歴、添付ファイル、担当者、連絡の条件を確かめ、食い違う値のどちらを残すか選べるか、統合を取り消せるかを質問します。連絡の停止が消えてしまう統合は、ただの重複整理として扱えません。判断がつかないものは候補のまま止め、確認の責任者に回します。

06.権限と操作履歴は、役割別のアカウントで確かめる

権限は、役職ではなく、仕事に要る操作から決めます。閲覧、編集、削除、出力、設定変更を分け、営業担当、広報担当、管理者、外部の協力者がどこまで扱うかを整理します。次は話し合いの出発点にする記入例で、どの会社にも当てはまる正解ではありません。閲覧と保管の考え方は顧客情報の扱いで扱っています。

機能の名前ではなく、契約する予定のプランでどの単位まで制御できるかを確かめます。顧客単位、案件単位、項目単位の制限が要るなら、役割別のアカウントを実際に作り、許可した操作ができることと、許可していない操作ができないことの両方を試します。

出力の権限は、画面の閲覧とは別に見ます。一覧では一部の項目しか見えない担当者が、CSVでは全項目を取れるなら、想定と違います。検索結果の出力、全件の出力、帳票、連携機能による取得を分けて質問します。項目の追加、必須条件、選択肢、権限の付与を誰が変えられるかも確かめます。設定を変えると検索結果や外部連携に響くので、変える前の確認と記録を運用に入れます。制限できない操作があるなら、その理由と代わりの手順を書き、権限を広げたまま使うことを合格にはしません。

退職や委託の終了を想定して、テスト用のアカウントを停止し、もう一度ログインできないことを確かめます。すでにログインしている端末、モバイルアプリ、発行済みの連携用の認証情報がどうなるかは、仕様資料と試用の両方で見ます。停止した後も、過去の対応者名と履歴を追えるか、担当していた案件が責任者の一覧に残るかも確かめます。アカウントの削除と停止は結果が違うことがあるので、同じ操作として扱いません。外部の協力者には、利用の期限と確認の責任者を付けます。休職の場合は、一時的な停止、担当の代行、復帰したときの再設定を整理します。

変更履歴は、誰が、いつ、何を、どの値からどの値に変えたかまで見られるかを確かめます。対象が顧客情報だけなのか、担当者、行動の期限、連絡の停止、権限の設定にも及ぶのかを分けて質問し、期限の修正と停止情報の更新を実際に行って、履歴の見え方を確かめます。削除したデータの操作記録が残るか、その記録を誰が見られるか、いつまで見られるかも確認事項です。履歴の機能があるというだけで、事故の原因を特定できるとは考えず、自社が追いたい操作をどこまで追えるかを評価表に書きます。

管理者が一人だと、その人がいないときにアカウントの停止や誤った設定の修正が進みません。増やせば、強い権限を持つ人が増えます。主担当と代わりの担当を決め、共用のアカウントは避けます。誰が操作したかを区別しにくくなるからです。端末の紛失、認証情報の漏えい、誤った出力が起きたときの社内の連絡先と、サービス側の問い合わせ先も整理しておきます。個別の法的な適否やサービスの安全性は、この権限表だけでは判断できません。管理責任者が最新の資料と契約条件で確かめます。

07.通知と自動処理は、止まるかどうかを試す

通知や自動処理は、うまく動く場面だけでは評価できません。条件が変わった、担当者がいない、連携先が止まった、顧客から停止の希望が届いた。そのときに誰が気付き、どこで止められるかを試します。社内の作業の通知と、顧客に届く連絡は分けて考えます。

通知は「次に動くのは誰か」から決めます。新規の問い合わせは割り当てを受けた担当、期限超過は行動の担当と確認の責任者、連携の失敗は管理担当です。全員に同じ通知を送ると、誰が対応するのかが曖昧になります。通知を読んだことと、作業が終わったことは別なので、未対応の一覧で結果を確かめられるかを見ます。通知を増やす前に、未完了を確かめる場所を決めます。メールや外部への通知にどこまで個人情報を載せるかも、社内の方針で決めます。

自動処理は、対象になる条件に加えて、対象から外れる条件を書きます。状態が変わった、別の担当がすでに対応した、連絡の停止が登録された。そのときに、予約済みの処理に反映されるかを確かめます。流れは「条件に当てはまる、連絡の条件と重複対応を確かめる、問題がなければ承認する、実行する、結果を記録する」で、途中に停止や食い違いがあれば実行を止めて責任者に回します。実行に失敗したときは、処理の状況を確かめてから再実行します。製品がこの流れのどこまでを担い、どこが手作業になるかを書き出します。条件の判定が予約の時点だけなのか、実行の直前にも行われるのかは、停止の希望に間に合うかどうかを左右します。

顧客に案内を送る処理では、対象、宛先、文章、添付、送信の予定日時を確かめる手順を置きます。試用では社内のテスト用の宛先を使い、確認者が差し戻したときに送信が止まるか、直した後に再び承認が要るかを見ます。一人の顧客に複数の案件がある場合や、二人の担当者が同時に操作する場合に、二重に実行されないかも質問します。承認の機能がないなら、運用で補えるかを業務量を含めて判断します。まだ確かめていない送信の機能を前提に、手順だけを完成させないようにします。

担当者がいないときは、代わりの担当に通知が届くだけでなく、その人が案件を開いて編集できる権限を持っているかを確かめます。連携の失敗では、未処理、処理済み、結果不明を区別できるかを見ます。結果不明のまま再実行すると、重複登録や二重の対応になります。連携を止めて手入力に切り替えた場合に、復旧後に同じ情報が二度入らない照合の手順も用意します。

停止の希望は、登録画面だけでなく、保存済みの検索、予約済みの連絡、外部の連携先、すでに出力した一覧に及びます。共通データのP001を案内停止に変え、どこに反映され、どこに手作業が要るかを記録します。出力済みのファイルには、CRMの中の更新が反映されるとは限りません。使う直前に最新の条件で対象を出し直す、古い一覧を使い回さない、という扱いを決めます。反映に遅れがあるなら、その間の処理を止める方法まで含めて評価します。

08.出力とバックアップは、実物のファイルで確かめる

画面に見えている情報が、必要な形で取り出せるとは限りません。出力したファイルと帳票は実際に開き、列、件数、内容、データどうしの結び付きを見ます。経営会議で使う一覧と、別のシステムに移すためのデータでは、要る内容が違います。

出力の目的ごとに、単位、期間、必要な列を決めます。案件の一覧なら、案件ID、顧客ID、担当者、状態、流入経路、次回行動。履歴なら、履歴ID、案件ID、日時、対応者、内容です。氏名だけで結び付ける形式は、同姓同名や表記の変更に弱くなります。期間の条件も、問い合わせ日、最終接触日、状態を変えた日では意味が違います。帳票の数字は、何を一件と数え、どの日付で区切り、どの状態を含めたかを明記し、案件数を顧客数として読まないようにします。

履歴を一行ずつ出す形式なら、一つの案件が複数の行になります。ファイルの行数と案件数が合わないこと自体は異常ではないので、出力の単位を確かめてから判定します。合わない点が出たら、設定で直るのか、仕様として取れないのかを分け、出し直したときは条件と変えた箇所を記録します。

代表データには、日本語、長い文章、文中の改行、カンマ、引用符、先頭がゼロの識別子を入れます。文字コードと区切り文字を確かめ、使う予定の表計算ソフトで読み込みます。開いた時点で日付や番号が自動で変換されることがあるので、出力の中身と、ソフトの解釈を分けて調べます。空欄が「未確認」なのか「該当なし」なのかも、台帳と照らします。画面では読めた文章が、途中で切れたり、改行で別のレコードになったりしていないかも見ます。

履歴と添付ファイルは、顧客一覧のCSVとは別の方法で取ることがあります。取れる対象、ファイル名、対応する顧客・案件のID、手順を確かめ、別々に出ても関係を再現できるかを試します。添付ファイルの参照先だけが出る場合は、解約後もその参照先が使えるのか、ファイルそのものを取っておく必要があるのかを確かめます。コメント、削除済みのデータ、変更履歴が一括出力に入っていると推測はしません。取れないものがあれば、引き継ぎへの影響と、別に保存する作業を導入の前に見積もります。

バックアップは、サービス側と自社側を分けて質問する

CSVを保存しただけでは、添付ファイルや設定を含めて元の状態に戻せるとは言えません。IPAの中小企業の情報セキュリティ対策ガイドラインは経営者編と実践編からなり、最初に取り組む基本の対策にバックアップを挙げています。社内の対策を整理するときの参照先になります。

選ぶときは、サービス側と自社側の責任を分けて聞きます。バックアップの対象、頻度、保管期間に加えて、復元を頼める条件、戻せる時点、範囲、かかる時間、費用です。サービス全体の障害からの復旧と、利用者が誤って削除したデータの復元は、同じとは限りません。自社で保存する出力ファイルも、保存先、見られる人、端末の管理、復元を確かめる担当を決めます。個別の文書の保存期間や特定のサービスの安全性は、一般的な解説からは決められないので、最新の資料と自社の専門家で確かめます。

09.移行と解約は、契約の前に確かめる

移行は、古いデータをまとめて取り込む作業ではありません。どの情報を正とし、重複や欠けをどう扱い、取り込んだ後に何を照合するかを決める作業です。同時に、将来解約するときにデータを取り出せるかも確かめます。入れられることと、出せることは、契約前の別々の要件です。

移行元は、共有の表、個人のファイル、メール、既存のシステムを一覧にし、持ち主、更新日、範囲を確かめます。同じ顧客が複数の場所にいる場合は、項目ごとにどれを優先するかを決めます。更新日が新しいほうが正しいとは限らず、連絡先を確かめた履歴や、停止の意思を受けた記録といった根拠で判断します。移行しないデータも、理由と件数を残します。移行から外すことと、廃棄することは別の判断です。旧環境の更新を止める日と、新しいCRMで入力を始める日をそろえ、その間に来た問い合わせを書く場所と、後から取り込む担当を決めます。

名前が似ているという理由で、意味の違う項目を対応させないようにします。旧IDは、照合と問い合わせに使えるよう残します。文字数の制限、選択肢、日時の形式で起きる取り込みエラーも、変換の決まりと一緒に書いておきます。

本番の前に、少量でテスト移行をします。きれいなデータだけでなく、重複、担当者不明、長い履歴、添付ファイル、停止の情報を入れ、取り込んだ後に、普段の検索、担当変更、出力まで試します。取り込みのエラーは、対象のID、原因、直し方、再取り込みの結果を残します。もう一度実行したときに、同じデータが追加されるのか、既存のデータが更新されるのかも確かめます。本番で問題が出たときに取り消せる範囲を質問し、戻せない操作は実施の前に対処を決めます。テストに実データを使う必要があるなら、管理責任者が範囲と取り扱いを確かめてからにします。

件数の照合は、顧客、案件、履歴、添付ファイルを別々に行います。次は顧客レコードだけを数える架空の検算です。重複統合の件数は、統合した組の数ではなく、統合で減ったレコードの数です。

総数が合っていても、欠落と重複が打ち消し合っていることがあります。旧IDと新IDの対応を全件で照らし、代表のレコードで連絡先、停止の情報、案件との関係を確かめます。本番までに増えたり変わったりした分は、この検算とは別に差分として取り込みます。

解約時の条件は書面で確かめる

「CSV出力可」という回答だけでは、必要な履歴や添付ファイルを取れるかは分かりません。次の質問を、候補各社に同じ条件で出します。

回答には対象のプランと確認日を付け、契約書と食い違う点は解消してから判断します。取得に社内の作業が要るなら、終了日から逆算して担当と時間を確保します。

旧データは、保管の目的、場所、見られる人、見直す時期、廃棄を判断する人を決めます。移行が終わったらすぐ消すのでも、念のため無期限に複製を残すのでもありません。問い合わせの履歴、契約関連の文書、その他の記録では確かめる条件が違うことがあるので、保存期間は一律に決めず、管理責任者や専門家が関係する資料で確かめます。保管中に更新を続けると新旧どちらが正か分からなくなるので、旧環境を参照専用にする方法があります。移行作業をした人の端末や一時フォルダに残った複製も、管理の対象です。

10.必須要件の合否を先に見て、採点は後にする

最後の判断では、必須要件の合否を先に確かめ、その後で使いやすさや追加の負担を比べます。機能が多い候補や合計点の高い候補でも、停止の情報を引き継げない、必要な履歴を出力できない、といった問題が残るなら、そのまま導入は決めません。

必須要件は、合格、不合格、未確認で判定し、希望要件の点数で不合格を埋め合わせません。設定や代わりの手順で満たせる場合は、その手順を実際に試し、運用の責任者が続けられると判断してから合格にします。費用や手間を理由に必須の条件を外すなら、評価表から消すのではなく、どの業務に響くか、誰が例外を承認したか、どんな補完の作業と制約が残るかを書きます。

希望要件の比較には、重み付きの採点が使えます。次は項目と重みの例で、実在の製品の点数ではありません。

たとえば、確認済みの項目について「3＝追加の補完なしで運用できる、2＝軽い補完が必要、1＝継続的な補完が必要、0＝実現できない」と決めます。重要度×点数で計算し、上の重みなら満点は（3＋3＋3＋2＋2）×3＝39点です。未確認の項目を0点や推定の点にせず保留とし、合計点は確認できた範囲をそろえてから比べます。

採点表の横に、設定、教育、保守の作業を並べます。誰が項目を作り、誰が現場に説明し、問い合わせを誰が受けるのかが決まっていなければ、使いやすい候補でも導入は止まります。教育は、機能の説明を聞いたかではなく、新規登録、停止の希望の記録、担当変更、検索、誤入力の修正を担当者が自分でできるかで確かめます。支援サービスを使うなら、初期設定だけか、移行や運用の変更も含むのかを見積書で確かめます。

導入時の決まりは、日常で見返せる一枚にします。次は役割分担の記入例です。

入力できない状況が起きたときに一時的に書く場所と、後で正式な記録に戻す担当も決めます。二重管理が当たり前になっていないかは、点検の対象です。

運用を始めたら、問い合わせの量と営業会議の周期に合わせて点検します。未割り当て、次回行動の未設定、期限超過、連絡条件の不明の一覧を見て、件数だけでなく原因を調べます。入力漏れが続くときは、教育不足と決める前に、項目が多すぎないか、入力する時点で情報が分かっているか、端末から操作しにくくないかを見ます。割合で見るなら、対象期間と分母を固定します。次回行動の未設定率なら、どの状態の案件を対象にするかを決め、終了した案件を混ぜません。

導入する、条件を解消してから判断し直す、今の運用を直す。どれを選んでも、評価表の空欄は未確認の事項として残し、理由と次の担当者が分かるようにしておきます。