14 KiB
title, source_status, level, usage
| title | source_status | level | usage |
|---|---|---|---|
| L2 · 万师傅概念体系（二级业务知识） | 2026-07-31 由原 platform-entities.md + domain-concepts.md 合并重组，并补入官网抽取与业务方访谈的新概念 | L2（二级） | 按需检索。每节标注它挂靠的 L1 条目 |
读之前
有明确定义、跨场景复用、容易混淆的名词与实体。 每一节都标注了它挂靠在 L1-essence.md 的哪一条—— 读某个概念读不懂时，先回去读它挂靠的那条 L1。
具体规则数值不在本文件，见 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。
5. 师傅治理
挂靠 L1 §3（自主经营，无雇佣关系）、L1 §5（质量不可预验证）
平台维护两套独立的师傅评分，容易混淆：
| 概念 | 定义 | 分数来源 | 周期 |
|---|---|---|---|
| 服务质量分 | 服务质量管理体系的核心分数，直接影响接单资格 | 用户投诉、客服投诉、系统监测；违规成立即扣分 | 1 年一周期，满一年扣分清零 |
| 综合评分 | 订单完成后下单方给出的星级评价，影响是否被指派 | 星级评价：低星扣分、主动五星加分 | 无清零周期，持续累加 |
计分来源、清零机制、影响面完全独立，不能互相替代。具体阈值与处置见 L3。
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 —— 各节挂靠的根级前提
- L3-rules-index.md —— 本层概念对应的具体规则与数值