惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

云风的 BLOG
云风的 BLOG
The GitHub Blog
The GitHub Blog
Y
Y Combinator Blog
博客园 - 三生石上(FineUI控件)
T
The Blog of Author Tim Ferriss
宝玉的分享
宝玉的分享
Hugging Face - Blog
Hugging Face - Blog
WordPress大学
WordPress大学
V
Visual Studio Blog
小众软件
小众软件
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
MongoDB | Blog
MongoDB | Blog
V
V2EX
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
博客园 - 【当耐特】
Microsoft Azure Blog
Microsoft Azure Blog
The Cloudflare Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Engineering at Meta
Engineering at Meta
L
LangChain Blog
Martin Fowler
Martin Fowler
GbyAI
GbyAI
博客园 - 司徒正美

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
直营模式中,一张整车订单包含哪些东西
Topcat · 2024-03-29 · via 人人都是产品经理

购车是大宗商品交易,各个因素涉及到的流程和规则很重很复杂,本文先聚焦讨论直营模式下TOC的零售购车交易,从六个因素中分析抽象出产品设计的模块or对象,不含规则和流程。

订单定义的是买方(buyer)在什么时间(time),什么地方(place),用什么价格(price)向卖方(seller)买了什么商品(product)。从用餐小票到跨国贸易,订单的基础结构是一样的,只是业务形态的不同导致每个因素上的复杂度和玩法不同。

一、买方-Buyer

这里先扩展一下买方概念,买车只是第一步,买回来还要搞上路资质,平时是谁开也都不一样,比如老公下单买车,用老丈人的指标上牌,平时给老婆用。那购车人就是老公,上牌人是老丈人,用车人是他老婆。

那又有个问题:车不是老婆一个人开,老公也有可能开怎么办?

把用车人往下拆一个颗粒度-主用车人和授权用车人,区分主次,主用车人权限最大。

买过新势力品牌电动车的朋友应该都知道,给家里人或者朋友开的时候,对方只要下个APP,给他授权,他就可以在APP里做一些基础控车的操作。

所以买方概念里的对象是多个,通常是购车人、上牌人、用车人。订单上起码要记录这三个对象。

二、时间-Time

这里没有用when这个单一指向时间,因为购车的链路很长,车是几万几十万的商品,不像买九块九的东西下单即成交,而长链路就会带来多个动作的时间点,购车人能看到的主要是下单时间、付款时间(定金、首付、尾款)、锁定配置时间、交付时间等,还有其他后端业务跟进运营的动作跟时间,暂时不做赘述。

这里最重要的就是定金支付时间和锁定配置的时间,去传统4S店里买车的时候,这种动作的时间点不是那么的重要,付首付做贷款更重要,因为经销商需要尽快回款,尽快拿到返利。

先看定金支付时间,电动车领域经过行业发展,业务运营模式开始发生变化,车本身的产品力只是基础,还要有足够吸引人的购车权益,比如终身免费充电、终身免费换电、送充电、限时送某个高级配置等。

给力的权益都是有一定成本的,换个角度想,好权益是有限的,一般是时间有限。有限的东西怎么分呢?谁先付钱给谁,这就是定金支付时间的作用——你在这个时间里付了定金,锁定的就是该时段的权益。

之前电车竞争相对没那么激烈的时候,品牌一般先发点新车素材,收小订订单,正式发布会的时候才开大定,小订的权益最好,大定次之,在时间阶段上做这种区分的原则是一样的:先付钱的人意向度最高,拿最好的权益。

不过现在竞争强度非常大了,销售节奏不会拖这么长,一般发布会直接开大定,另外提前准备少量现车,直接交付。

第二个是锁定配置的时间,这个动作代表确认车辆配置了,不再变更,这个时间关系到配车的顺序。

工厂现在都是以销定产的,业务部门预测各类配置的车需要生产多少量。在达到一个相对健康的平衡之前都是人工来预测,并不是工厂拿到你的订单直接就生产了。

