Salesforce Loyalty Management を活用したスケーラブルな顧客ロイヤルティプログラムの設計

執筆者：Salesforce アーキテクト

背景と適用シナリオ

現代のビジネス環境において、企業と顧客との関係は単なる取引ベースのものから、エンゲージメントと体験を重視したものへと大きく変化しています。この変化の中心にあるのが、顧客ロイヤルティです。効果的なロイヤルティプログラムは、顧客維持率を向上させるだけでなく、顧客生涯価値 (LTV) を最大化し、ブランドの熱心な支持者を育成するための強力なツールとなります。しかし、多くの企業は、サイロ化したシステム、一貫性のない顧客体験、パーソナライズの欠如といった課題に直面しています。

ここで Salesforce Loyalty Management (ロイヤルティ管理) が登場します。これは、Salesforce Customer 360 プラットフォーム上にネイティブに構築されたソリューションであり、企業が柔軟で、スケーラブルで、インテリジェントなロイヤルティプログラムを設計・管理・最適化することを可能にします。Salesforce アーキテクトの視点から見ると、Loyalty Management の真価は、単なるポイント管理機能に留まらず、販売、サービス、マーケティング、コマースといった顧客接点全体で一貫したロイヤルティ体験を構築できるアーキテクチャにあります。

適用シナリオは多岐にわたります：

小売・Eコマース： 購入金額に応じたポイント付与、特定商品の購入ボーナス、誕生日特典バウチャーの発行など。
旅行・ホスピタリティ： 宿泊数や利用金額に基づく階層型プログラム、ラウンジ利用やアップグレードなどの特典提供。
金融サービス： 口座残高や取引頻度に応じた優遇金利、手数料割引などのベネフィット提供。
B2B： パートナー企業や販売代理店の取引量に応じたリベートやインセンティブプログラム。

本稿では、Salesforce Loyalty Management を活用して、企業の成長に合わせて拡張できる、堅牢でスケーラブルなロイヤルティプログラムをどのように設計するか、アーキテクチャの観点から深く掘り下げていきます。

原理説明

Salesforce Loyalty Management のアーキテクチャを理解するには、その中核をなす「データモデル」「処理エンジン」「統合レイヤー」の3つの要素を把握することが不可欠です。

データモデル

Loyalty Management のデータモデルは、柔軟性と拡張性を念頭に置いて設計されています。主要な標準オブジェクトを理解することが、効果的な設計の第一歩です。

Loyalty Program (ロイヤルティプログラム): プログラム全体のコンテナです。プログラム名、通貨、処理モード（リアルタイム/バッチ）などを定義します。
Loyalty Program Member (ロイヤルティプログラムメンバー): プログラムに参加する顧客を表します。取引先 (Account) または個人取引先 (Person Account) レコードに紐づきます。現在のポイント残高や階層情報などを保持します。
Loyalty Tier Group (ロイヤルティ階層グループ) & Loyalty Tier (ロイヤルティ階層): 「シルバー」「ゴールド」「プラチナ」のような階層構造を定義します。階層の昇格・降格条件はここで設定されます。
Benefit (特典): 各階層のメンバーが受けられる特典（例：送料無料、限定アクセス）を定義します。
Voucher (バウチャー): 割引クーポンや特典引換券などを管理します。Voucher Definition でテンプレートを定義し、個々のメンバーに対して発行します。
Transaction Journal (トランザクションジャーナル): ロイヤルティプログラムにおけるすべての活動の記録台帳です。ポイントの獲得 (Accrual)、交換 (Redemption)、調整 (Adjustment)、失効 (Expiration) など、すべての取引がこのオブジェクトに記録されます。アーキテクチャ上、最も重要なオブジェクトの一つであり、データの完全性と追跡可能性を担保します。

これらのオブジェクトが連携することで、複雑なロイヤルティプログラムのルールや状態を体系的に管理することが可能になります。

処理エンジン

Loyalty Management は、リアルタイム処理とバッチ処理の両方に対応する強力な処理エンジンを備えています。適切なエンジンを使い分けることが、パフォーマンスとスケーラビリティの鍵となります。

