ソーシャルギフト機能を自社ECに導入する方法

ソーシャルギフトは、SNSのメッセージ機能やメール等を利用して、ECサイトで購入した商品を贈ることができる、今までには無かった新しい贈り方です。相手側が受取場所や受取日時を指定する為、住所や電話番号を知らない相手であっても、贈ることが可能です。昨今のSNSの普及や、ギフトを通したコミュニケーション利用が増えていることもあり、ソーシャルギフト機能はEC事業者からのニーズも高まっています。
そこで本記事では、ソーシャルギフトの機能を自社ECに導入する方法について、探っていきます。

目次

1. ソーシャルギフト機能とは
2. ソーシャルギフト機能を自社ECに導入する方法
3. ソーシャルギフト導入方法の比較
4. まとめ

ソーシャルギフト機能を自社ECに導入する為には、以下の専用機能が必要になります。

ソーシャルギフト専用のカートステップ

一般的なECサイトでは、注文者がお届け先の情報を入力して注文を確定させますが、ソーシャルギフトの贈り方では、注文完了後に受取人側が入力するため、専用の入力画面を用意する必要があります。
受取人側に対し、ギフトが届く通知とともに受取住所の入力画面へと導くための「ソーシャルギフト専用のURL」の生成も必要になります。
ギフトレターやメッセージ送付機能は、ギフトの特別感を演出する為に用意しておくと良いでしょう。

＜贈る側＞

１．贈り主（注文者）が商品を選び、決済を完了
２．ギフトレターやメッセージ送付
３．注文完了時にシステム側で生成される受け取り専用URLを贈り主（注文者）が贈りたい人にSNSやメールで通知
＜受け取る側＞

１．メッセージを受信
２．贈られる人（受取人）が受取場所や受取日時を指定

ソーシャルギフト専用の在庫管理や受注管理機能

ソーシャルギフト受注は、贈る側が注文を完了させても、発送先情報が未入力の状態では注文としては成立していません。受取人が情報を入力して注文が完了し、商品を発送できる状態となります。

しかし商品の在庫の確保は、受取人が情報を入力してくれることを前提に、贈る側が注文を完了させた時点で抑えておく必要があります。ただし、ECの運営上、いつまでも在庫を確保しておくわけにもいかないでしょう。これを防ぐために、受取人の情報入力期限を設けておき、期限切れの受注に対しては自動キャンセルするような仕組みが必要になります。

受注管理画面では、受取人が情報を入力した受注を判別表示できるようにしておき、完了した受注を発送業務に回せるステータスにしておきます。受取住所未入力の受注に対しては自動キャンセルにならないよう、必要に応じて贈り主へリマインドメールで通知できるようにしておくと、売り逃しによる機会損失も防げるでしょう。

また、プライバシー保護の観点から、受取人は送り主に対して住所を知らせたくない場合もあるでしょう。この為、商品の発送メール等の受注関連メールは、贈り主用と受取人用とで送付内容を切り分けておく仕組みも必要です。

ソーシャルギフト機能を開発（カスタマイズ）する場合

スクラッチ開発

新規立ち上げ、或いは現在運用中のECサイトのカートシステムが、スクラッチ開発等のカスタマイズ可能なシステムの場合、ソーシャルギフト機能をカートシステムに組み込むという方法をまず思い付きます。しかし、ソーシャルギフトは、実際に商品をカートに入れた後の画面を操作してみるとお分かり頂けますが、従来のECのカートステップとは購入導線が異なります。

つまり、ソーシャルギフトは、通常のECのカートとは別にソーシャルギフト専用のカートをもう一つ用意するようなイメージです。機能追加（カスタマイズ）は容易ではなく、実施方法を模索するなら、カート部分の大きなカスタマイズになるため、開発費用面や対応コスト面において大規模投資を覚悟しなければなりません。

ASP/クラウド型

ASP/クラウド型のカートシステム利用の場合、まずはASP/クラウド提供会社に確認して対応状況や導入予定を確認してみてください。カスタマイズ可能なASPの場合、追加機能開発の実現可否やカスタマイズ必要についての確認が必要です。

ソーシャルギフト機能のみを利用する方法

次に、ソーシャルギフトの機能のみを使える方法がないかを模索してみます。ソーシャルギフト機能が備わったカートシステムであれば、ソーシャルギフト商品のみを登録して、その部分のみを利用することはもちろん可能です。

大規模サイト等を既に運営しており、既存のサイトを動かすことが難しい場合や、「ソーシャルギフト機能をまずはお試し運用する」という意味合いで、期間を決めて利用したい場合、この方法でソーシャルギフトを導入すると良いでしょう。

