客户忠诚度软件

上周我在卡尔加里办事处，与我们最值得信赖的技术主管之一约翰·科迪巴克进行了很好的交流。他参与过并深入研究过许多旅行忠诚度软件系统（常旅客/常客等），我们讨论了这类事物的本质以及如何以更有成效的方式思考它们。

忠诚度系统的核心是跟踪积分（或里程）的系统。这应该允许客户查看他们的积分，也允许公司管理未兑换的积分。虽然大多数人似乎不这么认为，但这本质上是一个会计系统，只是用积分代替了美元。约翰的观察是，他反复遇到人们认为难以解决的问题，一旦你戴上会计的眼镜，这些问题就变得容易多了。

一个例子是处理临时更改。无论你的自动化规则处理多么好，总会有奇怪的事情发生，你必须手动干预。对于许多系统来说，结果是临时更改总数，这容易出错且未经审计。然而，用会计的思维方式，你会把这些变化看作是会计调整，而这种模式是众所周知的。

忠诚度计划与大多数会计系统的一个显著区别是，忠诚度计划更多的是管理负债，而不是管理资产。因此，更多地关注风险管理，以及税收和收入报告等常见主题。

许多忠诚度系统有多种积分，例如普通里程和精英资格里程。这是一个常见的复杂点。但是，如果你使用会计视角，你可以轻松地将它们跟踪为多种货币。

一个有趣的变化是潜在积分。如果我预订了下一月的航班，航空公司需要知道我下个月飞行时将获得的里程（潜在里程）。这些潜在里程会影响他们的负债。但是，只有在我飞行时，它们才会变成真正的里程。同样，会计思维可以在这里提供帮助，我们可以再次使用多种货币，或者使用应付账款的概念。机制是存在的，并且被很好地理解，我们只需要将模型应用于这种情况。

我们在实践中完善了这一点，我们还发现使用测试驱动开发非常有用。一群人花了几周时间试图通过计划设计来解决潜在里程问题，但核心问题在使用 TDD 的几天内就解决了。这的关键部分是专注于示例，使问题具体化。

会计类比也适用，尽管部分不太直接，适用于决定如何根据活动奖励里程。任何计划都有活动规则，这些规则需要非常灵活，并且需要应对忠诚度计划的不断变化。我们可以将其视为遵循域事件通过使用协议调度程序触发会计分录的模型。这是约翰和我多次使用过的模式，并且适用于这类不断变化的规则。本质上，我们有协议代表一类参与者的整体计划规则。每个协议都包含一组按事件类型和日期范围键控的过账规则。当域事件发生（酒店住宿）时，我们会查找客户的协议调度程序，并使用该事件查找正确的过账规则。然后，我们运行过账规则以创建适当的会计分录，以代表该事件的里程。事件的时间日期允许我们随着时间的推移更改过账规则，但仍然能够处理旧事件并正确地进行调整的自动化处理。（总有一天我会完成这些模式的编写，但我发布在网上的内容应该足以给你一些想法。）

忠诚度系统的第二个方面是跟踪客户体验。由于会计要求系统记录客户的活动，因此忠诚度系统充当了从客户与公司的互动中学习的自然基础。这其中很大一部分是数据挖掘——寻找客户行为模式，这可以带来新产品和促销活动。你还可以使用此活动历史记录来评估促销活动的成功——如果你为乘坐特定航线提供里程奖励，反应如何？

与我一样，约翰是使用报表数据库的坚定支持者，这非常适合这类问题。会计方面需要一组完全不同的数据结构，并在活动发生时进行定期更新。客户体验分析都是只读的，因此你可以使用不太规范化的结构，并从会计方面定期（但不一定是实时）馈送数据。

更进一步，完全解耦会计和客户体验系统似乎是合理的。它们通常作为单个客户忠诚度系统一起存放，因为它们跟踪相同的事件。然而，由于它们在内部差异很大，因此将它们视为两个独立的系统可能更有意义，这两个系统从同一个事件流中获取数据（会计方面可能会为客户体验方面生成一些事件）。

客户体验跟踪的一个习惯是频繁更改系统以支持新类型的分析。我们推测，我们可以尝试一种方法，该方法具有一个存储的客户活动事件日志，并插入相对独立的“挖掘器”，这些“挖掘器”将从日志中转换选定的信息以创建更特定的数据结构，以进行不同类型的分析。这些挖掘器可以相对独立，因此更容易构建。

如你所见，我们的讨论确实从关注约翰的经验转变为我们的一些共同推测，即如何构建未来的类似系统。我们很清楚的是，在这个领域探索新想法的空间很大，这可以引入一组新的抽象，从而导致能够更好地支持此业务活动的系统。如今，越来越多的注意力被放在这个问题上，因此这似乎是我们工作的一个富有成效的领域。