Flow (フロー): リアルタイムのトランザクション処理に使用されます。例えば、店舗での購入直後にポイントを付与する、ウェブサイトでポイントを特典に交換するといった、即時性が求められるシナリオに適しています。Loyalty Management は、ポイントの付与や交換を簡単に行うための標準 Flow アクションを提供しています。
Data Processing Engine (DPE: データ処理エンジン): 大量のデータを扱うバッチ処理に使用されます。例えば、月末に全メンバーの当月利用額を計算し、階層の昇格・降格を判定する、あるいは年間利用額に基づいてボーナスポイントを付与するといった、定期的な大規模計算に適しています。DPE は、大量の Transaction Journal レコードや関連オブジェクトを効率的に集計・変換し、結果を更新することができます。

統合レイヤー

ロイヤルティプログラムは、POSシステム、Eコマースプラットフォーム、モバイルアプリなど、様々な外部システムとの連携が不可欠です。Loyalty Management は、主に Connect REST API を通じて外部との連携を実現します。

この API を使用することで、外部システムからメンバーの登録、トランザクションの記録、ポイント残高の照会、特典の交換といった操作を安全かつ標準的な方法で行うことができます。アーキテクトは、リアルタイム性を求めるか、大量のデータを扱うかによって、直接の API コール、MuleSoft を介したオーケストレーション、あるいは Platform Events を活用したイベント駆動型アーキテクチャなど、最適な統合パターンを選択する必要があります。

サンプルコード

外部のEコマースプラットフォームで顧客が商品を購入した際に、ポイントを付与するシナリオを考えます。これは、Connect REST API を使用して Transaction Journal を作成することで実現できます。この API コールは、Eコマースシステムのバックエンドや、MuleSoft などの統合ミドルウェアから実行されることを想定しています。

以下のコードは、指定したロイヤルティプログラムのメンバーに対して、購入に基づきポイントを付与（Accrual）するための Transaction Journal を作成する例です。

Connect REST API: トランザクションジャーナルの作成

// HTTP メソッド
POST

// エンドポイント
/services/data/v58.0/connect/loyalty/programs/NTO_Program/transaction-journals

// リクエストヘッダー
Authorization: Bearer [Your_Session_ID]
Content-Type: application/json

// リクエストボディ
{
  "journalEntries": [
    {
      "loyaltyMemberId": "0lMxx0000000001AAA", // ポイントを付与するロイヤルティメンバーのID
      "journalSubType": "Purchase", // トランザクションのサブタイプ（任意）
      "activityDate": "2023-10-27T10:00:00Z", // 購入が発生した日時
      "transactionType": "Accrual", // トランザクションタイプ（Accrual: 獲得）
      "loyaltyProgramCurrency": "Points", // 使用する通貨（ポイントやマイルなど）
      "amount": 100, // 付与するポイント数
      "additionalContext": {
        "orderId": "ORD-00123", // 関連する注文IDなど、追加情報を格納
        "storeId": "STR-005"
      }
    }
  ],
  "journalTypeName": "ManualPointsAdjustment" // 事前に定義されたジャーナルタイプのAPI名
}

コードの注釈

エンドポイント: /services/data/vXX.X/connect/loyalty/programs/{programName}/transaction-journals という形式で、対象となるロイヤルティプログラムの API 名を指定します。
journalEntries: 複数のトランザクションを一度に記録できる配列形式です。
loyaltyMemberId: どのメンバーに対するトランザクションかを特定するための必須項目です。
activityDate: トランザクションが発生した正確な日時です。ポイントの有効期限計算などに使用されるため、正確な値を設定することが重要です。
transactionType: 'Accrual' (獲得), 'Redemption' (交換), 'Reversal' (取り消し) など、トランザクションの性質を定義します。
loyaltyProgramCurrency: ポイント、マイルなど、プログラムで定義された通貨の API 名を指定します。
amount: 付与または交換するポイント数です。
additionalContext: 外部システムの参照ID（注文IDなど）を格納するためのキーバリューペアです。これにより、後からトランザクションの追跡や監査が容易になります。
journalTypeName: どのような種類のトランザクションかを分類するためのもので、事前に設定で定義しておく必要があります。