ただし、本サイト（通常のEC）とは別のシステムで、ソーシャルギフト商品のみの専用カートを用意した場合、カートシステムを併用で運用することとなるため、考慮しなければならない点が発生します。サイト側のデザインは、統一させることで同一システムと見せかけることは可能であっても、バックヤード側のシステムが分かれれます。これにより、本サイトとは別のドメイン（サブドメイン含む）が必要になったり、受注運用や在庫管理、顧客対応においても、二重管理が発生してしまうことを念頭に置かなければなりません。

ソーシャルギフト対応したASP/クラウドECに移管する方法

ソーシャルギフトに対応したシステムに移管する（切り替える）という方法があります。システム移管（切り替え）と聞くと大掛かりに聞こえるかもしれませんが、実際のところは以下の３つのステップで完了します。

そして、これらのステップをより円滑に進めるための確認ポイントは以下です。

最近では、オリジナルのデザインでブランドイメージを訴求するようなこだわりのECサイトを構築可能なASP/クラウドEC型のカートシステムが登場しており、大手事業者もこれを採用するケースが増えています。どのようなデザインサイトの構築が可能かは、公開されている導入事例などを確認すると良いでしょう。

データの移管時の注意点としては、会員情報のパスワードやクレジットカード情報は引き継げません。新しいシステムにて会員自身に再登録を促す必要があります。これらのセキュリティの高い情報を平文保存されているようなシステムも一部現存しているかもしれませんが、これらのデータを移管してしまうことは即ち、セキュリティ度の高い情報が暗号化保存されていないことを意味します。既存顧客（会員）に情報管理体制の疑いの目を向けられ兼ねず、情報漏洩に対するリスクを連想させるでしょう。また、データ移管の際に手違いで流出してしまう事故も起こりかねません。既存顧客（会員）の利便性を思いやるよりも、多少手間をおかけすることとはなりますが「システムリニューアルの為、再登録のお願い」と周知させる対応をとることで、トラブルには繋がらないでしょう。

ドメインは、EC担当者のみならず運営者であっても、これまでどのように管理されてきたのか意外と知らないケースがあります。不明な場合はメインの所有者を確認し、DNSレコードを変更する方法を前もって確認しておき、切り替え時に慌てないようにしましょう。

ソーシャルギフト機能を自社ECに導入する方法としてご紹介した3つの方法を比較してみます。

ソーシャルギフト機能を開発する場合、「要件定義→設計→開発→動作確認→不具合が見つかれば修正→正常に動作するまで対応した上でリリース」といった大きな工程が必要になりますが、ソーシャルギフト対応カートの場合は、これらの工程が不要になり、自社の運用にマッチしているかの動作確認をするだけですぐに運用を開始できます。

ソーシャルギフト対応カートを利用する場合について、併用運用とシステム移管(切替/リプレイス)で比較します。大きなポイントとなる点は、受注運用にかかるコストと、移管時に必要なコストの比較です。
併用運用の場合、ソーシャルギフト対応カートを利用し続ける限り、受注運用や在庫管理、顧客対応において二重管理が発生します。
一方で移管（切替/リプレイス）の場合、各種データ移管が発生しますが、CSVで一括対応できる場合がほとんどです。

併用運用の場合に発生し続ける二重管理の対応コストと、移管時のコストを天秤にかけると、移管により一時的に発生するコストの方が、中長期目線で考えると少ないことは明白です。

ソーシャルギフト対応カートには、ギフトECサイト構築のためのクラウド型ASPのaishipがあります。ソーシャルギフト機能のみの利用も、ECカートシステムそのものの切り替え利用も、どちらも対応可能です。

しかし、現在のところソーシャルギフトの利用目的は「ギフト用途」がほとんどかと思います。ギフト用途におけるEC運用の場合、ソーシャルギフト機能以外にも、熨斗やラッピング機能、メッセージカード機能など、ギフトECの専用機能も必要です。お中元やお歳暮、バレンタインやクリスマス等、ギフトイベントには食品系の商材がよく贈られますが、食品系のECなら、三温帯の機能や出荷日別在庫管理等の専用機能も必要です。

aishipをソーシャルギフト機能のみで利用することは可能ではある、と書きましたが、今後ギフトECを本格運営していくのであれば、それぞれの機能を個々で利用するよりも、ギフトEC専用カートとして全体設計されたASP/クラウド型カートシステムを使用することで、導入費用や対応コストをトータル的に抑え、統一感のあるギフトEC運営を実現できるでしょう。

ソーシャルギフト機能の導入検討をきっかけに、システム自体もリニューアルすることで、新しいトレンドを取り入れた、より良いECサイト運営へと可能性が広がります。