---
title: L2 · 万师傅概念体系（二级业务知识）
source_status: 2026-07-31 由原 platform-entities.md + domain-concepts.md 合并重组，并补入官网抽取与业务方访谈的新概念
level: L2（二级）
usage: 按需检索。每节标注它挂靠的 L1 条目
---

# 读之前

有明确定义、跨场景复用、**容易混淆**的名词与实体。
每一节都标注了它挂靠在 [L1-essence.md](L1-essence.md) 的哪一条——
读某个概念读不懂时，先回去读它挂靠的那条 L1。

具体规则数值不在本文件，见 [L3-rules-index.md](L3-rules-index.md)。

---

## 1. 交易与匹配

> 挂靠 **L1 §2（两种匹配范式）**、**L1 §4（抽佣模式）**

| 概念 | 定义 | 容易混淆成什么 |
|---|---|---|
| **报价招标** | 下单方发布订单，系统推送给当地合适师傅，多个师傅**竞价报价**，下单方从报价中挑选 | 不是平台定价——价格由市场竞争形成 |
| **一口价** | 价格预先设定好，师傅直接接单，无竞价环节 | 不是"报价后议价"，是无报价流程 |
| **指派** | 下单方从多个报价中选定某位师傅承接订单的动作 | 报价招标特有；一口价是师傅主动接单，没有指派环节 |
| **抢单** | 一口价模式下师傅主动接单 | 与"指派"方向相反：抢单是师傅选订单，指派是下单方选师傅 |
| **平台价** | 订单在万师傅平台上成交的价格 | 与协议价区分，见下 |
| **协议价** | KA 用户与总包签订价格协议约定的价格 | 高于平台价；差额是总包的收入 |
| **佣金** | 平台从师傅的订单收入中抽取的费用，比例**按品类而定**（大致 15%） | 向**师傅**收，不是向下单方加收 |

## 2. 参与方

> 挂靠 **L1 §1（双边平台）**、**L1 §3（师傅自主经营）**、**L1 §7（需求侧三种结构）**

### 2.1 角色

| 角色 | 含义 | 备注 |
|---|---|---|
| **师傅**（master） | 平台签约的服务执行者 | 自主经营个体，非员工；评分体系见 §5 |
| **家庭用户**（family user） | C 端消费者 | TOC 场景下同时是下单方、付款方、服务对象 |
| **商家 / 企业用户**（merchant / enterprise） | 平台入驻的商品销售方 | **两个词指同一类主体**，只是叫法不同（数仓侧记作 `etp`）；下单是为了给自己的终端客户提供售后履约 |
| **终端客户** | TOB 场景下实际接受服务的自然人 | **未在平台下单、也不付钱**；不单独建角色，是"家庭用户"在 TOB 下的对应体 |
| **KA 用户** | 大客户，通过总包而非直接在平台下单 | 与总包签价格协议，可月结 |
| **总包**（general contractor） | 对接 KA 用户、代其在平台找师傅的中间商 | 官网称"服务商"；分内部（万师傅子公司自营）/外部（合作商）；**收入是协议价与平台价的差价**，方向是总包付钱给平台 |
| **运营**（operator） | 配置活动/广告的内部角色 | 需运营权限 |
| **审核员**（auditor） | 活动/广告审批角色 | 独立审批流 |

### 2.2 下单方类型

| 类型 | 说明 |
|---|---|
| 家庭订单（TOC） | 家庭用户经 APP / 小程序下单 |
| 企业订单 / 商家订单（TOB） | **同一回事，两种叫法**。企业/商家经官网后台、APP 等渠道下单。官网按场景细分为：**电商卖家、物流企业、品牌商家、企业维保** |
| 总包订单 | 总包代 KA 用户下单 |

> ⚠️ "商家订单"和"企业订单"指的是同一类订单，文档和口语中两种叫法混用，不要误当成两种类型。

## 3. 服务与履约

> 挂靠 **L1 §5（非标性）**、**L1 §8（生命周期主干）**

### 3.1 服务矩阵：类目 × 类型（两个正交维度）

这是理解万师傅"非标"的关键结构——**同一个类目下不同服务类型的流程完全不同**。

- **服务类目**（服务对象是什么品类）：家具、灯具、卫浴、浴霸、窗帘、智能锁、健身器材、全屋定制、
  家电、净水器、墙纸、晾衣架、门、智能家居、地板、广告安装等
- **服务类型**（对它做什么）：送货、安装、测量、维修、返货、保养（另有清洗、疏通、拆旧、定制等）

### 3.2 履约与配置化

| 概念 | 定义 |
|---|---|
| **履约**（fulfillment） | 师傅接单后，按平台要求履行服务责任直到客户验收完成的整个过程 |
| **履约流程** | 师傅履行订单服务所遵循的一系列步骤，由若干节点组成 |
| **节点** | 履约流程中的关键点，标志履约进度变化（如预约客户、上门签到、拆包验货、确认完成） |
| **模块** | 节点内相对独立、可重复管理的内容单元（如"确认完成"节点下的签收单、完工照、签收码） |
| **属性 / 组件** | 描述节点内容的信息项，及其表现形式（文本输入、图片上传、扫码、签字等） |

