顧客ロイヤルティソフトウェア

2007年9月4日

先週、カルガリーのオフィスにいて、最も信頼できるテクニカルリードの1人であるジョン・コーデバックと良い話をしました。彼は多くの旅行ロイヤルティソフトウェアシステム（マイレージプログラムなど）に取り組んできており、それらの性質と、より実りある方法でそれらについて考える方法について話し合いました。

ロイヤルティシステムの中核は、ポイント（またはマイル）を追跡するシステムです。これにより、顧客は自分のポイントを確認し、企業は未償還ポイントを管理できます。多くの人はそうは思わないかもしれませんが、これは本質的に会計システムであり、ポイントをドルと交換しているだけです。ジョンの観察によれば、彼は繰り返し、会計の視点に立てばはるかに簡単に解決できる問題に遭遇しています。

その例として、随時変更の処理があります。自動化されたルール処理がどれだけ優れていても、何か異常が発生して手動で介入しなければならないケースは常に存在します。多くのシステムでは、その結果、エラーが発生しやすく監査されていない合計への随時変更となります。しかし、会計の枠組みで考えると、これらの変更は会計調整と見なされ、これに関するパターンはよく理解されています。

ロイヤルティプログラムとほとんどの会計システムの顕著な違いは、ロイヤルティプログラムの方が資産の管理よりも負債の管理に重点を置いていることです。そのため、リスク管理だけでなく、税金や収益報告などの共通のテーマにも重点が置かれています。

多くのロイヤルティシステムには、通常のマイレージやエリート資格マイレージなど、複数の種類のポイントがあります。これは複雑さの一般的なポイントです。しかし、会計の視点を使用すれば、これらを複数の通貨として簡単に追跡できます。

これに対する興味深い解釈は、潜在的なポイントです。来月のフライトを予約した場合、航空会社は来月フライト時に獲得するマイル（潜在的なマイル）を知っている必要があります。これらの潜在的なマイルは、その負債に影響します。しかし、実際にフライトをしたときにのみ、実際のマイルになります。ここでも、会計的な考え方が役立ちます。複数の通貨を使用したり、買掛金的概念を使用したりできます。メカニズムは存在し、よく理解されています。モデルを状況に適用するだけです。

私たちは実践の中でこれを詳しく説明し、テスト駆動開発を使用することも非常に役立つことがわかりました。数人の人が数週間かけて計画された設計で潜在的なマイルを解決しようとしましたが、TDDを使用すると、主要な問題は数日で解決されました。この重要な部分は、例に焦点を当てて問題を具体的にすることでした。

会計のアナロジーは、活動に対するマイルの付与方法を決定することにも適用されます（ただし、部分的に直接的ではありません）。どのプログラムにも、非常に柔軟で、ロイヤルティプログラムへの継続的な変更に対応できる必要があるアクティビティルールがあります。これは、合意ディスパッチャを使用して、ドメインイベントが会計仕訳をトリガーするというモデルに従っているものと見なすことができます。これは、ジョンと私が何度も使用してきたパターンであり、このような変化するルールにもうまく機能します。本質的に、私たちは参加者のクラスの全体的なプログラムルールを表す合意を持っています。各合意は、イベントの種類と日付範囲をキーとする一連の転記ルールで構成されます。ドメインイベント（ホテル滞在）が発生すると、顧客の合意ディスパッチャを調べ、イベントを使用して適切な転記ルールを調べます。次に、転記ルールを実行して、イベントのマイルを表す適切な会計仕訳を作成します。イベントの日付設定により、時間の経過とともに転記ルールを変更できますが、古いイベントを処理し、調整の自動処理を正しく実行できます。（いつかこれらのパターンを書き終えるつもりですが、ウェブ上に掲載している内容は、いくつかのアイデアを与えるのに役立つと思います。）

ロイヤルティシステムの2つ目の側面は、顧客体験の追跡です。会計にはシステムによる顧客活動の記録が必要であるため、ロイヤルティシステムは、顧客と企業のやり取りから学ぶための自然な基盤として機能します。この多くはデータマイニングであり、顧客行動のパターンを探し、新しい製品やプロモーションにつながります。また、この活動履歴を使用して、プロモーションの成功を評価することもできます。たとえば、特定のルートのフライトにマイルボーナスのオファーをした場合、どのような反応がありますか？

私と同様に、ジョンはレポートデータベースの使用を強く支持しており、これはこの種の問題に適しています。会計面には、非常に異なる一連のデータ構造が必要であり、活動が発生すると定期的な更新が行われます。顧客体験分析はすべて読み取り専用であるため、会計側から定期的な（必ずしもリアルタイムではない）フィードを使用して、正規化されていない構造を使用できます。

さらに進んで、会計システムと顧客体験システムを完全に切り離すことは合理的と思われます。両システムは通常、同じイベントを追跡するため、単一の顧客ロイヤルティシステムとして一緒に配置されます。しかし、内部が大きく異なるため、同じイベントストリームから供給される2つの独立したシステムとして扱う方が理にかなっている可能性があります（会計側は顧客体験側にもいくつかのイベントを生成するでしょう）。

顧客体験追跡の習慣の1つは、新しい種類の分析をサポートするためにシステムを頻繁に変更することです。顧客活動の単一の保存済みイベントログにアプローチを試み、ログから選択した情報をより具体的なデータ構造に変換してさまざまな種類の分析を行う比較的独立した「マイナー」をプラグインできるのではないかと推測しました。マイナーはお互いに比較的独立しているため、構築が容易になります。

ご覧のとおり、私たちの議論は、ジョンの経験を検討することから、このようなシステムを将来どのように構築できるかについての共同の推測へと移行しました。私たちにとって明確なのは、この分野で新しいアイデアを探求する余地が多くあり、ビジネス活動により良いサポートを提供できるシステムにつながる新しい抽象化のセットを導入できることです。最近はこれに関心が集まってきており、これは私たちにとって実りある分野であるように思われます。