5.9 服务设计

概述与动机

服务设计（service design）是一门塑造一个人所体验的整个服务的实践，它横跨每一个渠道、贯穿整段时间，而不只是某一块屏幕或某一个应用。当有人续办护照、开设银行账户，或者上报一盏坏掉的路灯时，他们体验到的并不是你的产品。他们体验到的是一项服务：一通电话、一个网站、一封寄来的信、一次排队、一封永远不会寄达的邮件、一位不得不把客户信息重新录入一个看不到网站已经知道什么的系统里的个案专员。第 5.1 章讨论的是设计单个界面的技艺。服务设计则把视角拉远，去看整段旅程，以及柜台背后一切让柜台前的体验得以运转的东西。

这种“柜台背后”的区分正是其核心所在。服务设计把世界划分为前台（front-stage），即用户能看到、能接触到的一切；以及后台（back-stage），即负责交付服务、却对用户不可见的人员、系统和流程。出色的前台体验经常会失败，原因就是后台无法支撑它。一份光鲜的预约表单，如果只是被丢进一张职员一天检查两次的电子表格，那就是一个快速的前台嫁接在一个缓慢的后台之上，用户感受到的这种落差，就是长达三天的沉默。设计整个服务，意味着要把前台和后台这两半一起设计，还要设计好它们之间的接缝。

对大型团队而言，这不可避免地是一个组织层面的问题。服务几乎总是横跨多个团队、部门和系统，而这些所有者之间的边界，正是用户体验开始崩坏的地方。在企业环境中，单一一条客户旅程可能会横跨销售、开通、计费和支持等多个环节，每个环节都有自己的工具和目标，却没有任何一方对整体负责。在政府场景中，风险更高：一个正在经历丧亲之痛或喜添新丁等人生大事的人，不得不周旋于十几个不同的机构之间，每一个都要求提供相同的证明材料，因为这些服务是围绕政府自身的组织结构、而不是围绕这个人的需求来组织的。服务设计，就是让整件事情为身处中心的这个人真正地串联起来。

关键原则

要跨渠道、跨时间地设计整个服务，而不是某一块屏幕。用户并不关心你的团队边界画在哪里。
前台和后台是同一个系统。一段体验的好坏，取决于其背后的运营能力所能支撑的上限。
组织架构图会体现在服务当中。如果团队是孤岛式的，服务也会感觉像孤岛，所以团队设计和服务设计必须同步推进。
渠道之间、团队之间的交接，正是服务出问题的地方。要像设计步骤本身一样，刻意地设计好这些接缝。
面向员工的工具也是服务的一部分。一名被糟糕操作台折磨得心力交瘁的客服，产出的就是一位沮丧的客户。
要端到端地衡量服务，从用户最初的意图一直到他们真正获得的结果，而不是某一个渠道的局部指标。
要围绕用户的目标或人生大事来组织服务，而不是围绕你内部的部门。

建议

跨每一个渠道绘制客户旅程

首先要把一个人为了达成某个结果所走过的真实旅程画出来，这是更广义的客户体验（customer experience）的一部分。一张旅程图会铺陈出用户所经历的各个阶段（）从最初意识到自己有某种需求，到达成目标乃至之后（）并在每个阶段记录下他们试图做什么、他们的想法和感受，以及他们当时所处的渠道。它的价值就在于跨越渠道：大多数真实的旅程会在网站、电话线路、邮件、App 和实体场所之间来回切换，而最严重的痛点恰恰藏在这些渠道之间的缝隙里，因为在那里上下文会丢失，用户不得不从头再来。要把旅程图建立在研究（第 5.8 章）之上，而不是你的假设之上，因为你想象中的旅程和人们实际走过的旅程很少是一回事。要标记出“关键时刻”（moments that matter），也就是少数几个决定体验成败的关键节点，把精力集中在那里，而不是平均分散。一段在任何单一渠道上看起来都很顺畅的旅程，从头到尾体验下来仍然可能是糟糕的，而只有跨渠道的视角才能揭示这一点。

