オムニチャネル・OMO 顧客統合・機能のポイント
第２回は
オムニチャネルで課題となるテーマ
パーソナライズの「基本データ」ともなる
顧客情報統合
についてお伺いしていきます。
基幹システム」「受注管理システム」連携で何故実現しなかったのか
中田様
それは、各チャネルで顧客とは何かという認識がずれているからです。
オフライン系では顧客マスターがあります。顧客として管理しています。
Eコマースの従来パッケージシステムでは、顧客あるいは会員と呼んだりしますよね。
それを連携させようとしたりするわけです。
でもこれって根本的に違います。
Eコマースのパッケージにありがちのいわゆる「会員機能」とは
「Lexica：レキシカ」には、機能上「会員管理」というメニューが存在してないですし、「会員」というマスターもありません。
なぜなら、Eコマースサイトは、「会」を運営しているわけではないはずです。
アカウントを作って、そこに「認証情報」があって、「アカウント利用権」が与えられていて、その自分のアカウント情報を参照していることが実際の重要な機能です。
会に入っているのではなくて、人としてログインはしてマイページとかを見たり、利用しているということになります。
オフライン系の顧客とは
認証情報ではなく、「顧客名簿」です。
顧客名簿は、お店が作成しているものです。
自社の取引相手が顧客になります。
見方を変えると買われた、注文をして取引している人に対してあなたは顧客じゃないとは言えないです。
消費者視点でいくと、買った本人がそのお店で私は顧客ですけどというのは、何か変だという感じはありませんか。
私が顧客になったわけではなくて、私が買い物をした結果、私はただ買った人であって、それを店が顧客として帳簿につけているということすね。
このアカウントと認証IDについては、アカウントを開設したい本人がいて、それに対してお店がアカウントを開設しました。
そうすると本人としては当然それを使う権利があるので、本人はアカウントを保有していると言える。
アカウントを持ってるから、その情報を使わせてくれというのは普通に正当な要求なんですよね。
実際、これが重要な問題だと思っていまして、概念的にやはり違うものにもかかわらず、それを「ユニークID：UID」を送りつけるだけで連携できるかというと、それはできないでしょう。
実際の起きてくる問題と解決策
続きは YouTubeにて
E－リテーリングシステムズさんからのご案内
新しいコマースシステムを一緒に開発するエンジニア
OEMとして、コマースシステムとして開発提供頂けるパートナー様をお待ちしているとのことです。
あたらしい、アーキテクチャーを活用して自社ソリューションの幅を拡げていきたいなどのご関心やご要望があればE-リテーリングシステムズ様まで、お気軽にお問い合わせください。
オムニチャネルコマースクライアントのメリット
「Lexica:レキシカ」は、Souce：ソースまでを公開提供いただけます。
自社エンジニアリソースがあれば、自社で追加開発・変更や、コンポーザブルに外部システムとの連携が可能になります。
いままでのような、ベンダーロックや、開発タイミング・開発費用の過剰な負担から解放されて、POCなど素早い顧客変化、チャネル変化により迅速な対応が可能になります。
Lexica OMO/オムニチャネルコマースシステム・ご相談はこちらから
