骑手提前确认收货,初级产品经理要怎么处理这类复杂问题

6 评论 5826 浏览 12 收藏 16 分钟

作为一个初级的产品经理,有时候我们会遇到一些比较复杂的问题,我们应该如何应对呢?本文作者以“骑手提前确认收货”为例,对这个问题展开分析,希望对你有帮助。

01

“如果你是外卖平台的产品经理,你要怎么解决骑手提前确认收货的问题?”

几天前,我在网上看见有人在问这样一个问题。

“如果你是某某产品经理,你要怎么解决某某问题”,这样的问题,感觉经常可以碰见。

“产品经理”相关的讨论,大概有1/3是这样的问题。

作为一名初级产品经理,我每次看到这种问题,都会觉得有些不知所措。

就拿“骑手提前确认收货”这个问题来说。

首先,骑手能够“不守规矩”,说明业务设计上有漏洞,产品存在“错误”。

然后,已经有不少用户碰到这种情况,并感到相当程度的不满,说明已经影响到“用户体验”了。

那么,作为“产品”的经理,自然应该为产品负责,应该去纠正错误、优化体验。

真是这样吗?

其实不然。

这并不是一个可以简单解决的问题,它涉及到很多角色。

在这个问题的语境下,提问者想象了一个非常“强势”的产品经理形象:有较大的决策权,能够站在一个较高的视角,统筹全局,设计规划产品策略,能够指挥动员各部门进行配合,是一个“中央决策者”的角色。

同时,回答这类问题的,很多都是产品大佬。

所以,就更强化了这么一种错觉,以为“产品经理”就是这么一种“指点江山”的角色。

然而,现实中,能够做到这种程度的产品大佬,其实只是少数。

对于大多数产品人来说,情况完全不是这样。

其实从一些公司的组织架构上,我们也能看出一点端倪。

比如说,产品岗,算上实习生也只有两三人。

比如说,没有独立的“产品部”,而是并到运营部、设计部或技术部里面。

比如说,部门内没有“总监”级别的领导,或者,虽然有,但不是“产品”总监。

我觉得,更常见的情况是,产品经理在公司内部是一种相对“弱势”的存在。

初级产品经理,则更是如此。

我们向产品大佬学习,“高瞻远瞩”地去讨论怎么“解决”这类复杂问题,固然是有意义的。

考虑到实际情况,从初级产品经理的角度,更加“务实”地,去讨论怎么“处理”这些问题,我想,可能也是有些价值的。

所以,今天,我想以“骑手提前确认收货”为例,结合自己的一些经验,谈一谈“初级产品经理要怎么处理这类复杂问题”。

02

我们先来简单分析一下,为什么说它是一个“复杂”的问题。

首先,我们来看看“确认收货”这一业务本身。

“确认收货”,这个概念很简单,大家都清楚,我就不赘述了。

因为我们要去优化这个业务,所以在“动刀”之前,我们得先想想有没有其他的可能。

首当其冲的问题是,可以不要“确认收货”吗?

严格来说,可以。

外卖从店里发出后,将“已发出”作为订单的完成状态,也不是完全不可以。

但是,一般不建议这么做。

抛开具体的业务因素,主要有2个原因。

1.在边际成本可控的前提下,我们应该尽量提高数据的准确度。

多加一个状态,花不了多大成本。而更准确的数据记录,后续能挖掘出的业务价值,将会不成比例地增加。

2.已经做好的功能,如果不是出现严重问题,或者是大改版,一般不建议拿掉。

根据我的经验,那些一直没什么用的功能,一旦你拿掉了,非常诡异的,马上就会有人要用到,然后来找你麻烦。如无必要,勿瞎折腾。

不能拿掉“确认收货”,也不意味着,这个“确认收货”的动作,一定要由“骑手”来触发。

订单涉及到的角色,简单来说,有“用户”、“骑手”、“商家”、“平台”4个。

如果进行排列组合,可以有很多种情况。这里就不一一列举了。

除了“骑手来确认收货”外,还有以下3种看起来比较可行的方案。

用户来确认收货:

让用户来确认收货,也就没有骑手什么事情了。

乍看之下,好像能完美解决这个问题。

但是,其实不可行。

用户不愿意去操作“收货”,还在其次。

更重要的是,外卖有“超时赔付”服务。让用户自己“决定”收货时间,会有道德风险。

平台来确认收货:

比如说,根据手机定位等因素,来自动“确认收货”。

这种准确度很低,基本不可行。

骑手、用户和平台,共同完成“确认收货”操作:

其实也就是,由骑手来完成“确认收货”操作,然后引入其他角色对其进行监督。

比如说,要用户也确认,才有效。

比如说,平台进行定位监控,需要在收货地附近的操作,才有效。

这是一种比较可行的折中方案。

其实吧,完全由骑手“独断”的情况,并不存在。现实中,外卖平台,就是采用这种方案的。

具体策略可以有很多种,但是不管采用哪种方案,总体上都存在一个问题:提高监督力度,就会相应地提高成本、降低效率。

