时间: 2021-07-30 09:28:27 人气: 6 评论: 0
最近在梳理后端业务流程，结合实践来聊一聊如何从用户思维出发，打造业务场景闭环。
场景1.0：对于场景这个词的最开始认知是通过梁宁老师的分享，对于场景的解读是空间和时间的组合，即一个用户在什么时间什么地点有什么样的需求。
场景2.0：在实践过程当中，对场景这个词有了更深一层的了解，即场景是用户与产品的交互过程以及获得的反馈（这个反馈可能是正向的也可能是负向的），场景不仅仅是用户做了什么，同时还是产品提供了什么样的服务，场景的终点一定是通过产品或服务满足了用户的需求或解决了用户的问题。
上图展示了用户在使用产品或服务过程中得到正负反馈的闭环，用户在使用产品的过程中可能**遇到各种各样的问题，当然最理想的情况是用户使用产品或服务后得到了满足，获得了愉悦感或成就感。另外一种情况就是在使用的过程中遇到各种问题，遇到问题不是用户使用产品的终点，通过平台的介入、服务的借助帮助用户去解决问题，让用户得到原本期望得到的东西，虽然这是一种负向反馈，但是只要解决得当，还是能够获得用户的谅解。
业务场景主要分为两类：正常流程和异常流程，正常流程相对来说简单，即用户使用产品，满足了用户的需求或解决了用户期望解决的某个问题。异常流程相对来说更为复杂，根据业务的不同，异常场景的种类也有所不同，下面主要聊一聊异常场景的梳理方法。
尽可能穷举异常场景，很多初入业务的产品同学可能**说，正常流程很好梳理，但是异常流程怎么梳理呢？场景那么多那么复杂，怎么能保证能梳理到所有呢。这里提供两种可以快速获取异常场景的方法：和产品客服同事了解、听客服电话。
与客服同学了解是最快的方式之一，客服同学每天**接触各种各样的用户问题反馈，当你告诉他你希望了解的业务场景时，他们**给你提供各种各样的案例，不过客服同学可能没有成体系的产品思维，在给你讲述案例时可能想到什么说什么。这时就需要你去对其描述的案例进行归纳总结，形成体系化的场景类型。
听客服电话是另外一种获取异常场景的方式，通过客服同事了解到的毕竟是二手信息，只有亲自去听客服电话才能亲身感受与用户之间的交流与沟通，也更能理解用户在使用产品过程中遇到的问题。
听客服电话相对来说更能获取宝贵的信息，但是由于听客服电话需要消耗过多的时间，也有可能无法获取更全面的异常场景。所以两者相互结合，可能是了解异常业务尝尽的高效方法。
获取到尽可能多的异常场景后，就需要去梳理和思考了，每一种异常场景应该如何处理呢？是系统处理还是客服人工介入，这种处理方式用户**满意么，如果不满意又要如何处理？不得不说异常场景是最让人崩溃的，在梳理清楚异常场景的种类后，可以和客服同学、产品同学、运营同学一起进行头脑风暴，针对每一类异常场景去思考如何处理何如解决。
在规划每一类场景的业务流程时，如果你认为你已经想清楚了，那么再多问自己一个问题，就是这样处理完成后形成闭环了么？用户真的**满意么，如果用户不满意还**有进一步的处理方式么。
这里以OTA酒店业务为例，本质来说OTA作为酒店住宿的平台，通过从酒店供应商获取酒店资源提供给客人，从中赚取佣金获得收益。
那么在酒店预订业务过程当中，客人从预订酒店到最终入住结账中间**有各种各样的异常场景：
以客人预定后取消场景来说，很多酒店资源为了保证自己的利益，**设定各种预定规则，在预定后某一时间节点后就不允许用户取消或免费取消。
当客人预定后因为各种事由无法正常入住时发现无法免费取消时，通常**与平台与酒店进行协商，能否根据实际情况免费取消或少付费取消。这时，平台就**和酒店沟通，经过沟通后，平台**扣除部分罚金为客人取消。
但是这时就完成了异常场景的处理了么？
其实并没有。
从实际情况出发，有些客人不满足这样的处理方式，还**再次沟通期望能把扣除的部分罚金也要回来，那么在这种业务场景中就还需要二次退款的功能，可以将扣除客人的罚金再次退回。
所以，在梳理和规划异常场景的处理流程时，一定要多问自己一个问题，流程真的闭环了么？当然这个闭环可能不完全是通过产品通过系统完成，也可能是通过人工介入完成的，不管通过哪种方式，一定要实现流程的闭环。
很多时候，作为产品，尤其是在一个行业工作多年的老人，都缺乏一种创新精神或用户思维，在对功能的优化和创新过程中，都容易陷入既定框架当中。
在规划业务流程时，考虑的更多的是当前的流程是什么，如何可以在满足需求的同时又尽可能减少对当前流程的改动。这种工作方法或思考方式是有问题的，在进行流程的规划和优化时，首先应该思考的是这样做是不是对用户有利的，是不是用户想要的？也许通过你的改造降低了工作成本，但是那并不是用户希望的，那还不如不做。
先思考如何做是对用户有利的，再想能不能实现或实现成本有多高。作为产品，可以接受迭代或分期实现对用户有利的解决方案，但是一定不能接受为了减少工作量或减少成本做一个对用户不友好的方案。
上述方法适合业务驱动型产品，或者业务场景相对复杂的产品/服务，在梳理场景、梳理需求的时候，要尽可能从用户视角出发思考：是不是用户可能遇到的场景都包含了？是不是能满足用户的需求了？是不是真的是对用户有利的？
记小忆，公众号：PM龙门阵，人人都是产品经理专栏作家，OTA中后台产品经理。
本文原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
