はじめに
「あのお客様は、いつ・どこで・何を買ったのか」——これを一目で把握できていますか。
店舗のPOSとECの受注管理が別々のシステムに分かれていると、意外とこれが見えないんです。
私が担当したアパレル・ギア系のECでは、店舗POS（スマレジ）とEC受注管理（NextEngine）の取引データを、CRM（HubSpot）の**取引（Deal）**としてまとめて同期する仕組みを作りました。
この記事では、その全体像と設計思想を解説します。
なぜ売上を「取引オブジェクト」で持つのか
顧客360度ビューという発想
CRMには顧客（Contact）を中心に、その人にまつわる情報がぶら下がります。売上を「取引（Deal）」という形でContactに紐づけておくと、顧客ページを開いただけで「この人は過去に何を買ってきたか」がすべて見えます。
売上データをただの集計表として持つのではなく、顧客に紐づいた取引の集合として持つ。これがいわゆる顧客360度ビューの土台になります。マーケティングの担当者が特別な操作をしなくても、購買文脈を前提に会話ができるようになるんです。
店舗とECをまたいだLTV
店舗で買う人、ECで買う人、両方使う人——現実の顧客はチャネルを自由に行き来します。ところがシステムが分かれていると、その人の「本当の購買総額」が見えません。
取引データを1つのCRMに集約すると、チャネルをまたいだLTV（顧客生涯価値）が初めて計算できます。「ECだけ見ると小口だが、店舗では常連」といった顧客を取りこぼさずに評価できる。これは施策の優先順位を決めるうえで、とても効いてきますよね。
クロスセル施策の基盤
過去の購買履歴が取引・商品明細として揃っていると、「Aを買った人にBを勧める」といったクロスセルの条件を、CRMのセグメント機能でそのまま組めます。
たとえば「昨シーズンにジャケットを購入し、まだグローブを買っていない層」を抽出してメールを送る、といった施策です。売上データが取引オブジェクトとして構造化されているからこそ、こうした条件抽出が現実的な工数で回せるようになります。
何を同期するのか — 全体像
3つのオブジェクトへの分解
1件の取引を、CRM上では3種類のオブジェクトに分解して登録します。取引そのものはDeal、購入した人はContact、買った商品の一つひとつはLineItem（商品明細）です。
この3つを正しく関連づけることで、「誰が・いくらで・何を買ったか」が構造化されて残ります。分解の具体的な設計は、サブ記事のマッピング設計で詳しく掘り下げます。
データの流れ
同期は、POS/ECから取引を取得し、変換し、CRMへ書き込むという流れで動きます。全体をつかむために、処理の順序を整理しておきましょう。
スマレジ・NextEngineから対象期間の取引データを取得する
メールや顧客番号でContactを検索し、なければ作成する
取引をDealへ、商品行をLineItemへマッピングする
ContactにDealを関連づけ、DealにLineItemをぶら下げる
このパイプラインを、後述するDry Runで安全に検証してから本番に流します。
名寄せの難しさ
メールと顧客番号での照合
同期でいちばん神経を使うのが、購入者を既存のContactに正しく結びつける「名寄せ」です。同じ人が店舗とECで別々に登録していたり、メールアドレスを変えていたりすると、うっかり別人として登録してしまいます。
このプロジェクトでは、メールアドレスを第一のキーにしつつ、会員番号（顧客番号）を補助キーとして併用しています。どちらか一方だけに頼ると取りこぼすため、複数のキーで照合していくのが現実解でした。
重複を防ぐ
名寄せに失敗してContactが重複すると、せっかくの顧客360度ビューが分断されてしまいます。片方のContactに店舗の取引、もう片方にECの取引がぶら下がると、LTVも正しく出ません。
重複は「後から」直すのが大変
一度分裂したContactを統合するのは手間がかかり、関連づけのやり直しも発生します。だからこそ入口の名寄せロジックを丁寧に設計し、後述のDry Runで事前に結果を確認することが重要になります。
安全に運用する仕組み
Dry Runという安心
本番のCRMにいきなり書き込むのは怖いものです。特に初回同期は対象件数が多く、マッピングのミスがあると大量の誤ったDealを作りかねません。
そこで、実際には書き込まず「何が作成・更新されるか」だけをレポートするDry Runモードを用意しました。結果を見て問題がないことを確認してから、本番同期に切り替えます。この「一度立ち止まれる」設計があるだけで、運用の安心感がまるで違うんです。
日次同期と手動実行
定常運用では、QStash（スケジューラ）経由で日次の自動同期を回します。前日の取引をまとめて取り込む形です。あわせて、管理画面から任意のタイミングで手動実行もできるようにしています。
日次で回しておけばCRMは常に最新に保たれ、手動実行があれば「取りこぼしを今すぐ埋めたい」「特定期間を再同期したい」といった場面にも柔軟に対応できます。
まとめ
POS・ECの取引データをCRMのDealに同期する狙いは、チャネルをまたいだ顧客の購買全体像を1か所で見えるようにすることです。売上を取引オブジェクトとして構造化することで、LTV評価やクロスセル施策の基盤ができあがります。
このテーマを、3本のサブ記事でさらに掘り下げます。