构建一张连接前台与后台的服务蓝图

这门学科的核心制品是服务蓝图（service blueprint）。如果说旅程图呈现的是用户的视角，那么蓝图则在此基础上加上了下面的各个层次。一张典型的蓝图以水平的泳道形式呈现：最上面是客户的行动，接着是他们所接触的前台触点（touchpoint），再往下是一条“可见性分界线”，线以下是员工采取的后台行动，最下面则是支撑以上一切的支持系统和流程。从上到下读一列，你就能准确看到一个前台时刻要成立，背后必须发生哪些事情，以及如果某个系统运行缓慢或某次交接含糊不清，它会在哪里崩坏。蓝图正是你能发现那些无声失败之处：人工重新录入、隔夜批处理任务、一个自己都不知道自己是依赖方的团队。要和真正运营后台的一线员工一起绘制蓝图，而不只是和设计师一起，因为这些员工知道真正的工作发生在哪里。一张只画出理想路径的蓝图不过是装饰品；也要把失败路径和恢复路径画出来。

把后台和面向员工的工具当作一等公民来设计

要把员工使用的工具当作产品的一部分来对待，因为对客户来说，它们本来就是。当一名呼叫中心客服、一名个案专员，或者一名仓库拣货员，正在与一个缓慢、丑陋、半残废的内部操作台较劲时，这种摩擦会直接传导给他们正在服务的那个人，表现为更长的等待时间、错误的答复，以及显而易见的挫败感。内部工具长期资金不足，恰恰是因为它们的用户是“被困住”的、无法转身离开，而这正是第 5.1 章警告的：被困用户使用的软件，其代价是以错误和生产力损失的形式支付的，而不是以流失率的形式。要给面向员工的系统，配上和面向客户的系统同等水平的研究、设计和质量标准。要特别关注交接环节，也就是一个案例从一个团队、系统或渠道传递到另一个的那些时刻，因为一次被漏掉的交接，除了那个被晾在一边等待的用户之外，对所有人都是不可见的。要设计好接收方能看到什么、案例会携带哪些上下文一起传递，以及交接失败时会发生什么。

让团队设计与服务设计保持一致

要预料到，组织架构图会体现在服务当中。这就是康威定律（Conway’s law），即系统最终会映射出建造它们的组织的沟通结构，第 1.2 章对此有深入讨论。如果四个团队各自负责一段旅程中的一步、彼此又很少沟通，用户感受到的就会是四个彼此割裂、之间布满裂缝的步骤。所以服务设计和团队设计其实是同一个问题的两个观察角度，如果底层的所有权是碎片化的，你就不可能仅靠更好的界面来修复一段碎片化的体验。要用你的服务蓝图和旅程图来审视：你的团队究竟是围绕用户的旅程划分的，还是围绕内部的方便划分的，并且要愿意去重塑团队结构，或者创建一个明确拥有端到端旅程的角色，这样才会有人对整体负责，而不只是对自己那一小段负责。如果你无法重新划分团队，那至少要把团队之间的交接，变成有明确约定上下文和服务水平的显性契约。

端到端地衡量服务质量

要选择那些能跟随用户从最初意图一直到真实结果的指标，而不是那些只让某一个渠道单独看起来漂亮的指标。一个网站团队可能达到 98% 的表单完成率，而这些“完成”当中有三分之一在后台队列里悄无声息地失败了，局部指标永远不会显示出这一点。要衡量端到端完成率（这个人是否真的得到了他们想要的东西）、端到端耗时（从意图到结果一共花了多长时间，包括那些看不见的后台等待），以及付出的努力（在他们不得不使用的所有渠道上，这件事有多难）。要把运营数据和对真实体验感受的直接了解结合起来，无论是通过一次交易后调查、一道类似净推荐值（Net Promoter Score）的问题，还是持续性的研究。要格外关注渠道与渠道之间的流失，因为这些接缝正是衡量出的质量和实际感受到的质量分歧最大的地方。要把这些服务指标和产品管理的成果追踪（第 10.14 章）连接起来，这样数字才能驱动优先级排序，而不是躺在一个没人会去采取行动的仪表盘里。

