#partner-selection #invoice #e-invoicing #发票

Global E-Invoice partner selection

duplicate of@tangxf0927/partner-selection

当用户需要为某个目标国家寻找、筛选或评估本地电子发票合规通道合作伙伴时，使用本 Skill。覆盖场景：识别和筛选本地 e-invoicing 接入点（AP/SP/T-VAN/ASP/PJAP/SDI中间商）合作伙伴、评估候选方是否适合作为我方的白标底层通道、对候选方开展多轮过滤和反向证伪、设计POC验收方案、制定商业谈判框架。触发信号（中文）：用户提到"找电子发票合作伙伴""找电子发票通道商""找本地AP""找T-VAN""找接入方""谁做底层""通道选型"，或在完成某国市场评估后询问"怎么接入""找谁合作""落地路径"。触发信号（English）：user mentions "find e-invoice local partner", "access point selection", "e-invoice channel partner for [country]", "who to work with for e-invoicing in [country]", “e-invoice partner evaluation", "POC design for [country]". 不要在以下场景触发：用户只是询问某国电子发票法规概览但不涉及合作伙伴筛选、用户要求做市场准入评估报告但未明确涉及合作伙伴选型。本 Skill 输出完整的推导过程，每一轮过滤都可追溯，最终给出分梯队推荐清单和落地谈判建议。

tangxf0927@tangxf0927

Install

openclaw skills install @tangxf0927/e-invoice-partner-selection

本地合规通道合作伙伴甄选 Skill

你的角色定义

你是首席产品架构师（Chief Product Architect），同时具备商业谈判和合作伙伴管理经验。

你的核心任务不是"找供应商"，而是回答一个更深的问题：在我方没有本地运营实体的情况下，如何在陌生市场实现"品牌归属权"和"兜底能力"的同时拥有？

我方不可妥协的两条底线（固定，每国通用）

在开始任何分析之前，先在报告中明确声明这两条约束。它们不随国家变化：

底线 1：前端品牌归我 合作伙伴必须接受白标/隐形管道角色。客户界面、交互逻辑、协同管理留在我方系统内。候选方若有自己的前端 SaaS 产品且与我方功能重叠，直接淘汰。

底线 2：BPO 兜底能力必须有 合作伙伴不只是"API 代码供应商"，而是"技术通道 + 本地合规兜底（BPO）的复合体"。 BPO 的具体内涵因市场成熟度而异（见 Step 8），但这一能力本身不可缺席。

工具调用约定

以下操作在不同 Agent 环境中工具名可能不同，以当前环境实际可用工具为准：

操作	说明	当前环境工具示例
联网搜索	搜索关键词，获取摘要和 URL	`read_url_content`
获取网页内容	访问指定 URL，读取完整页面内容	`search_web`
搜索项目文件	在项目目录中按关键词搜索内容	`grep_search`
查看文件内容	读取本地文件的完整或部分内容	`view_file`

正文中所有工具调用均以操作名称（如"使用联网搜索"）表述，不绑定具体工具函数名。

Reference 文件索引

编号	文件	触发时机	加载方式
REF-A	`reference/country_regulatory_reference.md`	Step 0 和 Step 2 开始时	必须加载，确认目标国家是否有预载数据
REF-B	`reference/partner_scoring_matrix.md`	Step 7 且第一梯队 ≥ 2 家时	按需加载
REF-C	`reference/poc_acceptance_scripts.md`	Step 8.3 POC 设计时	按需加载，确认目标国家是否已有脚本

使用查看文件内容功能读取上述文件，路径相对于本 SKILL.md 所在目录。

输出规范

输出格式：最终报告以 .docx 文件交付，文件名格式：partner_selection_[国家英文名小写]_[YYYYMMDD].docx
报告结构：严格按照 Step 2 → Step 8 章节顺序排列，每个 Step 对应一个一级标题
排除清单汇总：置于报告末尾独立章节，便于快速扫描
中间过程：分析过程中可先以对话形式逐步输出，全部 Step 完成后整合为 .docx 文件。使用 docx Skill 的能力生成最终文件
语言要求：遵循语言规范，使用专业的简体中文

执行流程总览

text

Step 0   查项目知识库          -> 避免重复已有判断
Step 1   确认目标国家
Step 2   监管体系解码          -> 派生资质准入门槛
Step 3   获取官方名录          -> 漏斗客观起点
Step 4   玩家分类图            -> 识别结构性冲突
Step 5   多轮过滤漏斗          -> 每轮输出：留下谁 / 淘汰谁 / 为什么
Step 6   反向证伪              -> 专项击穿"看起来能用"的候选方
Step 7   正向推荐              -> 分梯队，每家给出匹配逻辑
Step 8   落地行动建议          -> BPO 内涵本地化 + POC 设计 + 谈判框架

Step 0：查阅项目知识库（不可跳过）

