客戶忠誠度軟體

上週我在卡加利辦公室，與我們最信賴的技術主管之一約翰·科迪巴克進行了一次愉快的交談。他曾參與並深入研究過許多旅遊忠誠度軟體系統（常客飛行/臥鋪等），我們討論了這些系統的本質，以及如何以更有成效的方式思考它們。

忠誠度系統的核心是一個用來追蹤點數（或哩程）的系統。這應允許客戶查看他們的點數，也允許公司管理未兌換的點數。雖然看來大多數人並不同意這種看法，但這基本上是一個會計系統，只是將點數換成了美元。約翰的觀察是，他反覆遇到人們認為困難的問題，但一旦戴上會計眼鏡，這些問題就容易多了。

處理臨時變更就是一個例子。無論你的自動化規則處理有多好，總會有些奇怪的事情發生，你必須手動介入。對許多系統來說，結果就是容易出錯且未經稽核的總計臨時變更。然而，以會計思維來看，你會將這些變更視為會計調整，而這種模式已被廣泛理解。

忠誠度計畫與大多數會計系統之間的一個顯著差異在於，忠誠度計畫更注重管理負債，而不是管理資產。因此，它更注重風險管理等事項，以及稅務和收入申報等常見主題。

許多忠誠度系統有多種點數，例如一般哩程和精英資格哩程。這是一個常見的複雜性。然而，如果你使用會計觀點，你可以將它們輕鬆地追蹤為多種貨幣。

一個有趣的變化是潛在點數。如果我預訂下個月的航班，航空公司需要知道我下個月飛行時將獲得的哩程（潛在哩程）。這些潛在哩程會影響他們的負債。然而，只有在我飛行時，它們才會變成真正的哩程。會計思維在此也能提供幫助，我們可以再次使用多種貨幣，或使用應付帳款的概念。機制已經存在且廣為理解，我們只需將模型套用於情況即可。

我們在實務中充實了這一點，我們也發現使用測試驅動開發真的很有幫助。一群人花費了幾週的時間嘗試使用計畫設計來整理潛在哩程，但核心問題在使用 TDD 的幾天內就解決了。其中的關鍵部分是專注於範例，以使問題具體化。

會計類比也適用於決定如何授予活動里程，儘管部分較不直接。任何計畫都有活動規則，這些規則需要非常靈活，並且需要應對忠誠計畫的持續變更。我們可以將此視為遵循網域事件透過使用協議調度器觸發會計分錄的模型。這是 John 和我多次使用且適用於這些變更規則的模式。基本上，我們有協議代表參與者類別的整體計畫規則。每個協議包含一組過帳規則，這些規則由事件類型和日期範圍作為關鍵字。當發生網域事件（飯店住宿）時，我們會查詢客戶的協議調度器，並使用事件查詢正確的過帳規則。然後，我們執行過帳規則以建立適當的會計分錄來表示事件的里程。事件的時間標記讓我們可以隨著時間變更過帳規則，但仍然可以處理舊事件並正確執行調整的自動化處理。（總有一天我會完成撰寫這些模式，但我放在網路上面的內容有望能提供給你一些想法。）

忠誠系統的第二個面向是追蹤客戶體驗。由於會計需要系統記錄客戶的活動，因此忠誠系統充當從客戶與公司的互動中學習的自然基礎。其中大部分是資料探勘，尋找客戶行為中的模式，這可能導致新的產品和促銷活動。你也可以使用此活動記錄來評估促銷活動的成功，例如如果你提供飛航路線的里程紅利，反應如何？

像我一樣，John 是報告資料庫的強力支持者，這非常適合此類問題。會計方面需要一組非常不同的資料結構，並在活動發生時使用定期更新。客戶體驗分析都是唯讀的，因此你可以使用較不正規化的結構，並從會計方面定期（但未必是即時）提供資訊。

進一步來說，完全解耦會計和客戶體驗系統似乎是合理的。它們通常會一起作為單一的客戶忠誠系統，因為它們追蹤相同的事件。然而，由於它們在內部有很大的差異，因此將它們視為兩個獨立的系統，從同一個事件串流中獲取資料（會計方面可能也會為客戶體驗方面產生一些事件），可能會更有意義。

客戶體驗追蹤的習慣之一是頻繁變更系統，以支援新類型的分析。我們推測，我們可以嘗試一種方法，該方法有一個儲存的客戶活動事件記錄，並插入相對獨立的「探勘器」，這些探勘器會將記錄中的選定資訊轉換為更具體的資料結構，以進行不同類型的分析。這些探勘器可以相對獨立，因此更容易建置。

如您所見，我們的討論已從檢視 John 的體驗轉移到我們對如何建置此類系統的一些共同推測。對我們來說很清楚的是，在這個領域中，有很大的空間可以探索新想法，這些新想法可以引入一組新的抽象概念，從而建置出可以為這項商業活動提供更好支援的系統。現在越來越多人關注這一點，因此這似乎是一個我們可以努力耕耘的豐饒領域。