为了各位馋虫,我设计了一款全新外卖APP“饿了拼”

零基础学产品,BAT产品总监带,2天线下集训+1年在线课程,全面掌握优秀产品经理必备技能。了解一下

本文笔者针对外卖App中用户无法实现店内双拼以及跨店双拼的痛点,设计了一款全新的外卖App”饿了拼“。

本文为笔者构思半天之作,可能不算完整,但其产品雏形已经完备,特与诸君分享。

产品关键词:外卖APP、店内多拼、跨店多拼、团购、社交

一、产品简介

饿了拼是一款支持店内以及跨店多拼点餐的外卖APP。

产品宣传语:用一份钱,拼出多倍美味。

目前,用户很多时候点外卖时犹豫吃什么,很多时候是一餐想吃多种美味——有时是同家的鸡排和烤鸡都想吃;有时想吃一家店的拌饭同时还想吃隔壁家的米线;有时是同时想吃一家店的拌饭还想点隔壁店的奶茶和小吃。

前两种情况,用户不仅难以承受金钱压力,“肚皮”也难以承受,而后一种情况用户不愿承受双份运费。上述情况下,用户往往是艰难妥协后才做出了最后的决定。

针对这个背景,“饿了拼”横空出世,它能够实现让用户是需用原来一餐的钱便享受多倍的美味。同时,能给商家、骑手、平台带来更为丰厚的收入。

二、产品分析

背景

泛化:外卖下泛用户需求分析

不同用户选择外卖最关心的核心要素均为:方便(时间成本),价格(经济成本),美味(产品质量)。不同用户群体对这三个要素的重视程度不同。

聚化:饿了拼”产品目标用户下需求分析

“饿了拼”的目标用户为“在校大学生”、“青年上班族”、“普通单身宅男宅女”。

这类人群对价格更较白领阶层更为敏感,同时非常追求美味享受。对该类人群而言:价格,美味是突破口,而“方便”次之。我猜该类人群很多时候点餐是一人餐。(没有找到对应数据,学生自己推测的)。

典型痛点场景描述:

  1. A餐馆的1号餐和B餐馆的2号餐,用户“小明”都想吃,但是因为吃不下和预算限制,不得不在其中艰难选择一个。
  2. A餐馆的1号餐好吃,但是A餐馆的小吃不好吃。隔壁B餐馆小吃好吃,小明想吃A餐馆的1号餐和B餐馆的小吃,但是又不愿意出两倍运费。
  3. A餐馆的1号餐和2号餐用户“小明”都很喜欢,由于店家不支持双拼。小明由于吃不下和预算等原因不得不在其中艰难选择一个。

痛点分析:

这类场景发生频率在外卖中属于中高频,相信每一位用过外卖的用户都深有体会。用户之前面临这个场景通常会因为“吃不下”、“价格”等因素而做出妥协。此时,若有一款“外卖”APP能解决该问题必然将在打开目标用户的市场,并将在市场中占据有利地位。

产品关联方综合分析:

分析:如何兼顾保障用户、商家、骑手的利益?

  • 商家方面需考虑的问题:分析之前商家大部分不支持多拼的原因:比如害怕烤鸡卖一半,另一半没人买;炒菜炒的太少不值得浪费体力和煤气费等。所以之前的双拼多只存在于“拌饭”这类品种。商家的利益必须保障。
  • 骑手利益问题:骑手属于平台内最被动最容易被忽视的群体。若开通双拼后,特别是跨店双拼。骑手的单个订单所花时间也会增加。是否应增加送餐费是个问题?若增加费用,谁应来出?
  • 用户问题:若用户选择跨店双拼。骑手所花时间增加后对应着用户的等待所需时间也会增加。

如何最大限度的减少用户等待时间增幅——即用户的体验如何最大程度优化?

综上如何让商家、骑手,用户每个群体都喜欢“饿了拼”的模式。

解决方案思路:

