上周，我们从亚马逊“以用户为中心”的使命出发，介绍了贝索斯的问号邮件，并详细解析了反馈闭环的步骤及善后复盘。反馈闭环的四个步骤分别为:搜集反馈、明确问题、处理反馈、回复用户。本周，我们将用一个具体案例说明亚马逊如何完成反馈闭环中的每个步骤，并阐述构建成功的反馈闭环的三个关键因素。

四、 亚马逊反馈闭环案例：网售图书

当一本书被卖出时，这项销售记录会反映在亚马逊内部的记录系统中，同时书的卖家（Seller，往往同时也是作者）也会在自己的亚马逊账户中看到这一记录。一天，一位热销书卖家发现他销售的书出现了异常，销售量为0。他感到非常奇怪，因为平时这本书一天能卖出几十甚至上百本，这天却突然一本也没卖出去。于是，他立即通过网站上的卖家支持（Seller Support）功能反馈这一问题并求助，这一路径相当于直接通过客服团队反馈用户声音。

卖家客服接到该用户的反馈，立即创建了一个工单（Ticket）记录下这个案例，并通过内部CTI*工具定位到了直接负责这个问题的技术组，接着通过邮件联系了该组的待命对接人（On-caller）确定了这个问题确实由这个组负责。（*这里提到的CTI工具是Category/Type/Item的缩写，是通过选择反馈问题符合的细分类别确定处理负责团队的一种精细定位工具，后文将有详细介绍。）

被客服联系到的小组是个性化推荐（Personalization）团队下面的一个负责图书排名（Book Ranking）的数据仓储技术小组（Data Warehouse Technology Service）。该组待命人接到这个Case后通知了经理，经理又把该问题分配给一位组内成员（Ticket Assignee，通常就是待命人）负责。他分析过具体的问题后，制定了解决此问题的行动项和时间表，并把这些内容发布在内部TT*平台上。解决问题的过程中，他也将处理此工单的工作进度放在了TT平台的工作记录（Work Log）里，以便相关组也可以随时查看处理的状态和流程。（*TT是一个跟踪工单处理状态并服务于各相关组交流的平台，后文将有详细介绍。）

在这个案例中，处理问题的技术人员发现问题的根源在于数据源。系统在做图书销售数据预处理时，用户买过的书没有显示在销售记录（Sales Log）里，或者说销售记录没有包含全部、精确的信息。于是他人工导出了精确的数据并将这些数据放在相应的表格里，并且给系统增加了完整性检查（Sanity Check）和预警机制（Alarm Mechanism），确保下次当数据源异常的时候能够第一时间被发现。处理完这些之后，这位技术员把TT平台上该工单的处理状态更新为“成功解决”。

当客服收到技术组的邮件消息并从TT平台上得知问题已经处理完毕后，便立即把处理的结果告知了提出反馈的卖家用户。

通过深入学习亚马逊的反馈闭环，我们总结出以下三个反馈闭环的成功因素：1）自上而下，以用户为中心的公司文化，2）分工明确的机制，完善高效的系统，和3）深入根源、及时细致的善后复盘。

对亚马逊或贝索斯多少了解一些的人会发现，贝索斯是一个追求完美用户体验的企业家。在各种公开场合接受采访时，贝索斯都会强调文章开头提到的亚马逊的理想是成为“地球上最以用户为中心的公司”，并能成为其他完全不同行业企业的模板，希望其他行业的企业能说出“希望在我们自己的行业也实现那样卓越的顾客体验”。为了使用户的利益和体验最大化，他还力推亚马逊采用从顾客需求出发的“逆向工作法”（Working backwards），来了解用户需求，耐心探索，不断磨练，直至找到解决方案。甚至在公司开会时，贝索斯还会刻意留下一把空闲的椅子，告诉与会人员必须考虑正坐在这把椅子上的消费者的感受。“那是现在这个房间最重要的人物。”贝索斯总是这样对与会人员强调，提醒他们保证用户的利益才是亚马逊一切工作的根本。

于是，贝索斯倡导的这种以用户为中心的公司文化，就从公司的最高管理者开始，自上而下在内部传递。这种来自最高层不断强调的声音（Tone of the Top）往往会在公司内部形成巨大效力，加上宣传部门的推广和中层领导做决定时的身体力行，其他层级员工不断耳濡目染，很难不被这种“用户至上”的文化及价值观影响。另外，亚马逊有500多个量化的指标来衡量运营表现，其中80%以上的指标都是围绕用户需求来制定的。这种体制和制度上的完善，如将用户体验与运营表现、员工评价直接关联挂钩，更使得员工们出于所在部门和个人被认可和提升的考虑极度重视用户体验。

从之前的介绍我们可以看到，亚马逊内部有分工明确的机制与完善高效的系统，彼此之间相互协作，在反馈闭环中起到了极好的基础铺垫和技术支持作用。接下来，我们会重点介绍几种在亚马逊反馈闭环中运作成功的系统或机制，以及它们各自所起的作用。