注意事項

Loyalty Management を導入・設計するアーキテクトは、以下の点に特に注意を払う必要があります。

権限とライセンス

Loyalty Management の機能を利用するユーザーには、"Loyalty Management" の Permission Set License (権限セットライセンス) が必要です。さらに、API を介してプロセスを自動実行する統合ユーザーには、"Loyalty Management - Process Actions" ライセンスが必要になる場合があります。これらのライセンス割り当てと、オブジェクト・項目レベルのセキュリティを適切に設計することが不可欠です。

API 制限とガバナ制限

Loyalty Management は Salesforce Platform 上で動作するため、すべてのガバナ制限（SOQLクエリの上限、DML操作の上限など）が適用されます。特に、Connect REST API は組織全体のAPIコールリミットを消費します。一日に数百万件のトランザクションが発生するような大規模なプログラムの場合、すべてのトランザクションをリアルタイムで API コールすると、容易に制限に達してしまいます。このような場合、トランザクションを一旦キューイングし、MuleSoft などでバッチにまとめて処理する、あるいは Platform Events を使って非同期で処理するなど、API コール数を最適化するアーキテクチャパターンを検討する必要があります。

データ量とパフォーマンス

Transaction Journal オブジェクトは、プログラムがアクティブである限り、急速にデータが蓄積されます。数百万のメンバーが毎日トランザクションを発生させると、数年で数億レコードに達する可能性があります。これがパフォーマンスのボトルネックにならないよう、設計初期段階からデータ戦略を策定することが重要です。具体的には、Salesforce の標準的なデータアーカイブ戦略（Big Objects へのアーカイブなど）や、定期的にデータを集計してサマリーオブジェクトを作成し、古いジャーナルレコードは外部のデータウェアハウスに移動させるといった戦略が考えられます。

エラー処理と補正

外部システムとの連携において、ネットワーク障害やデータ不整合によるエラーは避けられません。API コールが失敗した場合にどうするか、堅牢なエラーハンドリングとリトライメカニズムを設計に組み込む必要があります。例えば、API コールに失敗したトランザクション情報をカスタムのログオブジェクトに記録し、定期的なバッチ処理で再実行を試みる、あるいはエラー発生時に管理者に通知を飛ばすといった仕組みが考えられます。また、ポイント付与の誤りなどを修正するための補正（Adjustment）トランザクションのプロセスも定義しておくべきです。

まとめとベストプラクティス

Salesforce Loyalty Management は、顧客とのエンゲージメントを深めるための強力なプラットフォームですが、その真価を最大限に引き出すためには、戦略的なアーキテクチャ設計が不可欠です。

Salesforce アーキテクトとして、以下のベストプラクティスを推奨します。

ビジネス戦略から始める: テクノロジーの導入ありきではなく、どのような顧客行動を促進したいのか、どのような体験を提供したいのかというビジネス目標を明確に定義することから始めます。
適切な処理エンジンを選択する: ユースケースの要件（即時性、データ量）に基づき、リアルタイム処理には Flow を、大規模なバッチ処理には DPE を戦略的に使い分けます。
スケーラブルな統合パターンを設計する: 将来のトランザクション量を見越して、API のガバナ制限に抵触しないような統合アーキテクチャ（バッチ処理、非同期処理など）を選択します。
データ戦略を早期に策定する: Transaction Journal の増大を見据え、パフォーマンス維持のためのデータアーカイブ、集計、ライフサイクル管理の計画を立てます。
Customer 360 を活用する: Loyalty Management を単独のツールとして捉えるのではなく、Service Cloud での問い合わせ対応時にメンバーシップ情報を表示したり、Marketing Cloud で階層別のパーソナライズドキャンペーンを実施したりと、Salesforce の他製品と連携させることで、その価値を最大化します。

これらのアーキテクチャ上の考慮事項に注意を払うことで、Salesforce Loyalty Management は単なるポイント管理システムを超え、顧客体験を向上させ、持続的なビジネス成長を牽引する戦略的な基盤となるでしょう。

にゃんこのSalesforce日記

このブログを検索