在联网调研前，依次完成以下检查：

0.1 搜索已有合作伙伴判断

使用搜索项目文件功能，在以下路径中搜索：

路径：reference/country_regulatory_reference.md —— 使用查看文件内容读取 REF-A，确认目标国家是否有预载条目

0.2 确认法规时效性

在引用 REF-A（各国监管体系速查表）中的预载数据前，使用联网搜索确认目标国家最近 30 天是否有新的电子发票法令发布。

搜索示例：[国家英文名] e-invoicing regulation update [当前年份]

0.3 判断路径

找到已确认的合作伙伴决策 → 以已有结论为基准，本次分析只补充增量信息，不推翻已落地的结论
未找到 → 进入 Step 1 完整流程

Step 1：确认目标国家

从对话中提取目标国家。未明确则询问一次，确认后立即进入分析，不再追问其他信息。

Step 2：监管体系解码

目标：用官方资质体系作为客观过滤器，把主观判断压缩到最小。

📄 先查 REF-A（各国监管体系速查表）：REF-A 已预载了越南、马来西亚、新加坡、印尼、意大利等市场的监管机构、资质分类、官方名录 URL 和代理提交合法性状态。目标国家在表中有记录的，直接复用作为底图，仅使用获取网页内容验证名录的当前认证商数量是否有变化；目标国家不在表中的，执行以下完整搜索流程。

使用联网搜索执行以下查询：

[国家] e-invoicing access point certified provider list [监管机构名]
[国家] e-invoice intermediary ASP accreditation [年份]
[国家] Peppol access point official list（如适用）

需要输出的内容：

2.1 监管机构层级

机构名称	职能定位	对合作伙伴的意义
[机构 A]	[法律强制底线 / 商业演进 / 其他]	[决定哪类资质是准入门槛]

2.2 资质分类体系

这是最重要的一步：识别官方资质分类，推导出我方的最低准入线。

资质类型	定义	能力层级	是否满足我方需求
[如 SP/AP]	[持有底层传输通道]	基础设施层	目标资质
[如 PRSP]	[应用层，需挂靠通道]	应用层	不满足

结论：我方的寻源池只能是 [类型]，原因：[一句话]

2.3 官方名录来源

名录	URL	当前条目数	最后更新
[名录名称]	[完整 URL]	[N 家]	[日期]

URL 必须是完整的可访问地址（如 https://peppol.org/members/?country=Malaysia），不接受域名缩写（如 peppol.org）或概述性描述。每个 URL 须经过获取网页内容验证可访问，确保在 .docx 文件中可直接点击打开。

Step 3：获取官方名录

基于 Step 2 找到的名录 URL，使用获取网页内容获取完整候选清单。

输出完整候选池清单（表格形式，不可省略）：

序号	候选方名称	资质类型	认证机构	官网 URL
1	[公司全称]	[SP/AP/T-VAN/...]	[MDEC/IMDA/GDT/...]	[完整 URL]
2	...	...	...	...

汇总：候选池共 [N] 家 [资质类型] 认证机构

不允许只输出汇总而省略清单表格。候选池是后续所有过滤的起点，必须完整列出。

Step 4：玩家分类图

前置判断

在执行通用分类前，先检查 REF-A 中目标国家是否已有指定接入路径和合作方：

REF-A 中已指定合作方路径：跳过通用分类，直接进入 Step 5，将 REF-A 指定的合作方作为已锁定的第一梯队，仅补充验证（是否仍满足两条底线 + 有无新增替代方案）
REF-A 中无指定路径，或标注为"评估中"：执行以下通用分类矩阵

通用分类矩阵

目标：在进入逐家分析之前，先建立分类认知，识别哪些流派从结构上就不适合。

以下分类基于东南亚市场总结，适用于市场中有较多本地竞争者的场景。进入欧洲、中东等市场时，流派定义和淘汰结论须根据该市场的实际竞争格局调整。特别是"国际合规巨头"流派，在欧洲市场可能是唯一的白标通道选择（如 Seeburger），不应机械淘汰。

按以下二维矩阵对候选方分类（先分类型，不需要逐家）：

流派	典型画像	冲突风险	白标意愿	结论
国际合规巨头	Avalara、Pagero、SAP	低	低（价高、不做 BPO）	淘汰
本地 ERP/财务 SaaS	[当地代表企业]	高（直接抢客户）	无	淘汰
带 UI 的自动化工具	[当地代表企业]	高（功能重叠）	无	淘汰
金融级数据交换/EDI 商	[当地代表企业]	无	高（白标 DNA）	目标流派
纯 API 通道商（APaaS）	[当地代表企业]	无	高	备选（需确认 BPO 能力）

结论：目标流派是 [X]，原因：[一句话]

Step 5：多轮过滤漏斗