1) 工单系统（Ticket）：帮助部门间有效传递案例信息，同时能确保问题在一定时限内被解决的重要工具。例如，当客服接到用户反馈的问题时，会自己创建一个工单，指派给相应技术组来协助，若有依赖组，会在工单中的对应处（Correspondence）提及，并请求对方协助。工单系统会根据问题的严重程度将工单分为5个等级，从高到低分别是（SEV-1）关键功能失效、（SEV-2）影响关键功能、（SEV-3）影响团队生产力、（SEV-4）影响员工生产力、（SEV-5）对生产力无直接影响。从问题分级中可以见到，发出SEV-1、SEV-2级工单时，是直面外部用户等级的功能性问题，很有可能因此而发生掉单的情形,所以必须立即处理。另外，一般工单有5个状态，分别为已指派、研究中、工作进行中、待定、已解决。不同分级的工单对应不同的工单状态有不同的处理时限，如果工单负责人没在状态时限内完成相应任务，可能会被向上通报至直接领导。

2) 待命机制（On-call）：一种保证全年任意时间发生任何问题时，每个组都有待命的负责人能解决问题的机制。在亚马逊，每个组都会有个待命轮值表（Support Order）。此表不仅明确排定每天24小时待命负责人，也会详细记录找不到当日待命负责人的情况下，下一个应该负责待命的员工。如此一来确保问题无论在发生在何时，总有人能负责承担问题。通常待命人在待命时间内若接到外部传递的问题（如：工单）会立即着手处理，自己原本的工作会由其他组员接手。

3) 任务分类工具（CTI）：一种通过选择事件细分类别而确定处理负责团队的一种精细定位工具。C、T、I分别为Category（类别）、Type（类型）、Item（项目）三者的缩写，彼此是附属层级关系，其中，类别的层级最高，包含类型与项目。在CTI上，只要选定好用户反馈问题的类别、类型、项目，就能找到与问题关联性最大的负责团队。CTI存在的重要前提是公司内部有着非常明确且详细的组织架构和分工图，并且每个部门或团队负责的事务相对独立且没有重叠，这样才会保证责任定位的精准。CTI确保了责任人追溯的到位，省去了在确定责任人时很多的调查、沟通成本，提高了反馈闭环的效率。

善后复盘一般发生在用户反馈闭环步骤完成之后，但却是是用户体验管理的一项重要环节。合理运用善后复盘机制可以提高反馈闭环的效率与质量。

接下来我们会简要介绍5 Whys方法论。这个方法旨在找到问题的根源，并找出出现问题的原因与影响之间的联系。它使用起来非常简单——针对问题本身，通过一直问“为什么”(Why)，直到找到可自主采取的改进作为才可以停止。

大量的实证观测经验表明，经过五次以上“Why”的提问迭代，我们大部分时候都会找到正确的问题根源；相反地，不使用这个方法找到的问题根源，特别容易误导改进作为的方向，或者也许能够解决短期问题，却导致类似问题在更远的长期重复出现。因此，这个5 Whys方法论能够深入挖掘问题，避免只解决表面问题，或者改进方向错误的情况。

2) 复盘还需要及时、细致。例如亚马逊规定，COE需在反馈闭环之后马上撰写，以确保撰写人记忆犹新，对事件描述准确。另外，亚马逊的许多部门在每周的运营会议上，都会要求对当周遇到的问题案例进行复盘学习，这使得每个重要事件都能在反馈闭环完成后的一周之内进行复盘，同时确保了COE的撰写和归档的时效性。

而复盘的细致性则可以体现在亚马逊对COE具体内容的要求上，包括简要叙述问题，描述问题影响范围，对于问题根源的仔细分析，展示指标与图表，总结经验教训及改进作为等。我们在这里也对这几个重点内容做出简单介绍。

综上，因为亚马逊的善后复盘环节非常深入根源而且及时、细致，这种方式才能使用户反馈的问题在经过闭环步骤之后沉淀下来，作为公司的宝贵经验，指导公司日后更加完善地发展。

贝索斯把自己所在的亚马逊总部大楼命名为Day 1(第一天)。Day 1来自这位CEO的又一创新理念，意思是不管公司发展到何种程度，取得何种成绩，仍要把公司的每一天当作创业的第一天，用心做好当下。而在贝索斯看来，以用户为中心是目前保持Day 1活力的最佳做法。2017年年末，他在致亚马逊股东的信中提到，有时尽管满足了用户过去存在的体验需求，但用户由于对体验的要求不断提高，他们仍会有新的不满和需求。不过贝索斯还是这样鼓励说：“保持处于Day 1的心态，需要你耐心地尝试、接受失败、播种种子、保护树苗，这样，你就既能看到用户的喜悦，同时获得双倍回报。”借此，也希望正在读此文的各位也把自己在所在公司的每一天当作是第一天，重视用户体验，学习建立反馈闭环，以洞察用户的真实需求，做出更好的产品，从而为用户和自己创造更大的价值。