权衡：利与弊

方案	利	弊
端到端的服务所有权（一个团队拥有一整条旅程）	责任清晰，体验连贯，接缝会被认真设计	打破现有组织结构，配置人员和资金困难，可能形成瓶颈
按渠道或按步骤划分所有权	契合现有团队，局部范围清晰，易于配置人员	没有人对整体负责；渠道之间存在缝隙；容易陷入局部优化
前期做完整的服务蓝图	能在上线前暴露后台的失败点，形成共同的理解	耗费时间，容易过时，有“分析多于行动”的风险
只做轻量级的旅程图	快速、低成本，足以发现最严重的缺口	会漏掉蓝图才能捕捉到的后台和系统层面的失败
全渠道（omnichannel）一致性（跨渠道统一）	交接无缝衔接，上下文能跨渠道传递	集成成本高昂，需要共享数据和团队协同一致

核心张力存在于用户真正需要的服务（）它贯穿你的各个边界流动（）与你实际拥有的组织（）它是沿着这些边界画出来的（）之间。要按比例地、而不是教条地来解决这个矛盾。你不需要为了设计好一项服务就重组整个公司，但你至少需要有一个人或一个团队对端到端的结果负责，手握一张能让后台可见的蓝图，并拥有修复接缝的职权。要把最重的蓝图绘制工作，投入到那些高流量、高风险或高失败率的旅程上，其余的则使用更轻量的旅程图。目标不是打造一份完美的制品；而是打造一项对身处中心的这个人真正管用的服务。

与团队讨论的问题