**关键事实**：履约流程的节点组合**不是硬编码，而是按服务类型 / 地区 / 用户配置出来的**。
因此"某品类的履约有哪些节点"没有唯一答案，取决于配置——这是 L1 §5 非标性的直接产物。

### 3.3 特色服务

| 概念 | 定义 |
|---|---|
| **尾货处理** | 客户退货后同城转卖回款的服务。平台不参与交易过程，因此风控口径与普通订单不同 |
| **售后码** | 商家提供给终端客户、用于自助发起售后的凭证 |
| **专业维修 / 金牌维修师** | 面向维修类目的专项服务与师傅认证 |

## 4. 资金域

> 挂靠 **L1 §6（担保交易）**

这些概念由支付系统定义，被会计、开票、风控、资金监管等多个下游系统共同引用。

| 概念 | 定义 | 容易混淆成什么 |
|---|---|---|
| **交易**（Transaction） | 承载一次支付的完整生命周期 | 不是订单——一个订单可能对应多笔交易（部分支付/重试） |
| **支付**（Payment） | 早期模型里的核心概念 | 不是交易——新业务用"交易"，"支付"是存量兼容 |
| **渠道**（Channel） | 第三方支付通道（微信、支付宝、银联等） | 不是渠道商户——商户是在渠道下注册的身份 |
| **清算**（Clearing） | 与渠道方对账、确认资金归属 | 不是结算——清算解决"这笔钱是谁的"，实时性强 |
| **结算**（Settlement） | 资金按周期到账 | 不是清算——结算解决"钱真的到账" |
| **钱包**（Wallet） | 用户/师傅的虚拟账户余额 | 不是账户 ID |
| **授信**（Credit） | 平台给总包/企业客户的月结额度与垫付 | **不是师傅个人信用**；根源是 KA 月结带来的资金周转需求 |
| **保证金**（Earnest Money） | 师傅/总包**入驻时缴纳**的押金，违约扣 | 不是保障金 |
| **保障金**（Security Fund） | **平台发放**、用于抵扣服务费的额度 | 不是保证金；一个是交的，一个是发的 |

**结算周期**：师傅侧当前为 **T+1**，且**可由系统配置**，不是固定业务规则。具体配置见 [L3](L3-rules-index.md)。

## 5. 师傅治理

> 挂靠 **L1 §3（自主经营，无雇佣关系）**、**L1 §5（质量不可预验证）**

平台维护**两套独立**的师傅评分，容易混淆：

| 概念 | 定义 | 分数来源 | 周期 |
|---|---|---|---|
| **服务质量分** | 服务质量管理体系的核心分数，直接影响**接单资格** | 用户投诉、客服投诉、系统监测；违规成立即扣分 | 1 年一周期，满一年扣分清零 |
| **综合评分** | 订单完成后下单方给出的星级评价，影响**是否被指派** | 星级评价：低星扣分、主动五星加分 | 无清零周期，持续累加 |

计分来源、清零机制、影响面完全独立，不能互相替代。具体阈值与处置见 [L3](L3-rules-index.md)。

## 6. 保障与售后

> 挂靠 **L1 §5（核心矛盾）**、**L1 §6（担保交易）**

| 概念 | 定义 |
|---|---|
| **担保交易** | 平台居中托管订单资金，验收后才结算给师傅 |
| **服务质检** | 平台对服务过程/结果做质量检查 |
| **先行赔付** | 纠纷经核实符合保障条件时，平台先行赔付，不必等双方自行了结 |
| **商业保险** | 客户财产损失、师傅人身意外由合作保险理赔（平台的第二收入来源即来自此项提成） |
| **仲裁** | 退款申请被师傅拒绝、无法自行解决时，可申请平台仲裁 |
| **投诉** | 遇到不良师傅或交易纠纷时发起，可导致师傅扣分与处罚 |
| **售后工单** | 售后问题的承载单据，按业务类型（家庭/企业/总包）走不同处理流程 |

用户侧的三句承诺——"满意后付款""有纠纷找平台""出意外有保险"——分别对应
担保交易+质检、先行赔付、商业保险。

## 7. 工单与师傅治理体系

> 挂靠 **L1 §5（质量不可预验证）**、**L1 §9（治理必须留余地）**

### 7.1 工单类型（四种，容易混为一谈）

| 类型 | 谁发起 | 针对谁 | 用途 |
|---|---|---|---|
| **售后工单** | 用户 或 客服 | 师傅 | 服务出问题后的追责与处理主载体 |
| **二线工单** | 在线咨询升级而来 | 不定 | 一线在线客服解决不了、需外呼或跨部门协调的问题；也承接 KA 对接 |
| **申诉工单** | **师傅** | 平台的处罚决定 | 师傅对系统自动判罚提出异议 |
| **外投工单** | 用户（绕过平台） | 平台 | 用户已投诉到第三方渠道后的应对 |

**方向是关键**：售后工单是"平台追责师傅"，申诉工单是"师傅反驳平台"，
外投工单是"用户绕过平台投诉平台"。三者的立场完全不同。