1)针对商家的问题可以通过两种方式解决:团购预约、双人成单。

  1. 团购预约:商家可以将店内需要双(多)拼套餐提前发布出来。供用户选择参团(半个小时更新一次)。每一轮达到截止时间时参团人数超过预设下限值后方可有效(同时设置一个上限人数,超过人数后即可发团)。比如:截止时间为10:30、11:00、11:30等-午餐档。这个方式最好给与用户一定小额的优惠,在预约截止时间前(同时没超过人数上限)用户可以自由退出。
  2. 双(多)人成单:用户可以随时发出搭配订单申请,其他用户看到后若对该搭配订单该兴趣则可以加入该发起的搭配订单申请。用户发布订单时可以设置有效时间(最多半小时),有效时间截止前用户也可以随时撤销。只有满足对应人数后对应店家才会收到订单(双拼则两人即可、三拼则需三人)。这个方式用户不会享受优惠。

如此一来,商家之前的顾虑已然消除。且预测新模式下,商家的订单数和成交额将一定程度增加。

2)针对骑手问题

很简单,限定跨店范围和用户范围即可。而外卖行业天然具备该属性,商家是集中在一起的,用户也是集中在一起的。通常而言,一个餐馆附近100米还有多家餐馆,而“饿了拼”的目标用户集中在学校、写字楼、居民小区等人群集中点。

所以,跨店双拼时,把支持跨店的商店限定在附近100米内,参与店内和店外多拼的用户群也限定在1KM以内。

针对增加费用问题,如上面所说,商家的收入会增加。理应承担大部分多出运费。对于用户而言是可以多承担少量多出运费。

如此,新模式下,骑手的收入预测会一定程度增加。(毕竟一接单就是两个及以上)

3)针对用户问题

用户的问题已经在骑手问题中顺带解决了。限制商家和用户群范围,用户额外增加的等待的微乎其微。(特别是参团),而美味和价格优化体验提升极大。

综上,商家、骑手、用户都将在新模式下获利。而外卖平台不需要额外多承担任何费用,此外还能借助新模式往社交等领域试探。

还有其它小问题:比如跨店优惠卷。跨店协同问题(一家做好了,另一家没做好)

三、特色功能简介

  1. 店内/跨店(双/多拼):多拼团购预约(店家发起)、双(多)人成单(用户发起)
  2. 拼神美仙:用户可以将跨店搭配的方案发表,其它用户可以投票。商家可以采纳。用于之后的团购预约方案。
  3. 拼友:参与团购预约的用户可以选择进同一个聊天室,双/三拼的队友之间也可以聊天。等着也是等着,不如多认识一个朋友把。(外卖进入社交领域的首发,预测用户接受程度会较高)

 

