7.8 KiB
title, source_status, level, usage
| title | source_status | level | usage |
|---|---|---|---|
| L1 · 万师傅业务本质（根级业务知识） | 2026-07-31 业务方访谈确认收入模式、总包/KA 商业关系、核心矛盾表述；仅 §8 状态机一处待补。2026-09-07 订正 §7：KA 与总包非绝对关联，部分 KA 直接下单 | L1（根级） | 设计为常驻上下文，可整份放入 system prompt |
读之前
这是万师傅业务的世界观层——从业者视为空气、从不言说，但一旦理解错， 后面所有推理都会歪掉的那些前提。
收录标准：老员工觉得"这还用说？"、新人问了会被当成傻问题，但答错整条推理链错位。 详细的名词定义在 L2-concepts.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。
❓ 待补：订单的正式状态枚举与状态机（上面是行为流程，不等于系统状态定义）。
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 —— 二级概念，每条应能挂到本文件某一节之下
- README.md —— 分层原则