### 7.2 售后工单分类体系（三层）

**服务状态（一级）× 投诉项（二级，共 16 项）× 三级分类**

| 服务状态 | 二级分类 |
|---|---|
| **服务前**（4 项） | 师傅超过24小时联系不上、指派后拖延或拒绝服务、同意或引导非平台交易、虚假预约 |
| **服务中**（9 项） | 要求客户帮忙、有不文明行为、未按规范提供服务、虚假上门、向客户泄露服务费用、导致客户对商家差评、不合理加价或虚假增费、威胁骚扰、造成商品或客户家物品损失 |
| **服务后**（3 项） | 虚假完工、散播谣言、刷单刷数据或使用外挂 |

> ⚠️ **注意主语**：16 个分类项**全部以"师傅"为主语**。这套体系不是中立的"问题分类"，
> 而是**对师傅的追责分类**——因为平台无法事前管理师傅（L1 §1、§3），只能靠事后追责治理。
> 理解这一点，才不会误以为它能用来分类"所有售后问题"。

### 7.3 工单来源：用户发起 vs 客服发起

| 来源 | 用户可见性 | 师傅可见性 |
|---|---|---|
| **用户发起** | 可查看处理进度、可自主举证 | 可见、可举证 |
| **客服发起** | **用户无感知**，无法查看进度或自主举证 | 可见、可举证 |

这个差异直接影响沟通策略——客服发起的工单，用户并不知道它存在。

### 7.4 处罚与申诉

| 概念 | 定义 |
|---|---|
| **系统自动判罚** | 平台对师傅履约数据自动监控，在**预约、签到、拒单、完工**四个节点自动判定违规 |
| **处罚单** | 自动判罚生成的处罚单据（数仓侧对应 `penalty_sheet`） |
| **违约金** | 处罚单对应的罚款，按违规类型分档 |
| **免责次数** | 每月给师傅的容错额度，额度内的违规不实际处罚 |
| **申诉** | 师傅对处罚单提出异议；系统先自动过滤，达标自动通过，未达标转人工处理 |

**四个自动判罚节点与数仓罚单枚举对应**：超时预约、超时签到、拒绝服务——
这解释了 `bd/` 中 `penalty_sheet.business_type` 那几个枚举值的业务来源。

### 7.5 其他相关概念

| 概念 | 定义 |
|---|---|
| **外投** | 用户绕过平台，向第三方渠道（12315、黑猫投诉、行政监管、社交媒体舆情）投诉 |
| **质保 / 质保期** | 服务后的保修期。质保期内师傅需免费上门处理自身原因造成的问题 |
| **服务确认码** | 完工时由客户提供给师傅的验收凭证，师傅索要确认码但未实际完成服务即"虚假完工" |
| **普通工单 / 紧急工单** | 按紧急度分级，响应时效不同；涉及人身安全、报警、威胁骚扰等为紧急 |
| **双向响应** | 时效考核口径：需联系不同的两方（如同时联系用户和师傅），只联系一方不算 |

## 8. 业务域与系统地图

> 技术侧视角，供定位系统归属用

### 8.1 数仓业务域缩写

| 缩写 | 业务域 | 对应 |
|---|---|---|
| mst | master（师傅） | §2.1 师傅 |
| usr | user（用户） | §2.1 家庭用户 |
| etp | enterprise（企业） | §2.1 商家 / 企业 |
| order | order（订单） | 订单域 |
| bas | basic（基础） | 公共基础数据 |
| fmis | finance（财务） | 财务域 |
| kf | customer_service（客服） | 客服域 |

### 8.2 资金 / 风控系统域

支付系统（资金流转中枢）、会计系统（记账）、开票系统（税务）、风控系统、
资金监管、清分结算、收银台、保险系统。

> 两套划分不是同一体系（前者按数仓表名前缀，后者按系统边界），存在交叉但非一一映射。

---

## 来源

| 内容 | 来源 |
|---|---|
| §1 一口价/报价招标/指派、§3.1 服务矩阵、§3.3 特色服务、§6 仲裁投诉 | 官网 wanshifu.com（首页 / 如何找师傅 / 商家服务 / 客服中心），2026-07-31 |
| §1 协议价·平台价·佣金、§2.1 KA 用户与总包关系、§4 结算周期 | 业务方访谈，2026-07-31 |
| §2.1 角色（商家/师傅/家庭用户/运营/审核员） | dev-knowledge-base `team-conventions/glossary.md` |
| §2.1 总包、§5 评分体系、§6 售后工单、**§7 工单与治理体系全节** | 客服工单SOP与对外规则合集（企业/家庭售后工单处理流程、申诉工单处理流程、二线工单处理流程、高投外投SOP），2026-08-03 |
| §3.2 履约配置化 | 服务履约配置化专项.docx |
| §4 资金域概念 | payment/ai-knowledge 支付系统业务语义 |
| §8.1 数仓缩写 | `bd/warehouse.md` |

## 关联

- [L1-essence.md](L1-essence.md) —— 各节挂靠的根级前提
- [L3-rules-index.md](L3-rules-index.md) —— 本层概念对应的具体规则与数值