比如说,我们可以要求骑手确认收货时,提交一张自拍照。

那么,我们设想一下“办公楼中午配送高峰期”的场景。

可能骑手自拍的那么一瞬间,后面的电梯就关上了,下一趟就是十几分钟之后的事情了。

中午的配送高峰期,经得起几个“十几分钟”?

骑手的配送效率,会因此受到非常大的影响。

这就是为什么说它是一个“复杂”问题的原因了。

这里面有很多个维度,用户的体验,用户的收货习惯,骑手的配送效率,骑手的收入,骑手的体验,平台的监管成本,平台的收入,平台的商誉,等等。

一旦我们动了其中一环,不可避免地会影响到其它维度,很难做到“帕累托改进”。

因此,它不存在一个简单的终极解决方案,而是一个各方进行博弈、互相妥协的平衡。

03

接下来,我们来看看,在公司内部,这样的问题具体是按什么流程来解决的。

当然,不同公司情况不同,具体细节会有差异。这里我们抓大放小,暂时忽略这些细节差异。

首先,这个问题是谁先挖掘出来的?

虽然我们要求产品经理要懂用户,要关注用户,但是,公司里面并不是只有产品经理在关注用户。

大概率上,这个问题会由以下部门发现并提出来。

客服部:

用户有不满,就会投诉。客服接到这类投诉多了,问题的严重性就会凸显出来。达到一定程度,这个问题就会被提出来。

运营部:

一般会有运营同事在持续监控网上各平台内关于自己公司的讨论。用户不满的讨论多了,有恶化的苗头时,这个问题就得在公司内部提出来。

问题确立之后,一般是怎么提出来讨论呢?

大致上,有2种情况。

1.在日常性的比较高规格的公司例会上,由发现问题的部门提出来。

这类日常性会议,可能一周召开一次。与会的有各部门领导和核心成员,还有老板。

一般来说,初级产品经理没有资格参加。就算参加了,也只有听的份。

2.发现问题的部门将问题反馈给领导后,将需求立项,组织相关部门进行协商讨论。

这种情况,有时候需要产品经理与会,甚至需要由产品经理来组织。

但是,初级产品经理更多的是一个“组织者”、“执行者”的角色,不是“决策者”。

那么,讨论之后,问题具体要怎么解决呢?

1.有的时候,问题并不需要解决。

比如说,虽然表面上看起来“群情激奋”,但其实只是少数人的不满。大多数用户可能并不在乎这个问题。他们只是“沉默”,没有发声而已。

而为这少数人进行优化,可能成本上不划算。

所以,不进行处理,保持这个平衡就行了。

2.有时候,问题需要处理,但是没有产品经理什么事。

解决问题,不是只有“技术”一种方式,还可以通过“管理”。

比如说,质检部门,或是其他类似部门,定期随机地电话回访用户,排查这种“提前确认收货”的情况,然后对有问题的骑手进行处罚公示。

这样,付出较低的成本,就能很好地改善这个情况。

3.有时候,需要一整套解决方案,而产品经理只是负责其中一部分。

比如说,因为配送效率是“红线”,不能对“骑手侧”动手。那么,我们可以对“用户侧”进行管理。

它可以是一套涉及多部门的解决方案:

  • 客服部,设计一套安抚用户情绪的话术,并在难以安抚的时候,按规定给用户发放优惠券。
  • 运营部,监控网上的负面声音,对于情绪强烈的,主动联系安抚。
  • 产品经理,在APP内设计体现骑手困难的内容,以争取用户的理解。在骑手确认收货后,把“投诉反馈”的入口放在突出的位置,确保用户在情绪升级之前,能被引导到客服那里,由客服来解决。
  • ……

04

很多时候,产品经理,尤其是初级产品经理,并不是一个“中央决策者”。

初级产品经理,往往只是一个“执行者”,而且往往只负责整个解决方案中的一部分。

这和很多人想象中“指点江山”的形象,相去甚远。

当然,不是“决策者”,也不意味着可以“置身事外”。

作为产品经理,我们很多时候,肯定是需要参与进来的。

那么,面对这些复杂问题,初级产品经理应该怎么处理呢?

以下谈几点建议。

1.要能够准确评估问题,并及时将问题升级。

其他部门,因为他们的日常工作大部分只涉及到部门内部,所以他们对跨部门的协作不是很熟悉。

所以,有时候他们会把这些问题,不明就里地提到产品经理这里来。

我们接到这些需求后,要对其进行评估。

当发现不是简单修改APP设计就能解决时,要及时将问题升级。

2.做好干系人管理,宁滥勿缺。

虽然初级产品经理不怎么参与决策,但有些时候需要由我们来组织协调各部门之间的协作。

比如说,联系各方开会讨论,向各方同步进度,等等。

这种时候,我认为,最应该避免的就是,有缺漏,该联系的人没联系到。

这可能会导致整个方案设计出现重大纰漏,或者在后续推进过程中难以得到相应干系人的积极配合。