谁端到端地拥有整项服务，从用户最初的意图到他们真正获得的结果，这个人实际上又拥有多大的权力？ 在大多数大型组织中，诚实的答案是“没有人”，因为所有权是按渠道和部门拆分的，每个所有者都只按自己那一段被考核。这个空白正是服务失败的地方，因为所有者之间的接缝不属于任何人，也就得不到任何关注。要决定是否设立一个明确的端到端所有者，比如服务所有者或旅程所有者，并且要说清楚，这个人是否真的能够改变后台系统和团队边界，还是仅仅对一个他们根本无法撬动的指标负责。把你目前的组织架构图和你最重要旅程的蓝图并排摆在一起，看看谁接触了这段旅程，谁又对它负责。如果两者对不上，你就找到了你最严重的交接失败的根源。这个问题的答案，应该改变你们如何为这项工作配置资金和人力，而不仅仅是谁来参加站会。
我们的团队是围绕用户的旅程划分的，还是围绕我们内部的方便划分的，我们愿意为此做出改变吗？ 康威定律（第 1.2 章）意味着，无论你是否有意为之，你的服务都会映射出你的沟通结构，所以一段被拆分给四个互不沟通的团队的旅程，感受起来就会是四个彼此割裂的步骤。舒适的做法是修一修界面，不去动组织架构图，但这只是在治疗症状，而病因会不断地重新制造出同样的问题。要诚实地审视：你的团队边界，是否恰好制造出了用户抱怨的那些交接缺口，并权衡重塑团队的真实成本，与一段碎片化体验所带来的持续成本。把你旅程图中的痛点拿出来，逐一检查有多少恰好落在某个团队边界上。如果大多数都是，那么更好的界面救不了你，讨论就必须转向团队设计。你在这里做出的决定，决定了你的服务改进能否真正扎根，还是悄悄地被侵蚀掉。
我们面向员工的工具，在多大程度上服务好了使用它们的人，这又是如何反映到客户身上的？ 在任何大型组织中，内部工具都是最稳定地被忽视的软件，因为它们的用户是“被困住”的，它们的预算也总是事后才想起来的，然而一名与残破操作台较劲的个案专员或客服，会把这种摩擦直接传导给客户，表现为延迟和错误。要问问自己，你们上一次针对自己面向员工的系统做研究是什么时候，还是你们只是假设，既然员工是拿薪水来应付这些问题的，工具就一定没事。要考虑到，大多数无声的服务失败其实恰恰发生在后台（）发生在人工重新录入和交接时丢失的上下文中（）而这一切前台指标都看不到。把一位真正的员工请到会议室里，看着他完成一项日常任务，然后追踪他的困难是如何传导到客户身上的。如果你们从来没有像对待产品那样为内部工具投入资金，这很可能是你们能找到的、提升端到端服务质量最便宜的一项重大改进。
哪一个单一的端到端指标，能够告诉我们整项服务是否真正管用，我们今天为什么没有追踪它？ 对大型团队来说，这个问题令人不安，因为诚实的答案通常是：每个渠道和部门都有一个绿色的局部指标，却没有人衡量这个人是否真的得到了他们想要的东西。表单完成率、通话处理时长和工单关闭数，都会让上报它们的所有者看起来很不错，而每一个都可能保持健康，与此同时整体串联起来的结果却在后台队列里失败。要确定一个能跟随用户从最初意图到真实结果的端到端完成率或端到端耗时指标，并说清楚谁将负责在那些从来没有被设计成能共享数据的系统之间为它打点。把当前各渠道的仪表盘、一条高流量旅程的蓝图，以及渠道之间无声流失的估算数字都拿出来，让局部的“绿色”和端到端的“红色”之间的差距变得看得见。在企业和政府场景中，要就谁对整条旅程的数字负责、谁有权基于它采取行动达成一致，因为一个没有任何单一所有者能够撬动的指标，是一个不会改变任何事情的指标。
我们的服务在哪些地方强迫用户一再重复自己，一个“只需告知一次”的版本，建设成本会是多少？ 重复的数据采集，是一项服务围绕你内部边界、而不是围绕用户需求来组织的最明显信号，而且它在双方身上都很昂贵：用户在每一次交接时都要重新提交同样的证明材料，而每个部门都要为重新收集和重新核实这些材料付出成本。与之相对的考量是，使“只需告知一次”成为可能的共享记录，需要在那些可能从来没有相互信任对方数据的历史的系统和团队之间进行集成，所以建设成本和数据治理方面的工作都是真实存在的。把一张标注出用户在哪些地方提供了你已经掌握的信息的旅程图拿出来，粗略统计一下有多少个独立的记录存储着同一个字段。对于一项横跨多个机构的政府服务，还要补上在这些机构之间共享数据的法律依据，因为同意、隐私法和信息治理规则，决定了“只需告知一次”在你考虑是否负担得起之前，是否根本上就是被允许的。
当上下文在团队、系统或渠道之间被交接时，实际上有什么会随之传递，交接失败时又会发生什么？ 交接正是服务无声崩坏的地方，因为除了被晾在一边等待的用户之外，这种失败对所有人都是不可见的，而在一个大型组织中，每一次交接都跨越一道边界，在那里没有任何单一所有者会为丢失的东西感到责任在身。要刻意决定，哪些数据、历史和状态必须随案例一起传递，接收方能否看到它们，以及当一次转移卡住或到达时不完整时，恢复路径是什么。把你针对一条真实旅程的服务蓝图拿出来，逐条追踪案例被交接的每一处，标注出哪些上下文被保留了下来，哪些被重新录入或丢失了。在受服务水平协议或法定响应时限约束的企业和公共部门服务中，要把每一次交接都当作一份有约定上下文和明确兜底方案的显性契约来对待，因为一次没有文档记录的交接，就是一场没有任何仪表盘会提前警告你的、迟早会发生的违约。

行业视角

