产品需求场景是什么,业务场景的构建,涉及场景管理功能

业务场景是什么(场景是需求的灵魂)最近在梳理后端业务流程,结

近期梳理后端业务流程,结合实践,从用户思维的角度来谈谈如何打造业务场景闭环。

用户思维:打造业务场景闭环
用户思维:打造业务场景闭环

一、场景是需求的灵魂

场景1.0:场景这个词最初的认知是梁宁先生分享的,对场景的解读是空间和时间的结合,即一个用户在何时何地有什么样的需求。

场景2.0:在实践的过程中,我对场景这个词有了更深的理解,即场景是用户和产品之间的交互以及他们得到的反馈(这个反馈可能是正面的,也可能是负面的)。场景不仅是用户做什么,还有产品提供什么样的服务。场景的结局一定是用户的需求或问题通过产品或服务得到满足。

用户思维:打造业务场景闭环
用户思维:打造业务场景闭环

上图是用户在使用产品或服务的过程中,获得正面和负面反馈的闭环。用户在使用产品的过程中可能会遇到各种各样的问题。当然,最理想的情况是用户在使用产品或服务后感到满意,并获得愉悦感或成就感。还有一种情况是你在使用产品的过程中遇到各种问题,这并不是用户使用产品的终点。通过平台的介入和服务的帮助,你可以帮助用户解决问题,让用户得到原本期望的东西。虽然这是一种负反馈,但是只要解决得当,你还是可以得到用户的理解的。

二、如何从用户思维出发,打造业务场景闭环

1. 场景梳理清楚了么?

业务场景主要分为两类:正常流程和异常流程。正常的流程比较简单,就是用户用产品来满足用户的需求或者解决用户期望解决的某个问题。异常的流程相对更复杂,根据不同的业务,异常场景的类型也不同。下面简单说一下异常场景的排序方法。

尽可能穷尽异常场景,很多新产品同学可能会说正常流程很容易梳理,但是异常流程怎么梳理呢?这么多复杂的场景,怎么保证能全部整理出来?下面介绍两种快速获取异常场景的方法:和产品客服同事了解,听客服电话。

认识客服同学是最快的方法之一。客服同学每天都会接触到各种用户反馈。当你把你想了解的业务场景告诉他的时候,他们会给你提供各种各样的案例,但是客服同学可能没有系统的产品思维,给你讲案例的时候可能会想到说什么。这时候你就需要把它所描述的案例进行归纳,形成一个系统的场景类型。

监听客服电话是另一种获取异常场景的方式。毕竟客服同事了解到的都是二手信息。只有亲自去听客服电话,才能亲身感受到与用户的沟通,更好地了解用户在使用产品时遇到的问题。

听客服电话相对来说是更有价值的信息,但是因为听客服电话时间太长,可能得不到更全面的异常场景。因此,两者的结合可能是理解异常业务的一种高效方式。

在得到尽可能多的异常场景后,我们需要进行梳理和思考。我们应该如何处理每一个异常的场景?无论是系统处理还是客服人工干预,用户对这种处理方式会满意吗,如果不满意,怎么处理?不得不说,变态的场面是最让人崩溃的。整理出异常场景的类型后,可以和客服同学、产品同学、运营同学一起头脑风暴,思考每一种异常场景该如何处理和解决。

2. 闭环了么?

在规划每一种场景的业务流程时,如果你认为自己已经想好了,那么再问自己一个问题,这是不是处理完成后形成闭环的方式?用户真的会满意吗?如果用户不满意,会有进一步的处理吗?

这里以OTA酒店业务为例。本质上,OTA作为酒店住宿的平台,通过从酒店供应商处获取酒店资源,向客人提供酒店资源,并从中赚取佣金。

那么,在酒店预订业务的过程中,从酒店预订到最终入住,就会出现各种异常的场景:

在客人预订后取消的场景下,很多酒店资源会设置各种预订规则来保证自己的利益,在预订后的某个时间点不允许用户取消或免费取消。

客人在预订后发现由于各种原因无法正常入住时无法免费取消,一般会和平台、酒店协商,看是否可以免费取消,或者根据实际情况少付费。这时候平台会和酒店沟通,沟通后平台会扣除部分罚款,为客人取消。

但是此时的异常场景你处理完了吗?

其实不是的。

从实际情况来看,部分客人对这种处理方式并不满意,会再次沟通,希望返还部分被扣的罚款。那么在这个业务场景中,就需要二次退款的功能,可以再次退回客人被扣的罚款。

所以在整理和规划异常场景的处理流程时,一定要多问自己一个问题。流程真的是封闭的吗?当然,这个闭环不一定是产品通过系统完全完成的,也可能是人工干预完成的。无论哪种方式,都必须实现流程的闭环。

3. 这是用户想要的么?

>

很多时候,作为产品,尤其是在一个行业工作多年的老人,都缺乏一种创新精神或用户思维,在对功能的优化和创新过程中,都容易陷入既定框架当中。

在规划业务流程时,考虑的更多的是当前的流程是什么,如何可以在满足需求的同时又尽可能减少对当前流程的改动。这种工作方法或思考方式是有问题的,在进行流程的规划和优化时,首先应该思考的是这样做是不是对用户有利的,是不是用户想要的?也许通过你的改造降低了工作成本,但是那并不是用户希望的,那还不如不做。

先思考如何做是对用户有利的,再想能不能实现或实现成本有多高。作为产品,可以接受迭代或分期实现对用户有利的解决方案,但是一定不能接受为了减少工作量或减少成本做一个对用户不友好的方案。

上述方法适合业务驱动型产品,或者业务场景相对复杂的产品/服务,在梳理场景、梳理需求的时候,要尽可能从用户视角出发思考:是不是用户可能遇到的场景都包含了?是不是能满足用户的需求了?是不是真的是对用户有利的?

内容来源网络,如有侵权,联系删除,本文地址:https://www.230890.com/zhan/180569.html

(0)

相关推荐