这里就涉及到订单配车,原则上都是先锁定配置的先得。

各品牌对这两个动作时间的定义和使用会有些区别,特斯拉比较简单粗暴,就是一个大定,可以理解为下了定金就是锁定配置了,蔚小理是分了两个,除了客户自己锁配,兜底是48小时自动锁配。

主要是管理思路上不一样,特斯拉还是产品主导,买定离手,看重车辆本身的销售和交付,流程简单有效;新势力在每个环节都拼用户体验,让用户下完订单还是有更改的机会。

除此之外还有其他常规时间点,下单时间,支付首付时间、支付尾款时间、验车时间、提车时间、交付时间等,按实际业务情况分布在订单主单和子单上面。

三、地点-Place

在什么地方交易,同样因为长链路的原因,交易过程中跟地点相关的也有多个。

在销售转化阶段,下单付定金发生在销售门店,一般是跟你联系过的销售人员所在的门店;如果你实车看都没看,就是喜欢而且不缺钱,直接在APP或者小程序里下单了,这时候订单给哪个门店呢?销售是有成单绩效的,天上掉的馅饼怎么分呢?要看具体的业务规则,可以进到总部400跟进沟通以后分配,也可以按订单上的交付城市映射一个默认销售门店。

在交付跟进阶段,付尾款做贷款、验车提车的时候发生在交付门店,交付角色不止要跟进订单,还要跟进车的物流进度、验收入库、交付前整备等。车的流转就涉及到仓库点位,订单在哪个交付门店,车辆就要去到这个门店下的仓库。

用户的购车单上只需要提现门店信息,车辆在仓库间的流转对用户来说不是必要信息,而且因为涉及到物权交易,有一定的复杂度,一般是做单独的内部单据来管理。

四、商品-Product

毫无疑问这里就是某个配置的车,现在在线上选车的时候看上去跟在电商平台选衣服一样,一层层选车型、外观内饰轮毂等,但后端的处理区别是很大的。

电商逻辑的核心是前后端品类映射和商品属性管理,一件衣服是属于上衣还是下装,颜色有几个,尺码有几个,这些都是可以在一个后台里运营管理。而汽车品牌是集设计、生产制造、销售、物流、交付、车辆网于一体的,每一块下面都是一个细分的大部门,一个车到底是什么配置大家必须要用同一套语言沟通,比如工厂叫浅蓝、深蓝,销售定义叫天空蓝、海蓝,你下了一个海蓝的订单,工厂应该生产深蓝还是浅蓝的车呢,那就要一个地方定义一套配置,大家交互的时候都按这个定义来,无论自己这方叫什么,跟其他方沟通的时候要转化成这套语言,就像出国交流用英语一样。

定义配置的地方通常是BOM(BOM是个比较复杂的范围,不再展开,只要理解它定义了配置的基础语言就OK)。

对销售侧来说,定义是车型是Model 3,对应的内部语言可能是MM-3,定义的颜色是烈焰红,对应的内部语言可能是R,这里就涉及配置语言的映射关系管理,姑且叫商品配置管理,它是基于内部语言做包装和映射关系的模块。

五、价格-Price

价格一般也是跟在配置上定义的,每个配置都有明确价格,选完以后就是配置总价(MSRP),现车或者员工车可能有打折,会涉及订单打折or车辆打折的管理模块。

价格不光是落单,还要跟付款进度联动,影响订单状态,如果是全款购车,付完定金后面就是尾款待付了,如果是贷款,中间还有首付支付状态的联动校验。

六、卖方–Seller

这里要从财务视角看卖方,最后给你开票的是什么主体,一般是品牌子公司or分公司。随之关联的就是组织架构管理,子公司和交付门店和销售门店之间的关系,开票与之关联的是跟财务应用的对接。

以上从订单组成的六个因素拆分对应的关键对象or模块并引申出关联项,可以作为理解整车订单的思路。

作者:Topcat

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

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务