‘应时’智慧服务框架/‘On-Time’ Intelligenc
前言
航司如何敏捷及即时的为旅客提供适合场景的服务，即“应时”旅客服务，关键在于在现有触点之上，打通各类系统及应用，尤其是数据；且需要让数据能够流动，并准实时的被航司的服务框架捕获及智慧的响应。航司的产品、内容、服务等，如何精准的投放在特定的客户及特定的场景，不仅仅是需要菜单型的产品及服务单元，更需要数据处理技术及人工智能等的应用，更关键的需要：On-Time Intelligence Service Framework。
业务思路
在现有的航司即有实体触点的基础上，使用电商平台的通知服务，善用在电商服务机会期，构建更精准的数字化触点，以期投放更优质服务和产品，获得更多的收益和赢得更高的忠诚度。
框架全景
为了实现即时的一系列基于数据变化的动作，则需要框架本身是基于数据流处理，且融合旅客信息或Single Customer View，航司各类业务数据，以个性化订阅发布模式，按照结构化及动态业务规则进行定制化事件触发及响应，并投放在客制化的各类渠道上，以期按照时间、地点、人物编排一系列应用场景和连贯动作序列。
建设内容
围绕客户为中心整合机票、酒店、运价和航班等数据，通过数据分析、客户订阅等方式提供实时、应时的全时客户服务，提高客户满意度和航空公司机票和附件服务产品的销售转化率，提高航空公司客户服务品质。
a) 建设基于数据流采集的服务事件触发及采集体系。
b) 建设基于消息队列的旅客服务串联渠道。
c) 建设基于规则引擎的旅客服务规划，编排，管理中心。
d) 建设基于数据及科学计算模型和算法的旅客服务智能模块。
即：即时获悉全面的旅客行程变化、合理编排通知形式的服务触点、精准旅客分群输入、通知类服务产品定义、旅客服务通知场景编排、微服务标准化体系构建、IT运维及业务应用监控监控。
旅客行程数据使用：基于订单的状态变化，捕获旅客行为及出行时点，产生业务事件。
航司即有触点数据使用：基于即有电商触点，捕获旅客行为及出行时点，产生业务事件。
第三方数据使用：根据业务场景需要及服务内容，获取第三方数据的实时或被动数据，供服务通知产生及服务内容打包使用。
电商顾客细分群体数据导入及精加工：导入Single Customer View及业务数据或精准营销产生的顾客细分群体及标签，之后根据电商通知服务的能力和场景设计，筛选及精加工旅客群体。
通知服务规则制定及场景编排：以可视化方式让业务人员设计通知规则，顾客细分群体的投放，尤其是业务场景的编排及设定。并将其转换为结构化的规则存储，用于后续通知服务的后台打包及生成。
通知服务后台打包及生成：在已经捕获的业务事件驱动的前提下，根据上述定义的规则和场景，进行通知服务序列的生成，通知内容和数据的打包，保存进待推送存储中待发。
通知服务推送：对接现有航司通知服务推送基础架构，实现最终的闭环通知服务。额外增加电商的触点。
通知服务业务规则制定：通过电商业务和旅客服务专家的分析，及对于现有旅客分群的特征工程分析，确定和设计业务规则的结构和内容。
通知服务业务场景编排：通过电商业务和旅客服务专家的过往经验，设计和编排可行的场景应用，以及数据和通知服务序列。
通知服务打包OR优化：除IT架构和技术实现外，需要对业务规则使用及通知序列的生成，结合业务场景的状态，优化打包效率，以期更实时，更广泛的使用更复杂的业务场景和规则组合。
业务场景
罗列几个Use Case场景，从而为航司打造“更高的忠诚、更优的服务、更多的收益、更好的航司”等综合的旅客服务体系。
a) 出行贴心小秘书 – 更高的忠诚
b) 退改签服务助手 – 更优的服务
c) 竞价升舱 – 更多的收益
d) 低价预警 / 售罄通知（锁价宝） – 更好的航司
HLSD & TD
如下简要阐述一下High-Level Solution Design和Technical Design的内容。
a) Logical Architecture
b) Rule Matrix & Block & Path, Service Sequence
c) Business Event, Rule Engine
d) Inbound Trigger, Outbound Fulfillment
结论
航司的服务及架构模块，不仅仅需要按照DDD的思路进行微模块微服务的架构优化，更关键的是需要以动态或流动处理的方式，构建一系列针对场景和数据应用的平台框架，将各类资源（数据、系统及应用、服务、接口、外部及内部资源、线上线下等等）有机的融合在一起，构建处理应时旅客诉求的应时智慧服务框架。
