交付部门标准化 SOP 框架
用统一入口、统一流程、统一表格和统一沉淀机制，把 BD 需求、项目推进、跨部门协作和结果归档串成可复制的交付系统。
交付部是 BD 需求的统一承接方
交付部负责需求收集、项目识别、流程分流、标准化文档建设及跨部门协同。 交付部能直接处理的事项由交付部完成；涉及技术、市场、财务、运营等专业判断的事项， 由交付部牵头对应部门共同完成，并沉淀为标准答案、模板和流程，以降低 BD 和中后台的重复沟通成本。
所有 BD 需求先进入交付部
BD 的所有生态合作、项目推进、项目方问题、流程咨询，都可以先进入交付部。
判断类型、归属和下一步
交付先判断能否自行解决、是否需要其他部门参与、是否已有标准答案或标准流程。
重复问题进入标准化资产
将重复问题沉淀为 FAQ、话术、模板和 SOP，降低 BD 与中后台重复沟通成本。
三项职责：承接、识别、标准化
交付部负责把问题讲清楚、判断归属、推动结果，并把结果沉淀成下次可复用的标准内容。
1. 承接 BD 所有需求
BD 的所有生态合作、项目推进、项目方问题、流程咨询，都可以先进入交付部。
- 接收 BD 需求
- 判断需求类型
- 判断是否可自行解决
- 判断是否需要其他部门参与
- 跟进问题直到有结果
- 将重复问题沉淀为标准化内容
2. 识别项目类型
交付部需要在项目进入后快速判断项目属于哪一类，并明确所需部门与下一步动作。重点识别 AI / RWA / 普通接入等路径。
- 区分项目接入与普通咨询
- 判断是否属于 AI / RWA 项目
- 判断是否涉及技术、市场、财务、运营、合规
- 明确项目类型、所需部门、下一步动作
- 为项目选择合适推进路径
3. 建立标准化回答体系
交付部负责搭建 BD 可直接使用的 FAQ / 话术库，但不一定负责回答所有专业问题。
- 交付收集问题并分类整理
- 交付判断归属部门
- 对应部门提供专业答案
- 交付整理成标准 FAQ
- 同步给 BD 使用并持续更新
FAQ / 话术库标准闭环
交付不是替所有专业问题背锅，而是把问题收集、分流、沉淀成 BD 可复用的标准答案。
FAQ 分类建议
- 技术接入 FAQ
- Gas Fee FAQ
- 宣发支持 FAQ
- 活动合作 FAQ
- 项目信息填写 FAQ
- 项目方常见问题 FAQ
- 内部协作 FAQ
边界原则
- 交付负责收集、分类、判断归属、整理沉淀
- 专业部门负责专业判断和执行支持
- 交付负责把问题讲清楚，并推动对方给出答案
- 答案回流后进入 FAQ / 模板 / SOP
9步流程把项目从入口推到归档
每个项目都有入口、有判断、有排期、有跟进、有升级、有沉淀。
从需求进入到分类分流
前三步解决“需求从哪里来、是什么类型、该走哪条路径”。
步骤 1：BD 提交需求 / 项目信息
BD 在与项目方初步沟通后，将需求提交给交付部。
- 项目信息表
- BD 群需求同步
- 项目合作群信息
- 其他内部需求入口
步骤 2：交付初步识别需求
交付部判断：
- 这是项目接入需求，还是普通咨询？
- 是否涉及技术、市场、财务、运营？
- 交付能否直接处理？
- 是否需要跨部门协作？
- 是否已有标准答案或标准流程？
步骤 3：项目分类与分流
交付根据项目需求进行分类，整理判断标准，明确项目类型、所需部门、下一步动作。AI / RWA 项目需结合专项准入评估结论后再分流。
从合作方向到进度表
中间三步解决“能不能推进、拉哪些人、如何可视化跟进”。
步骤 4：对齐合作方向
交付与 BD 确认：
- 项目真实需求是什么
- 当前是否适合推进
- 哪些需求可以支持
- 哪些需求需要调整
- 是否进入 Plan A / B / C 合作方案
步骤 5：建立对应协作入口
根据项目类型决定是否建群、建什么群、拉哪些人。
- 只拉当前阶段需要的人
- 不是所有项目都拉所有人
- 按项目类型配置协作入口
步骤 6：在生态项目进度表中更新合作方案和时间表
交付整理一版合作方案，并在进度表中更新，内容包括：
- 项目类型
- 合作方向
- 当前阶段
- 所需支持
- 参与部门
- 下一步动作
- 关键时间点
- 当前卡点
从跨部门推进到项目归档
最后三步解决“谁来配合、卡点如何升级、结果如何沉淀”。
步骤 7：跨部门协作处理
当交付无法独立解决时，由交付牵头对接对应部门。标准动作：
- 交付整理背景
- 交付明确问题
- 交付找到对应部门
- 对应部门给出专业判断
- 交付同步给 BD / 项目方
- 交付沉淀为 FAQ / 模板
步骤 8：进度跟进与卡点升级
交付维护生态项目进度表，持续更新项目状态、下一步动作、卡点和负责人，必要时升级。
步骤 9：结果同步与归档
项目完成后，交付负责归档。归档内容包括：
- 项目信息
- 合作类型
- 合作方案
- 项目群链接
- 技术接入记录
- Gas Fee 申请记录
- 宣发记录
- 活动记录
- 卡点与解决方案
- 可沉淀的 FAQ
5个模块搭建交付工作系统
后续交付部门可以分成 5 个标准模块来搭建。
BD 需求入口
让 BD 知道所有需求往哪里提交。
项目识别和分类规则
让交付快速判断项目走哪条流程。
标准 FAQ / 话术库
减少 BD 和中后台重复沟通。
跨部门协作机制
明确交付与其他部门的边界。
进度追踪和复盘归档
让所有项目状态可视化，避免项目丢失。
BD 需求入口：统一提交形式
目标：让 BD 知道所有需求往哪里提交。
项目信息表
项目方基础信息、合作诉求、当前阶段与对接人统一收集。
需求收集表
日常咨询、临时需求、跨部门协同需求统一登记。
Gas Fee 申请指引
明确 Gas 申请条件、提交流程、审核与发放记录要求。
活动预算申请指引
规范活动预算申请材料、审批路径与费用统计口径。
宣发需求提交模板
统一宣发需求字段、时间节点与市场协同信息。
识别规则、FAQ、协作与归档
项目识别和分类规则
目标：让交付快速判断项目走哪条流程。
- 项目分类标准
- 是否需要技术判断
- 是否需要市场判断
- 是否需要财务审批
- 是否需要运营负责人拍板
标准 FAQ / 话术库
目标：减少 BD 和中后台重复沟通。
- 技术接入 FAQ
- Gas Fee FAQ
- 宣发支持 FAQ
- 活动合作 FAQ
- 项目信息填写 FAQ
- 项目方常见问题 FAQ
- 内部协作 FAQ
跨部门协作机制
目标：明确交付与其他部门的边界。
- 交付负责牵头、整理、分流、跟进和沉淀
- 专业部门负责提供专业判断和执行支持
进度追踪和复盘归档
目标：让所有项目状态可视化，避免项目丢失。
- 生态项目进度表
- 项目状态字段
- 下一步动作字段
- 卡点字段
- 负责人字段
- 周报机制
- 项目归档机制
Botchain RWA项目准入和评估
RWA 是什么，以及为什么要评估
RWA 代币化本质
- 为链下资产创建链上凭证或权益映射
- 代币可代表所有权、收益权、债权或相关法律实体权利
- 在满足合规前提下，可转让、交易或作为链上抵押品
代币化的主要价值
- 提升资产可分割性
- 提高结算效率
- 扩大全球触达与可交易性
- 连接 TradFi 与链上金融场景
机构参与必须关注
- 法律权利是否清晰
- 底层资产托管是否可靠
- KYC / AML 机制是否到位
- 智能合约安全与赎回机制
- 链下资产验证与信息披露
对交付部的含义
RWA 作为公司的重点孵化对象，不是普通 EVM 部署项目。进入交付排期前，必须先完成资产结构、合规、托管、赎回与信息披露评估。 AI 项目则重点看产品真实性、Agent / 算力或协议交互、链上部署可行性与长期建设能力。
五个关键指标判断项目可靠度
团队背景与透明度
审查团队金融、区块链、资产管理背景；官网/白皮书披露可被 LinkedIn 等渠道核验。匿名或信息不透明项目风险更高。
法律合规性
确认是否符合所在地监管要求；是否具备 KYC/AML；是否与合规托管机构合作，并提供法律文件供审查。
资产质量与估值透明
关注资产类型、市场价值、估值流程与流动性。房地产等项目应提供第三方评估；估值机制应可定期更新并降低信息不对称。
技术安全性
智能合约需经可信审计；优先检查预言机可靠性、多签钱包、保险或风控机制，避免未审计合约带来资产损失风险。
社区与市场反馈
参考社区活跃度、更新频率、用户口碑、交易量与流动性表现，综合判断项目稳定性和市场认可度。
交付侧初步评估，运营和战略部决策
交付负责材料齐套与交付可行性初评；是否立项由运营与战略部决策。
产品真实性与链上可行性
- 是否有清晰产品形态与真实交互场景
- 是否涉及 AI Agent、算力、数据或协议经济
- 是否具备 EVM 兼容部署路径
- 是否有技术对接人与可持续建设计划
- 是否能沉淀为可复用交付模板
资产、合规与托管闭环
- 底层资产类型、权属与估值是否可验证
- 法律主体、监管边界、KYC/AML 是否齐备
- 托管安排、赎回机制、信息披露是否明确
- 智能合约审计、预言机与多签风控是否到位
- 是否具备可执行的链上映射与结算路径
初评与材料准备
- 整理项目背景、需求单与问题清单
- 核对材料齐套度与交付可行性
- 协同技术 / 合规补充缺口说明
- 形成初步评估意见，提交运营与战略部
立项结论仅三态
- 通过：进入立项、澄清与交付排期
- 有条件通过：先补齐合规 / 技术 / 材料缺口
- 拒绝或暂缓：写明原因与复评条件
- 未决策通过：不建正式交付群、不排期、不承诺上线日
每个 RWA 项目必须齐套五项交付件
需求单
明确项目诉求、资产结构、合规边界、部署目标和关键依赖。
Owner
指定内部唯一负责人，对进度、卡点升级和结果闭环负责。
排期
按里程碑锁定时间：澄清、联调、预发、上线、验收。
验收表
上线前按标准验收项逐项确认，形成可归档结论。
风险记录
持续记录合规、资产、技术、运营风险及应对动作。
内部立项、需求澄清，到上线后持续跟踪
内部立项与需求澄清
- 评估通过后进入内部立项
- 确认 Plan A / B / C 与优先级
- 召开需求澄清会，输出需求基线
- 基线外变更走变更单并重排期
- 未立项：不建正式群、不承诺上线日
上线验收
- 按验收表逐项核对
- 确认链上路径、文档与风险告知
- 验收结论：通过 / 带缺陷通过 / 打回
- 验收材料归档至项目档案
- 未通过验收不得进入运营交接
运营交接与后续跟踪
- 交接 FAQ、异常升级路径、值守接口
- 同步宣发 / 客服 / 运营所需资料
- 设定观察期与跟踪指标
- 风险记录持续更新至关闭
- 交接完成后状态转为运维观察 / Completed
交付部 SOP 落地动作
统一需求入口
项目信息表、需求收集表、Gas Fee 申请指引、活动预算申请指引、宣发需求提交模板统一管理。
项目进度表维护
持续更新阶段、下一步动作、卡点、负责人和关键时间点。
FAQ / 话术沉淀
沉淀技术接入、Gas Fee、宣发、活动、项目信息填写、项目方常见问题、内部协作 FAQ。
跨部门卡点升级
整理问题背景、判断需求、责任部门和截止时间，推动专业部门给出判断。
项目归档
归档项目信息、合作方案、接入记录、Gas Fee、宣发、活动、卡点解决方案与复用内容。
统一入口，标准流程，持续沉淀
交付部承接 BD 需求，识别项目类型，推动跨部门协作，并把结果沉淀为 FAQ、模板与 SOP。 RWA 项目先由交付侧初评，再由运营和战略部决策；齐套交付件后进入排期、验收与运营交接。