137 lines
7.8 KiB
Markdown
137 lines
7.8 KiB
Markdown
---
|
||
title: L1 · 万师傅业务本质（根级业务知识）
|
||
source_status: 2026-07-31 业务方访谈确认收入模式、总包/KA 商业关系、核心矛盾表述；仅 §8 状态机一处待补。2026-09-07 订正 §7：KA 与总包非绝对关联，部分 KA 直接下单
|
||
level: L1（根级）
|
||
usage: 设计为常驻上下文，可整份放入 system prompt
|
||
---
|
||
|
||
# 读之前
|
||
|
||
这是万师傅业务的**世界观层**——从业者视为空气、从不言说，但一旦理解错，
|
||
后面所有推理都会歪掉的那些前提。
|
||
|
||
**收录标准**：老员工觉得"这还用说？"、新人问了会被当成傻问题，但答错整条推理链错位。
|
||
详细的名词定义在 [L2-concepts.md](L2-concepts.md)，具体规则数值在 [L3-rules-index.md](L3-rules-index.md)。
|
||
|
||
---
|
||
|
||
## 1. 双边撮合平台，不是自营服务商
|
||
|
||
万师傅连接**有家居售后需求的一方**和**有技能的师傅**。平台不雇佣师傅、不持有商品、不直接提供上门服务。
|
||
|
||
由此：平台对师傅只能**治理**不能**管理**——没有考勤绩效上下级，只有准入、评分、处罚、清退；
|
||
服务质量无法靠"培训员工"保证，只能靠规则 + 评分 + 保障机制兜底。
|
||
|
||
## 2. 供需匹配有两种范式
|
||
|
||
- **报价招标**：下单方发单 → 多个师傅竞价 → 下单方挑选并**指派** → 付款。价格由市场竞争形成。
|
||
- **一口价**：价格预先定好 → 师傅直接接单（抢单）。价格由平台/下单方设定。
|
||
|
||
两种模式下"师傅怎么拿到单"完全不同，涉及派单、报价、抢单的一切推理都必须先分清是哪种。
|
||
|
||
## 3. 师傅是自主经营的个体，不是员工
|
||
|
||
师傅**入驻**（不是入职）、被**清出平台**（不是辞退）。收入是服务报价所得，不是工资。
|
||
|
||
由此：需要**保证金**（没有雇佣关系可约束，只能用经济约束替代）、需要**评分体系**
|
||
（替代绩效考核）、需要**技能验证和实名认证**（替代招聘筛选）。
|
||
|
||
## 4. 平台怎么赚钱：向师傅抽佣
|
||
|
||
**主要收入 = 向师傅收取订单佣金，比例按品类而定，大致 15%。** 另有一部分来自保险费提成。
|
||
|
||
这条是理解平台大量机制的钥匙：
|
||
|
||
- 平台收入与**师傅成交额**直接挂钩 → 平台和师傅既是利益共同体，又要治理师傅，存在内在张力
|
||
- **师傅每单绕过平台就能省下这 15%** → 线下交易是**结构性风险，不是个别师傅的道德问题**。
|
||
隐私号码、线下交易风控、引导线下判罚，全部由此而来
|
||
|
||
## 5. 核心矛盾：非标 + 不可预先验证
|
||
|
||
平台的大部分机制都是为解决这四个固有难点而存在：
|
||
|
||
| 难点 | 应对机制 |
|
||
|---|---|
|
||
| **服务品类高度多样且非标** | 服务类目 × 服务类型二维矩阵、履约流程配置化、按品类定佣金与计费 |
|
||
| 服务质量在购买时无法验证 | 评分体系、服务质检、满意后付款 |
|
||
| 履约发生在线下，平台不可见 | 履约节点打卡、完工照、签收码 |
|
||
| 双方都有动机绕过平台 | 隐私号码、线下交易风控、违规处罚（动因见 §4） |
|
||
|
||
第一条是万师傅区别于多数服务平台的根本难点：家居品类极多、每个品类的服务流程与技能要求都不同，
|
||
**导致"类目/流程变更"成为常态而非例外**——这正是履约流程必须做成可配置、而不能硬编码的原因。
|
||
|
||
> 治理这些矛盾的手段有其上限，见 §9。
|
||
|
||
## 6. 资金本质：担保交易
|
||
|
||
钱不是下单方直接付给师傅，而是**先到平台、服务验收后才结算给师傅**。
|
||
|
||
由此：平台必然需要清算、结算、钱包、提现整套资金体系；承担资金沉淀与合规责任，
|
||
因此才有资金监管、会计、开票等系统。"满意后付款"不是营销话术，是资金流的真实结构。
|
||
|
||
## 7. 需求侧有三种结构，付钱的和被服务的可以是不同人
|
||
|
||
- **TOC（家庭）**：下单方 = 付款方 = 服务对象，都是家庭用户本人
|
||
- **TOB（商家/企业）**：下单方和付款方是商家，**服务对象是商家的终端客户**——终端客户从未在平台下单、也不付钱。其中单量较大的客户称为 **KA（大客户）**
|
||
- **总包**：见下
|
||
|
||
**总包**是一类中间商：与 KA 签协议价、再以平台价向平台下单。需注意 **KA ≠ 总包，二者并非绝对关联**：
|
||
KA 只是"TOB 中单量较大的客户"，并不必然走总包——有的 KA 与总包签价格协议、由总包代为下单（见下方资金链）；也有 KA 直接在平台下单，不经总包。总包是"部分 KA 的下单渠道"，不是 KA 的定义属性。
|
||
|
||
当 KA 经总包下单时，资金与服务链条是三跳：
|
||
|
||
```
|
||
KA 用户 ──协议价（可月结）──▶ 总包 ──平台价──▶ 平台 ──抽佣后结算──▶ 师傅
|
||
```
|
||
|
||
**总包的收入 = 协议价 − 平台价的差价。** 注意方向：是**总包付钱给平台**，不是平台付钱给总包——
|
||
总包本质是"买平台服务能力、加价卖给 KA"的中间商，不是平台的外包供应商。
|
||
|
||
由此：售后纠纷中"客户"指谁必须先分清是哪种结构（TOC / TOB 直单 / KA 经总包 / KA 直单），否则责任判定、赔付对象、验收方全会认错人；
|
||
KA 月结带来的资金周转压力，也是平台需要向（经总包下单的）KA 对应的**总包**提供**授信**的原因。
|
||
|
||
## 8. 订单生命周期主干
|
||
|
||
所有品类、所有模式共享同一条主干：
|
||
|
||
**下单 → 支付 → 派单/接单 → 联系并预约客户 → 上门签到 → 服务履约 → 上传完工凭证 → 客户验收 → 结算**
|
||
|
||
各品类在"服务履约"环节插入不同节点（验货、检测、测量等），但主干不变。
|
||
具体节点由履约配置系统配置，见 [L2-concepts.md](L2-concepts.md)。
|
||
|
||
❓ **待补**：订单的正式状态枚举与状态机（上面是行为流程，不等于系统状态定义）。
|
||
|
||
## 9. 治理的边界：处罚必须留余地
|
||
|
||
平台靠师傅供给运转，**师傅供给是核心资产**。处罚过重会流失师傅，因此治理机制内建了大量缓冲：
|
||
|
||
- **免责次数**：每月给师傅固定的容错额度，超出才真正判罚
|
||
- **申诉机制**：系统自动判罚后，师傅可在时限内申诉，达标可自动撤销
|
||
- **新师傅保护**：新师傅前几单的首个售后工单从轻处理
|
||
|
||
**这些不是执行不严，是设计使然。** 平台与师傅的关系是双向的：
|
||
§4 说的是师傅有绕过平台的动机（利益冲突），本节说的是平台不能过度惩罚师傅（依赖关系）——
|
||
两者共同构成平台治理的张力，任何涉及"要不要加大处罚力度"的判断都必须同时考虑这两面。
|
||
|
||
由此还可推出：师傅侧的违规判定必须给出申诉通道，纯粹的"检测即处罚"在这个业务里不成立。
|
||
|
||
---
|
||
|
||
## 来源
|
||
|
||
| 内容 | 来源 |
|
||
|---|---|
|
||
| §4 收入模式、§5 非标性、§7 总包/KA 商业关系 | **业务方访谈，2026-07-31** |
|
||
| §7 订正：KA 与总包非绝对关联、部分 KA 直单 | 用户订正，2026-09-07 |
|
||
| §9 治理边界 | 客服SOP合集《申诉工单处理流程》（免责次数/申诉机制）+《新师傅0-3单第1个售后工单从轻处理流程》，反推归纳 |
|
||
| §1 双边平台、§3 自主经营 | 官网（"让用户自主选择，让师傅自主经营"）+ 客服SOP《第1章师傅入驻要求》《第12章产品规则说明》 |
|
||
| §2 报价招标 / 一口价 | 官网《如何找师傅》 |
|
||
| §6 担保交易 | 官网"满意后付款" + payment/ai-knowledge 支付系统业务语义 |
|
||
| §7 TOC/TOB | 违规拒单 prompt.txt 业务背景 |
|
||
| §8 生命周期主干 | 违规拒单 prompt.txt §1.4 + 服务履约配置化专项.docx |
|
||
|
||
## 关联
|
||
|
||
- [L2-concepts.md](L2-concepts.md) —— 二级概念，每条应能挂到本文件某一节之下
|
||
- [README.md](README.md) —— 分层原则
|