初创企业。 人手不多，也没有时间做繁复的制品，所以只画出那唯一一条承载核心价值的旅程，而且只画到足以看清前台在哪里交接给一个缓慢或人工的后台就够了。要在一个下午内在白板上完成，而不是把它当成一项为期六周的研究。你的优势在于，整项服务装在几个人的脑子里，所以修复一次失败的交接，只是一次对话，而不是一场跨部门谈判。要在你的边界扩张到让交接变得昂贵之前，用好这个优势。

小型企业。 你没有服务设计师，也没有预算去雇一个，所以务实的做法是自己以客户的身份走一遍自己的旅程，记下每一个你让别人重复自己、或者卡在人工步骤上等待的地方，然后修复其中最严重的那一个。优先选择那些已经能够打通你各个渠道的工具（比如一个共享收件箱、一个会通知员工的预约系统），而不是自己搭建一套你维护不了的集成。买系统的时候，要权衡它把上下文交给下一个环节的能力有多好，因为一个便宜的工具，如果在销售和履约之间丢失了客户的信息，它给你带来的复购损失，会远超它省下的那点钱。

企业。 核心问题在于，单一一条旅程横跨销售、开通、计费和支持，每一个环节都有绿色的局部指标，却没有任何一方对整体负责。要为你们高流量、高风险的旅程投入完整的服务蓝图绘制，任命一位对接缝拥有权限的端到端所有者，并标准化一个能经得起审计、能驱动各团队优先级排序的端到端指标。要把共享的案例记录和面向员工的操作台当作有资金投入的产品来对待，并让每一次跨团队交接都成为有约定上下文和服务水平的显性契约。

政府。 服务必须围绕公民的人生大事来组织，而不是围绕机构自身的结构，并且要以透明和对公众负责的方式，遵循公开发布的服务标准。采购规则会塑造你能建设什么，所以在数据共享具备法律依据的地方，要优先采用共享记录和“只需告知一次”的模式，并在设计流程之前先把这一依据记录清楚。要和真实用户一起做研究，包括最弱势的群体，绘制跨机构的后台蓝图，并衡量整条旅程，而不是每个机构各自的那一小段，因为公众评判一项服务的标准，是他们是否得到了结果，而不是哪个部门完成了自己的任务。

示例

初创企业。 一家十人规模、销售家庭保险产品的初创企业，一直把自己看作一家做 App 的公司，它的 App 确实做得不错。但流失率居高不下，支持团队也不堪重负，于是创始人们绘制了真实的理赔旅程蓝图。他们发现，真正的服务时刻发生在客户半夜水管爆裂的那一刻：App 把请求交接给一个邮件队列，邮件队列再交接给一位客户看不见的第三方查勘员，这位查勘员会在工作时间用一个未知号码回拨过来，而这个号码最终进了语音信箱。光鲜的前台架在一个缓慢、不透明的后台之上，而那个“关键时刻”（）一次充满压力的理赔（）恰恰是失败发生的地方。修复交接环节、让客户能够看到查勘员这一步的进展，并把理赔工作流当作产品的一部分来对待，对留存率的提升，比任何一项新的 App 功能都更有效。

企业。 一家电信公司在销售企业互联网服务时，线上下单只需两分钟，交付过程却是长达两周的噩梦。销售、开通、现场工程和计费各自负责旅程中的一段，各自都达成了自己的目标，而客户体验到的，则是反复被要求提供同样的信息、被错过的预约时段，以及一份和报价对不上的首期账单。跨越全部四个部门的服务蓝图绘制暴露了这些接缝：由于没有任何共享的订单记录随客户一起流转，上下文在每一次交接时都会死掉。公司任命了一位从下单到开通的端到端所有者，建立了一份随订单一起流转的共享案例记录，并围绕串联起来的整体结果重新设计了团队激励机制。局部指标几乎没有变化；而端到端的开通时长和投诉率都大幅下降。