所以,我们需要“宁滥勿缺”。把没关系的人也拉来了,不可怕。把有关系的人漏了,才可怕。

3.在讨论中,需要就产品设计难度和成本,提出自己专业的意见。

整体来说,其他部门,对产品设计开发的具体情况,是不了解的。

这就导致,在讨论方案时,他们可能会提一些“强人所难”的要求。

我们参与讨论,并不完全是来“接受任务安排”的。对方案的可行性,我们是需要进行一定程度把控的。

因此,我们需要就产品设计难度和成本,提出自己的意见。并根据当期讨论的情况,提出更合适的方案。

4.产品设计、项目跟进过程中,要有全局思维。

产品经理,并不是完全“听命行事”的。

在一些局部,我们也是需要进行很多“决策”的。

比如说,策划PRD的时候。

比如说,项目跟进中出现突发情况,需要产品经理解决的时候。

这个时候,我们需要清楚,我们不是在单独处理眼前这个细节问题,我们负责的是整个解决方案中的一部分。

因此,我们需要站在整个解决方案的高度,按照方案的核心思路,去设计和解决问题。

 

作者:简明产品论,个人公众号:简明产品论(ID:JianMingPM)

本文由 @简明产品论 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!
1人打赏
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 骑手行为心理:
    超时收货确认影响绩效,会被罚钱

    潜在场景:
    1.商家出货不及时,配送员等待时间较长
    2.骑手同时拿多单,导致部分订单存在配送超时风险,然后提前确认收货
    3.天气原因,交通原因导致配送超时

    场景对应解决方案:
    1.建立商家出餐时长预测模型,出餐时长超过一定时间对商家做出惩罚,骑手配送不予惩罚
    2.为提升赚钱效率骑手一次性领取多单情况无法避免,否者会打击骑手配送积极性
    对应策略:
    a.派单领取策略调整:所以在可领取多单的情况下,首先根据历史大数据去查看,骑手同时领取超过多少单时存在超时风险,针对该阈值设置领取单数限制规避超时问题;领首单和尾单间隔超过多长时间时会存在延误风险,领单时给予骑手提示配送风险。
    b.配送效率优化:多单情况下为骑手进行线路规划,提升配送效率
    c.提前确认收货被投诉,给予一定时间段0派单、被投诉多次进行惩罚并延长0派单时长,给予用户优惠券补偿
    3.恶劣天气情况下单少推准时宝并给予用户安抚话术说明,降低骑手延误赔付问题。

    回复
  2. 个人觉得这个不应该首先思考,为什么要提前收货?
    1.因为系统计算的时间不充足?交通原因;餐厅原因;骑手原因;其他因素。
    2.利益出发。提前收货,可能带来的投诉风险,考核等。
    如果能把这些因素控制住骑手为啥要提前收货呢?

    回复
    1. 1、交通原因、餐厅原因等这些因素是客观因素,也是不可控的。
      2、解决办法如你所说,增加配送时间,看似从“根”上解决了提前收货的问题。现在我们思考“提前收货”带来的问题是在哪一侧,毫无疑问是在“用户侧”的。
      3、现在返回来说增加配送时长能否解决上述问题,你换位思考作为用户,在中午点了一份餐想在既定的时间美美的吃一顿,然而餐厅离你不是太远大概1-2km,一看时间一个小时,你会怎么想?作为骑手你会怎么做?所以你这个问题最终又绕回到了用户侧,说白了还是不解决问题。
      4、从投诉风险入手,让骑手在点击提前收货时面临被投诉等处罚风险,这看似也能解决问题。但站在骑手角度出发,他一方面担心在规定时间配送不到而面临处罚(因客观因素无法把控而导致配送超时),一方面担心配送不到点击提前收货而面临处罚,这是一个让骑手很纠结的事,时间长了会影响骑手积极性从而影响APP的大众口碑,同样又绕回到了用户侧。
      5、我真实的体验也是这样,单位附近有几家餐厅原来都是1-20分钟左右货到,现在直接调整为50-70分钟左右(我回想时间更改的这段时间,貌似提前收货的问题真的没发生过了0.0),下雨天之类的更甚,所以我在基于此前服务的基础上不止一次的对客服提出我的困惑。
      6、我只在一种情况下对上述问题有过“理解”就是之前的某个下雨天,骑手打电话过来说明原因,我也理解,并且因为骑手态度很好,给了好评。
      7、我认为产品真的应该在基于自身原因的思考下最大程度的站在用户侧考虑问题,而不是一上来就把问题抛出来,而抛出来的大部分原因是不可控的,这可能会让决策层很头疼,同样也不是一个好的职场行为方式。有点啰嗦了,希望对你有帮助。

      回复
    2. 谢谢,这几个点值得我反思。

      回复
  3. 这好像是一个简单问题,并没有复杂度吧。给骑手增加一个风险阈值,当提前确认收货的风险成本大于收益时,骑手就会降低提前收货的动机。

    回复
  4. 骑手确认送达的button仅在用户定位地址小于100米的时候可以触发,用户中途修改地址需要再移动端操作说明。

    回复