顧客管理のスプレッドシートが3ヶ月で崩れる理由｜テンプレを配る前に決める列と入力規則

顧客管理のスプレッドシートを探している方の多くは、すでに一度テンプレートを使ったことがあると思います。そして、しばらく経ってから見返すと、空欄が並び、同じ会社が2行あり、ステータスの言葉が人によって違う状態になっている。よくある光景です。

この状態を「現場が入力してくれないから」で片づけると、次のテンプレも同じように崩れます。実際に崩れたシートを直しにいくと、原因は入力する人の意識ではなく、シートの構造側にあることがほとんどです。

検索して出てくるテンプレート記事は、ほぼすべてが配布までで終わっています。配った後にどう崩れるか、崩れないために配る前に何を決めておくかは、ほとんど書かれていません。この記事はそこだけを書きます。

顧客管理シートの崩れ方は、意外なほどパターンが少ないです。現場で見るのはだいたい次の4つで、どれも「入力をがんばる」では止まりません。

特に多いのが1行目の「1行に情報を詰め込みすぎている」です。1顧客1行のつもりで作ったのに、商談が2回、3回と増えると、備考欄に日付付きのメモが積み上がっていきます。こうなると、集計もできないし検索もできない。備考欄が長くなってきたら、それは列設計を見直す合図です。

運用が始まると、必ず「この項目も入れたい」が出てきます。ここで何が起きるかが、そのシートの寿命を決めます。

壊れやすいのは、表の右端に数式やピボット、フィルタビューがぶら下がっている作りです。列を1本挿入した瞬間に、参照範囲がずれる、名前付き範囲が合わなくなる、条件付き書式の適用範囲だけ取り残される。直した人は気づかず、次に数字を見た人が「合っていない」と言い出します。

対処はそれほど難しくありません。集計側の参照を列番号ではなく見出し名で引くようにしておく、データ範囲を列全体で取っておく、追加していい場所を「この列とこの列の間」と決めておく。この3つで、列追加は事故ではなく作業になります。

もう1つ、足す前に「その列は誰が、いつ、何を見て埋めるのか」を1文で言えるかを確認してください。言えない列は、たいてい3ヶ月後に空欄のまま残ります。埋まらない列が増えるほど、シート全体が信用されなくなります。

表記ゆれは、注意喚起では直りません。人に気をつけてもらう代わりに、シート側で書ける形を狭めるほうが確実です。Googleスプレッドシートなら、データの入力規則（プルダウン、日付、チェックボックス、条件による制限）で大半はカバーできます。

ポイントは、全部を厳しくしないことです。分類に使う列だけ固定して、それ以外は自由に書かせる。ここを間違えて全列を規則で縛ると、現場は入力そのものを避けるようになります。

会社名のように、プルダウンにできず表記ゆれも起きやすい項目は、入力規則ではなく「名寄せ用のキー列」を別に持たせるほうが現実的です。顧客IDでも、法人番号でも、社内での呼び方でも構いません。人が読む名前と、機械が突き合わせるキーを分けておくと、後からツールへ移すときに一番効きます。

出典・一次情報：セル内にプルダウン リストを作成する（Google ドキュメント エディタ ヘルプ）。Googleスプレッドシートでは［データ］→［データの入力規則］→［ルールを追加］からプルダウンやリスト範囲を条件に設定でき、リストにないデータを入力すると拒否される（［詳細オプション］で警告表示に切り替えられる）ことが公式ヘルプに記載されています。仕様は変更されます。最新の情報は公表元でご確認ください。

崩れたシートを見ていて一番多い共通点は、同じ事実を2箇所から編集できる状態になっていることです。営業が自分の管理表で顧客ステータスを動かし、事務が全社シートでも動かす。あるいは、CRMにも同じ項目があって、どちらが最新か誰も分からない。

こうなると、片方を直した人は直したつもりでいて、もう片方を見た人は古い数字で判断します。しかも、間違いが見つかったときに直す場所が2つあるので、直すたびに食い違いが再生産されます。

ルールはシンプルです。1つの事実について、書き込める場所を1箇所だけにする。他の場所は参照専用にして、編集権限を外す。参照する側が「ここは見るだけ」と分かる見た目にしておくと、なお崩れにくいです。

顧客ステータスは営業、請求情報は事務、というように、事実ごとに責任者を分けるのは問題ありません。避けるのは、同じ列を複数の人・複数のシートから触れる状態です。運用を始める前に、列ごとに「この列を直すのは誰か」を書き出しておくと、後から揉めません。

「何件までスプレッドシートで大丈夫か」はよく聞かれますが、件数だけでは決まりません。同じ1,000件でも、1人が週1回更新するなら十分回りますし、5人が同時に開いて履歴を追記していれば、数百件のあたりから待ち時間や上書き事故が出てきます。判断材料は、件数・同時に触る人数・履歴を何件持つか・誰が数字を見るか、の4つです。

だから、限界が来てから慌てて移行するのではなく、移行する条件を先に書いておくのがおすすめです。「同時に更新する人が3人を超えたら」「1顧客あたりの履歴が10件を超えたら」といった形で、自社の言葉で決めておく。条件を先に決めておくと、移行の判断が感情論になりません。

移行するときに効くのは、テンプレの完成度ではなく、ここまでに書いた3つ（キー列がある・入力規則で値が揃っている・更新者が1人に決まっている）です。この3つが揃っているシートは、CRMでもkintoneでも、そのまま取り込めます。逆に揃っていないと、移行の前に数ヶ月分のデータクレンジングが必要になります。ただしkintoneは最低契約が10ユーザーなので、少人数の会社では金額の下限が先に効いてきます。その前提での組み方はkintoneは10人からにまとめました。

なお、この記事は顧客リストそのものの設計の話です。集めた数字を経営の画面として見せる話はBIツールなしで経営ダッシュボードを作るにまとめているので、ダッシュボードを作りたい場合はそちらを見てください。