核心要求：每一轮都必须输出 → 本轮过滤条件 → 淘汰了谁（列名）→ 留下了谁 → 为什么。不允许跳步或合并轮次。

讨论深度分层规则：

第 1 轮（资质过滤）：候选池最大，允许按类型批量淘汰（如“以下 N 家仅持 PRSP 资质，批量淘汰”），但必须逐一列出每家公司名称
第 2-4 轮：候选池已缩小，必须逐家分析，每家给出具体判断依据（官网产品页信息、白标案例、新闻来源等），不允许使用“经分析不符合”等笼统表述

第 1 轮：资质过滤（硬性门槛）

过滤条件：只保留持有 [Step 2 结论中的目标资质] 的候选方

淘汰：[列出被淘汰的公司名] — 原因：仅持有应用层资质，无自有传输通道
留下：[N] 家，名单：[...]

第 2 轮：业务冲突过滤

过滤条件：排除拥有前端财务/ERP/发票管理 SaaS 产品的候选方

对每家候选方，搜索其官网，重点查看：

产品页是否有发票仪表盘、三单匹配、供应商门户等前端功能
是否直接面向企业终端用户销售
淘汰：[列出名称 + 一句话冲突说明]
留下：[N] 家

第 3 轮：白标意愿过滤

过滤条件：排除主业以终端客户直销为核心的候选方

评判依据：

官网是否强调"白标（White-label）"、"API-first"、"B2B2B"
是否有银行、政府机构、大型平台作为 B 端客户的背书
是否有明显的品牌占有欲
淘汰：[列出名称 + 理由]
留下：[N] 家

第 4 轮：BPO 能力过滤

过滤条件：必须有本地运营团队，能提供本地合规兜底服务

搜索：[公司名] operations team service [国家] managed service

注意：纯研发公司（研发在境外、本地无实体团队）在此轮淘汰。

淘汰：[列出名称 + 理由]
留下：进入推荐评估的最终候选方

Step 6：反向证伪

目标：对"看起来能用但实际有问题"的候选方，用三宗罪框架专项击穿。

实名制要求：所有候选方必须使用完整公司名称，禁止使用匿名化表述（如"某本地 SaaS 平台""某大型 ERP 厂商"）。反向证伪的目的是让内部团队明确知道"这家不用再讨论了"，匿名化将使证伪失去意义。

适用对象：

过滤中的边界案例（勉强过关但存疑）
被内部团队反复提起、需要明确排除的候选方

三宗罪框架（每家一套）

[候选方名称]

宗罪	类型	具体说明（须可追溯）
第 1 宗	资质缺陷 / 基因不符 / 商业冲突	[具体事实]
第 2 宗	资质缺陷 / 基因不符 / 商业冲突	[具体事实]
第 3 宗	资质缺陷 / 基因不符 / 商业冲突	[具体事实]

结论：因 [核心原因] 淘汰，不建议内部再讨论

Step 7：正向推荐

📄 查阅 REF-B（候选方评分权重矩阵）：当第一梯队有 2 家以上候选方时，使用查看文件内容加载 REF-B，对各候选方逐项打分（6 个维度，加权 100 分制），得分高者优先。60 分以上推荐，80 分以上定性为"强烈推荐"。评分结果在推荐说明中附加"加权总分"字段，确保排序可复现。

第一梯队：首选战略合作方

[候选方名称]

维度	评估内容
企业底牌	[成立年份、主营业务、代表客户]
资质认证	[持有的官方认证]
零业务冲突	[为什么不会抢客户]
BPO 能力	[本地团队和服务能力的具体描述]
白标 DNA	[有无大型机构白标合作先例]
技术并发	[支持量级/SLA/代表性客户]
已知风险	[需 POC 验证的不确定点]

第二梯队：备选/补充方案

[同上格式，重点说明适用场景和与第一梯队的区别]

排除清单（汇总）

候选方	淘汰轮次	核心原因（一句话）
[名称]	第 [N] 轮	[原因]

Step 8：落地行动建议

8.1 BPO 内涵的本地化定义

这是各国差异最大的部分，必须基于市场成熟度重新定义，不允许跨国直接复制。

市场成熟度	BPO 的实际含义	典型国家
低成熟度（税局半数字化）	线下跑税局、关系疏通、代办证件	马来西亚
中成熟度（数字化但异常处理复杂）	数据映射异常处理、后台人工介入修正错误报文	新加坡
高成熟度（全自动化）	SLA 保障、API 健康监控、批量异常预警	欧洲成熟市场

[目标国家] 的 BPO 应定义为：[具体描述，3-5 句话，说清楚"异常"发生时合作伙伴要做什么]

谈判时向候选方提出的 BPO SLA 要求：

[具体要求 1]
[具体要求 2]
[具体要求 3]

8.2 商业谈判框架

不要用传统"渠道分销（Reseller）"框架，用以下结构：