DDD:Blueprint(服务蓝图)

领域驱动设计系列

Posted by Shoukai Huang on March 5, 2020

1 相关概念

定义

前文介绍过用户旅程地图,它是一种能帮助利益相关者更好地理解随着时间变化,用户如何跟他们的产品或服务之间互动的工具。而服务蓝图不仅包含了用户的全部旅程,也包含了能让旅程可行的所有交互过程。

旅程地图聚焦于你的用户在前台端到端的体验,服务蓝图聚焦于由表面到核心的后台业务以及如何交付和操作的幕后,并且与用户体验联系起来。

服务蓝图展示的是企业在为特定用户提供一款产品和服务的过程中,每个阶段服务执行的效果,是详细描述服务系统的图片或地图,服务过程中涉及到的不同人员可以理解并客观使用它,而无论他的角色或个人观点如何。

服务蓝图直观上同时从几个方面展示服务:描绘服务实施的过程、接待顾客的地点、顾客雇员的角色以及服务中的可见要素。它提供了一种把服务合理分块的方法,再逐一描述过程的步骤或任务、执行任务的方法和顾客能够感受到的有形展示。

场景

服务蓝图适用场景

  • 找出服务流程的崩溃点以及可优化点。
  • 传达一项新服务的执行计划。
  • 衡量服务执行过程每一步是否达标。
  • 定义一个服务点或触点是高接触还是低接触。

2 构建方法

建模方法

服务蓝图(Blueprint)建模的基本思路是:

  1. 借助于流程图,通过分解服务组织的系统和架构,鉴别用户与服务人员以及服务体系内部的服务接触点;
  2. 在服务流程分析基础之上描述服务传递的各个方面,将服务提供过程、员工和顾客的角色、服务的有形证据直观地展示出来;
  3. 经过服务蓝图的描述,服务被合理地分解成服务提供的步骤、任务和方法,使服务提供过程中所涉及的人都能客观地理解和处理它。

内容解析

一个正规的服务蓝图有三个基本元素:

  • 互动线:客户和服务之间的互动点。
  • 可视线:超过这条线就是用户看不见的服务。
  • 内部互动线:在这条线以外,内部业务终止了,取而代之的是合作者的介入。

这三条线隔出的5条泳道体现了服务的基石:

  • 实体证据(译者注:图中最上面那一行就是实体证据):指的是顾客服务旅程图中会接触的物料和场所。
  • 顾客行为:指顾客为了获得服务而不得不做的事情。没有顾客的行为,就根本没有服务!
  • 前台:顾客在体验服务旅程中能够看到的所有活动、人员和实体证据。
  • 后台:所有的不被用户看到但是为提供服务而必须存在的东西。
  • 支持过程:记在互动线下的支持服务的活动。

附件泳道

为了表达得更清楚,我们推荐一些附加的泳道:

  • 时间:服务的提供伴随着时间的消耗,服务蓝图中的一步可能需要5秒,也可能需要5分钟,所以在顶部增加的时间能帮助大家更好的理解这个服务。
  • 质量衡量:服务的成功或价值需要一些体验因素来衡量,这些因素是用户在心里判断服务是成功还是失败的关键时刻。比如,等待时间。
  • 情绪旅程:对某些服务来说,理解用户的情绪状态是非常必要的。比如,在急诊室里,用户的恐惧心理必须列入考量因素。
  • 拆分前台:当多个接触点同时一起工作来提供服务体验时,最好将每个接触点拆分到单独的泳道(如,用户与数字设备的互动和用户与服务人员的互动)。
  • 拆分后台:后台可以是由人,系统,甚至设备构成。对于细节的或聚焦于局部的服务蓝图,将后台拆分成内部员工、应用、数据和基础设施能区分出不同领域的服务。
  • 服务体验周期的各阶段:服务是随着时间展开的,如果按体验周期的各阶段来呈现,则服务会更清楚。例如,顾客是如何被吸引来,怎么开始用服务,体验服务,结束使用,然后有可能再次重新开始使用服务而变成回头客。
  • 主要互动行为的照片/草图:增加这条能帮助读者用看漫画书的方式快速了解这些服务是如何随时间展开的。

补充注释

研究和实地观察对绘制蓝图是非常必要的。如果我们要讨论在现有流程中,用户和内部员工做了哪些有用哪些没用的事情,记住蓝图是一种强大的方式。那些关键点可以以很多方式来突出,但我们还是建议使用带图例的icons 来呈现,这样更简单明了。

3 实践示例

一家“互联网+集体出行”创业公司,其主营业务是“定制班车”。与常见的大型公司通勤班车的主要差异在于,定制班车不是只为限定的公司提供服务,而是向社会开放,充分利用大巴车的运力资源。从用户的角度来看,典型的通勤乘车流程一般为:用户在乘客端(APP/微信公众号)查询线路——购票——前往停车点——找车上车——出示车票——舒适乘坐——下车。搜集完成相关信息后,很容易绘制出通勤班车服务蓝图如下

运营中心也将“乘客无法上车”做为服务管控的核心关注点,与服务蓝图的分析结果是一致的。

通过赔付规则来解决“乘客无法上车”执行了一段时间之后,用户投诉量有所下降,但并没有特别明显的改变。与此同时,其副作用也开始逐渐发作:由于运营手段是靠“惩罚”来规范服务,时间一长,与供应商之间的关系开始紧张,我们不得不重新审视这个事情:如果说处罚是发生在事后的补救措施,显然服务事故是平台、车企(供应商)和乘客都不愿意看到事情,那么,事中是否可以采取措施来纠正差错?事前又有没有手段可以规避问题发生呢?带着这两个问题,我们再次观察服务蓝图,从中发现了几个问题:

1。 主动服务流程有“断点”。基于体验设计的基本规则,在一个完整的流程中,不应当出现“用户不知道自己该干啥/需要等多久”的体验流程断点(参考唐纳德-诺曼的《设计心理学》一书)。而我们的服务流程中,却有好几处这种问题:

* 用户买好车票后,不知班车是否如约正常运行,心里没底;
* 用户已到达停车点,不知什么时候该留意来车,沉迷玩手机错过班车;
* 用户上车后,可能因为补觉(早班车很常见)坐过站;
  1. 关键节点的有形展示,不够到位。通勤班车都运行在上下班高峰时段,大家很容易想象得到,高峰时期的公交车站是什么样的一个场景。而长期以来,辨识班车最靠谱的标识,就是车牌。当然平台上运行的班车原则上都需要配置有车贴标识,但因线下运营的一些实际困难很难做到位。这样一来,用户在公交站台的茫茫车海中,时不时会因为看不到车牌(目标太小)而错过班车。

根据以上两点结论,我们对服务流程进行了升级改造,升级后的服务蓝图如下:(橙色部分为新增内容)

具体来讲,我们增加了这几个服务节点:

  1. 正常发车时,会对该班次全部购票用户推送发车通知;
  2. 车辆即将到站的时刻,发送到站消息;
  3. 提供下车提醒服务(由程序自动完成);
  4. 提供车辆外观形象,帮助用户找车;

资料