本文由 @李引繁 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 首先立个牌子,不看好!
    第一,骑手要跨店取餐,那么骑手的费用必然增加,增加的费用还不是用户买单吗?这就可以推翻上文提到的“价格”
    第二,对于商家而言,拼单势必会投入更多经历,而且相对与完成套餐,单价如果降低,餐盒也是成本。对于现在的外卖商家,并不是单量多,利润就对应增加,能做到曲线增长就不错了。
    第三,对于用户而言,我是相信有拼单需求的。问题是一个用户的可持续性,每次都愿意投入精力去选择拼单吗?相对传统套餐,在结算时,能得到优惠吗?(请考虑餐盒和配送费)
    第四,我觉得顺着笔者的思路,如果加入社交属性,每天有一个订餐组长(3到5个人,一起在同一个店铺下单),通过更高的单价获得更大的优惠,还是可行的。
    欢迎硬怼

    回复
    1. 1.适当增加费用是可以接受的。价格和美味这两个因素。用户可以为了其中一个适度对另一个因素进行调整。我再给你说一个。你去商家买餐。我试过购买好几份套餐和一份套餐的送餐费是一个价,但是两种情况是不同的。
      2.利润率可能会降低,但是收入和利润会增加。餐盒的费用也可以让用户承受。我这里的依据是商家能接受增加收入为前提的增多工作量。并且拼单的权限是商家决定的。他不同意,可以随时取消。
      3.选择拼单后,可以分享到微信群或者熟人聊天中。这种拼单很快的。至于价格波动不是很大就行。就餐盒和送餐费而言,是很小的增加。对于部分用户而言是可以承受的。
      4.再次强调,拼单是目前模式的补充,不是代替。

      回复
  2. 我们公司17年做了一款跨店点餐APP,差不多砸了100多万吧,现在已经挂了。我也是一个跨店点餐爱好者,现在经常用马云巴巴的盒马鲜生点跨店美食,祝好运

    回复
    1. 这个模式的亮点之一是拼单模式为2份口味的min版(正常版本的一半分量)。不知道贵公司是否也是如此操作的。然后文中指出的跨店协同问题是具体实践中是如何解决的。。我其实感觉会比想象的要复杂一点 :cool:

      回复
  3. 对于文章,有一点点建议,作者能不能配图说明流程呢,有点难想象呢~

    回复
  4. 我想吃肯德基的汉堡,麦当劳的薯条 :arrow:

    回复
  5. 你既然说了,这个产品核心用户是对价格敏感的,每餐都有明确预算。那拼单模式基本对商家销售额没什么提升,还会增加操作成本。 对于目标用户来说现在已经很简单的 外卖点餐都会出现 选择困难症,这个app估计会让点餐时间延长1倍
    一个需求并不强的产品,需要增加平台、商家、骑手 3方的学习操作成本,不太看好

    另外说一个与产品无关的点,“美食”不是外卖的特点 只有便利性才是

    回复
    1. 1.拼单是原单点模式的补充。不是代替。
      2.销售额肯定会的,因为就单个商家而言扩展了边缘用户。之前的商家有满多少才配送。现在变成了附近跨店满多少就可配送。并且选择多种口味后。用户预算是可以适当轻微增加。这个是符合用户经验和心智的。
      3.至于朋友你关于需求不强的结论,我无法苟同。你可以观察询问线下的面店:选择2两同样面的用户,和选择两种不同口味一两面的用户,谁多谁少。你也可以看下美团拌饭商家中,双拼和单拼,哪个销量好。
      4.关于学习成本问题。通过交互,界面的升级。是不会带来很多的。相关交互流程和页面在我脑里已经是十分清晰的。
      5.我用的是要素。不是特点。便携性是外卖对于其他就餐方式的特点而已。在目标用户中,美味和价格是主导用户是否选择外卖的优先核心要素,其次才是方面性。

      回复
  6. 想法挺好的,但是感觉实现起来很困难,对于场景中的三个角色都带来新的问题。
    比如说,
    1. 用户想要想吃A餐馆的套餐1和B餐馆的小吃,何不与同事分别定A餐馆和B餐馆的餐呢?
    2. 对于商家来说,上午10点以后准备外卖餐的事件会非常紧急,导致的问题就是商家需要投入更多时间,精力去这部分套餐。
    3. 骑手在整理用户餐品的时候需要更多精力,因为时间紧迫可能会导致送错餐,搭配错餐的问题频繁发生。
    只是一些粗略的想法,不喜勿喷。谢谢 :o

    回复
    1. 1.你不好确定用户跟同事都喜欢这两种餐,且都愿意跟彼此分享自己的餐。我所指的目标用户中已经指明了。(多数点的单人)
      2.这个精力是存在的。因为拼餐多了,之前的单点肯定会少。而预约的核心是让之前可能10:00之前还在休息的店家可以提前准备订单了。而之前商家只能按经验来行事。
      3.这个问题可以在下游软件(骑手APP上解决)。问题不大

      三个角色新的问题不可怕。重要的是各个角色更在意什么,用户看重的美味和价格,愿意牺牲一部分的方便来换取。而骑手和商家最在乎收入,可以更多牺牲一部分的精力投入。

      回复