政府。 一个国家的政府重新设计了它的“家庭成员去世”服务，这是公民要面对的最艰难的人生大事之一。此前，丧亲者不得不分别通知税务机关、养老金服务机构、车辆管理机构、护照签发机构和地方政府，每一个机构都有自己的表格，每一个都要求提供同一份死亡证明。团队围绕这一人生大事、而不是围绕各个机构来组织服务，建立起了一条单一的“只需告知一次”旅程，它把一个人填写的信息，在可见性分界线以下分发给每一个相关部门。为了与公共部门的服务标准保持一致，他们与近期经历丧亲之痛的人一起做了研究，绘制了跨机构的后台蓝图，并衡量整条旅程，而不是各个机构各自的部分。完成率上升，重复联系的次数下降，公民也不再需要把丧亲之痛重新经历十几遍。

商业论证：动机、投资回报率与总拥有成本

服务设计的回报来自于弥合渠道之间、团队之间的缺口，因为那正是价值流失的地方。端到端的失败带来的代价，往往是按渠道划分的仪表盘所无法呈现的：一段旅程在线上完成了，却在后台失败，这会带来一次支持联系、一次返工，往往还会带来一位流失的客户，而这些代价没有一项会落在那个看起来“成功”的渠道头上。当你端到端地衡量并修复整项服务时，你减少的是重复劳动（同一份数据被采集了五次）、失败需求（纯粹由于服务第一次就没做好而产生的联系请求），以及那些即便每个部分在技术上都正常运转、却仍然感觉支离破碎的体验所导致的流失。在企业场景中，回报体现为更短的订单到回款周期、更少的升级事件；在政府场景中，回报体现为更低的服务成本，以及那些人们无处可去的服务，其成功完成率的提升。

总拥有成本，必须把做服务设计的成本，与你已经背负着的碎片化所带来的、远为庞大的成本进行权衡。看得见的成本，是研究、蓝图绘制、跨团队协调，有时还包括对共享系统和员工工具的投入。而不去做这件事所隐藏的成本，则分摊在支持预算、运营和声誉损害之中，这正是领导层低估它的原因：没有任何一个团队的预算能够反映出一次失败交接的全部代价。要说服领导层，就在一条高流量的旅程中，给失败需求和重复劳动标出一个具体的数字，绘制它的蓝图，并向领导层展示，这些成本有多少其实就藏在他们现有团队之间的接缝里。然后在这条旅程上开展一次有边界的试点，前后端到端地测量，用结果去争取更艰难的结构性改变。把服务设计定位为消除那些已经在被悄悄支付、只是不可见的成本，往往比任何关于“优雅”的诉求，更能打动财务和治理方面的利益相关者。

反模式与陷阱

渠道孤岛。 每个渠道都被独立设计、独立衡量，于是这段旅程处处看起来都还不错，端到端却没有一处真正管用。
前台的口红。 一个光鲜的界面被嫁接在一个缓慢或人工的后台之上，一旦用户需要后台响应，体验就会崩溃。
把组织架构图当服务。 服务是围绕你的部门、而不是围绕用户的目标来构建的，迫使用户去应付你内部的边界。
蓝图戏法。 精心绘制的蓝图只画过一次，被欣赏一番，却从未被用来改变服务实际的运行方式。
只画理想路径。 旅程图和蓝图忽视了失败和恢复路径，而那恰恰是真实服务真正伤人的地方。
被忽视的员工工具。 把面向员工的内部系统当作二等公民对待，于是它的摩擦会直接渗透到客户身上。
交接失忆症。 上下文在团队、系统或渠道之间的每一次转移中丢失，用户不得不一遍又一遍地重新解释自己的处境。
让人好看的指标。 局部的、按渠道划分的目标始终保持绿色，而端到端的结果却在无声无息地失败。

成熟度模型

第 1 级，启动： 每个渠道和团队都各自孤立地、被动地设计和运行。没有人拥有端到端的服务，没有旅程图，也没有蓝图，后台的失败一直不可见，直到以投诉的形式浮出水面。用户会在不同渠道之间反复重复自己，因为没有人审视过整体。
第 2 级，发展： 部分旅程已经被绘制出来，最严重的跨渠道缺口也已被知晓，但这项实践参差不齐，取决于个别人的热情。旅程图存在，却很少延伸到后台，所有权仍然是按渠道划分的，面向员工的工具是事后才想起来的，即便有蓝图绘制工作，各团队之间的做法也各不相同。
第 3 级，标准化： 关键旅程会与运营员工一起，用一套在全组织内一致执行的、有文档记录的方法，从前台到后台完整地绘制出来。指定的服务所有者对端到端负责，交接是有约定上下文的显性契约，员工工具经过刻意设计，这套做法被强制执行，而不是可选项。
第 4 级，管理： 服务被以数据的方式衡量和控制。端到端完成率、端到端耗时（包括看不见的后台等待）、用户付出的努力、失败需求，以及渠道之间的流失，都会与基线进行对比追踪，交接失败和重复的数据采集会被量化，而不是被假设。蓝图会被持续更新，服务所有者要对端到端目标负责，变更的通过或否决决策依据的是这些证据，而不是局部的渠道指标。
第 5 级，协同优化： 团队设计和服务设计相互对齐，所有权跟随旅程走，组织是围绕用户的目标和人生大事、而不是围绕部门来构建的。端到端指标驱动优先级排序，组织持续地绘制蓝图、衡量并共同重塑体验和运营，并随着用户需求、渠道和跨团队边界的变化而调整整项服务。

讨论话题

当一段旅程横跨多个团队时，任命一位端到端所有者更好，还是围绕这段旅程重新划分团队更好，决定这一选择的因素是什么？
你们的服务质量有多少能够通过更好的前台设计来修复，又有多少需要改变后台或组织架构图？
在你们的服务中，用户最常在哪些地方不得不重复自己，一个“只需告知一次”的版本，建设成本会是多少？
当面向员工工具的用户是被困住、无法用脚投票的，你们如何为这些工具提供资金和优先级排序？
即便这会直接冲击你们的资金和汇报线，服务是否应该围绕人生大事或用户目标来组织？
哪一个单一的端到端指标，最能告诉你们整项服务是否运转良好，你们今天为什么没有追踪它？

关键要点

要跨渠道、跨时间地设计整项服务，而不是某一块屏幕，并且要记住，用户并不关心你的团队边界画在哪里。
前台和后台是同一个系统；一段出色的体验，好坏取决于其背后的运营所能支撑的上限。
服务蓝图是你的核心制品：它把前台触点，与交付这些触点所需的后台人员、系统和交接连接了起来。
组织架构图会体现在服务当中（康威定律），所以服务设计和团队设计必须同步推进。
要把面向员工的工具和团队之间的交接，当作服务中一等公民的组成部分来对待，因为它们的摩擦会传导到客户身上。
要端到端地衡量服务，从最初的意图到真实的结果，并围绕用户的目标或人生大事、而不是围绕你的部门来组织服务。

参考文献与延伸阅读

Marc Stickdorn 和 Jakob Schneider，This Is Service Design Thinking
Marc Stickdorn、Markus Edgar Hormess、Adam Lawrence 和 Jakob Schneider，This Is Service Design Doing
Andy Polaine、Lavrans Lovlie 和 Ben Reason，Service Design: From Insight to Implementation
Lynn Shostack，“Designing Services That Deliver”，Harvard Business Review
Matthew Skelton 和 Manuel Pais，Team Topologies
Melvin Conway，“How Do Committees Invent?”，Datamation
英国政府数字服务（UK Government Digital Service），Service Manual 与 Service Standard
美国联邦总务署（U.S. General Services Administration），18F Methods 与美国数字服务局（U.S. Digital Service）的 Playbook
Nielsen Norman Group，关于服务蓝图绘制与客户旅程图绘制的系列文章