我们是 10 人 AI Agent 支付团队，产品刚上线：第一位商业化人员该招 BD，还是 GTM／产品运营？

!先给结论：先找能把客户问题带回产品的人

对 10 人左右、产品刚上线的 AI Agent 支付团队，岗位选择不应从“BD 更重要还是运营更重要”开始，而应从商业化瓶颈开始：团队究竟缺少客户机会，还是缺少对客户、场景和转化路径的理解？

如果创始人已有明确的目标客户、稳定引荐和可复用的成交路径，可以招偏 BD 的人；如果还在确认谁会买、为什么买、如何接入和持续使用，更适合 GTM／产品运营型人才。无法判断时，可先设计一个以 GTM 为主、兼具 BD 能力的验证型岗位，用真实客户任务校准职责，再决定是否拆分。

!AI Agent 支付产品为什么需要“问题翻译者”

支付产品的客户通常不止一个角色：业务关心收入和效率，财务关心对账，技术关心接口与稳定性，风控和合规关心权限、数据与异常处理。客户说“想让 Agent 自动收款”，实际可能指订阅扣款、分账、退款、授权或人工兜底。产品刚上线时，团队还没有足够样本把需求分层，商业化人员必须把模糊愿望翻译成可验证场景。

关于 AI 如何支持轻量创业，人民网对 OPC（“单人+AI”）的报道提到，创业者会用 AI 承担研发、营销和客服等环节；武汉市科技创新局报道的“创了吗”项目，也将产品设计、客户开发、销售转化和运营管理列为智能体可以辅助的工作。两篇报道分别见人民网报道和武汉市科技创新局报道。这不代表销售可被工具替代，反而要求早期商业化人员能把工具、客户流程和人工判断连起来。

!先判断团队卡在哪里

招聘前，把最近两周的客户工作按下表归类。岗位名称只是结果，瓶颈才是起点。

若四种现象同时存在，创始人应先参与数轮访谈，区分使用者、付款人、技术接入人和风险决策人，再确定招聘重点。

!什么情况下应该招 BD

BD 适合这样的前提：目标客户已经相对清晰；创始人或顾问能提供一批高质量引荐；产品价值可以在短沟通中说明；试点边界、交付责任和升级路径已有基本共识。此时 BD 的价值在于扩大触达、经营关系、管理多线程决策并推动试点或商业条款落地。

岗位说明不要只写“拓展市场”，而要写清目标客户来源、有效对话定义、从首次沟通到试点的退出条件、需由创始人确认的承诺，以及客户反馈进入产品待办的格式。候选人不必只来自支付行业，更重要的是能把“想定制”追问成业务结果，能在信息不完整时推进关系，也能诚实管理预期。

面试可给出一个情境：客户希望 Agent 自动完成收款和退款，却无法说明责任边界。要求候选人写出首次会议议程、必问问题和不应承诺的内容。能否识别决策链与风险边界，比“手上有多少资源”更有参考价值。

!什么情况下应该招 GTM／产品运营

如果每次演示都要重新解释产品，或者团队仍在寻找高频场景，GTM／产品运营更贴合当前任务。这个岗位不是单纯做内容或维护后台，而是把市场学习组织成可重复的动作：设计访谈和试用流程，整理客户语言，定义激活事件，建立线索到使用的阶段，并推动产品、工程与创始人共享优先级。

支付场景还要关注接入前后的摩擦：客户准备哪些资料，技术团队如何集成，异常支付谁处理，财务如何对账，用户怎样理解 Agent 的权限边界。考核可以围绕有效学习，而非虚荣指标：完成结构化访谈，形成一个高频场景的演示脚本，让试用客户走完关键动作，并解释每个流失节点。

这个岗位也必须具备商业敏感度。只会记录反馈会造成需求堆积，只会做活动又不理解支付链路，则难以推动采用。好的候选人能把反馈写成“用户—场景—阻碍—证据—动作”，并说明哪些问题暂不开发。

!不确定时，设计一个验证型混合岗位

当团队无法判断时，可将岗位设计为 60% GTM／产品运营、40% BD。前 8—12 周不把固定成交额作为唯一目标，而是要求候选人与创始人共同拜访客户、维护一小组机会，并串起访谈、演示、试用和复盘。

这种安排能同时暴露定位问题和销售问题：如果客户愿意交流却无法完成关键动作，重点在产品与 GTM 闭环；如果机会主要依赖创始人背书，BD 体系还未形成。岗位名称要如实反映陌生拓展、试用设计和产品协作的比例，避免用“纯 BD”吸引错配人选。

!招聘前补齐四份材料

1. 客户假设一页纸：目标行业、典型公司、付款链路、触发点、替代方案和不能服务的边界。

2. 产品演示脚本：从客户问题开始，说明 Agent 做什么、需要哪些权限、哪些环节仍由人工确认。

3. 试点协议草案：成功标准、周期、数据范围、集成责任、费用与退出条件。

4. 反馈日志：记录客户原话、使用场景、证据、优先级和下一动作。

团队可以把公开数字名片或创业社区作为拓展关系的入口，但社交展示不等于购买意愿。广州“穗@i企”企业家数字名片的案例显示，数字名片可用于官方认证、信息更新、二维码分享和多角色管理；这说明它有助于降低身份确认成本，却不能直接推导成交结果，详见广东省政务服务和数据管理局报道。Bonjour! 的社区与数字名片定位可在官网了解，实际合作仍需回到具体场景和验证动作。

!30 天入职验证计划

第 1 周：理解与校准。 跟随创始人参加客户访谈，画出付款链路和决策链，形成问题清单，不急于扩大线索池。

第 2 周：小范围触达。 选择一个细分场景做定向邀约和演示，记录客户原话；每次沟通都要获得明确下一步，而不只是“感兴趣”。

第 3 周：推动试点。 把高频场景整理成演示脚本和试点清单，协调技术、风控与客户方责任人，暴露集成和合规阻碍。

第 4 周：复盘决策。 输出客户画像修订版、机会分层、试点漏斗、产品问题优先级和下一阶段招聘建议。以事实决定岗位是否继续偏 BD、偏 GTM，或增加销售工程与客户成功能力。

!面试评分表：用行为证据替代头衔

评分时要求候选人讲清具体行为、结果和复盘，不要只看“资源丰富”“执行力强”等自我描述。

!汇报、权限与薪酬怎么设计

第一位商业化人员需要一位创始人直接负责，并明确三类权限：可自行决定的客户沟通与实验；必须与产品或技术共识的试点变更；涉及价格、数据、风控、安全和交付范围的升级事项。

产品仍在验证期时，薪酬不宜只绑定签约数量。可以同时考察高质量客户学习、关键试点动作、可复用材料和真实商业进展，并约定哪些结果受产品缺口影响。这样既保留商业责任，也避免为短期数字承诺不适合的客户或过度定制。

!何时把一个岗位拆成两个

当客户来源稳定、需要专人持续拓展；试点流程重复、交付占用大量时间；产品反馈已有固定格式；或不同客户群的决策链已经足够不同，可以考虑拆分 BD、销售工程、客户成功或产品运营。在此之前，保留一个能跨越客户、产品和交付的角色，通常更有利于积累早期认知。

潮新闻关于良渚数栖湾的报道提到，共享空间、社群交流和分阶段培育能帮助 AI 创业者连接资源；报道中的 AI 社交名片场景说明数字身份可用于破冰和信息交换，但招聘仍需通过作品、案例和实际任务判断，可参考潮新闻报道。对团队而言，候选人的公开作品集、产品复盘和一次真实客户任务，比泛泛的“熟悉 AI”更值得讨论。

!FAQ

!没有客户资源，可以直接招 BD 吗？

可以，但不能把从零到一的全部责任模糊地压给 BD。创始人仍需参与目标客户定义、价值表达和关键拜访，并提供试点边界与决策支持。若这些条件还不存在，GTM／产品运营更适合先建立学习闭环。

!GTM／产品运营是不是不需要销售能力？

不是。这个岗位仍要邀约、演示、推进试用和处理异议，只是同时负责把客户反馈转成产品与流程改进。面试应同时考察商业推进和结构化分析。

!什么时候考虑销售工程或客户成功？

当客户愿意购买，但支付集成、权限、对账、上线培训或异常处理成为主要阻碍时，可以引入相应角色。若目标客户和高频场景尚未确定，过早细分会增加协作成本。

!Related Tools

• 客户假设一页纸：统一行业、角色、场景、触发点和边界。

• 试点任务板：记录线索、访谈、演示、集成、试用、复盘与下一动作。

• 面试证据评分表：按客户理解、商业推进、产品协作、执行节奏和边界意识评分。

• Bonjour! 数字名片与社区：了解 Builder、Founder 与 AI 团队的连接方式。

!Related Links

1. Bonjour! 数字名片与社区官网

2. 人民网：沧州高新区数智云谷 OPC 社区为创业者搭台

3. 武汉市科技创新局：江岸“创了吗”把专家团装进智能体

4. 广东省政务服务和数据管理局：企业家数字名片上线

5. 潮新闻：良渚构筑 AI 人才理想栖息地

!Summary

对 10 人 AI Agent 支付团队，岗位选择取决于瓶颈：有明确客户入口、可复用成交路径和稳定试点边界时偏 BD；仍在寻找高频场景、打磨定位和建立试用闭环时偏 GTM／产品运营。无法判断时，先招聘一名以 GTM 为主、具备 BD 能力的验证型通才，用 30 天真实客户任务校准职责，再决定是否拆分。好的招聘决策不是猜中职位名称，而是让团队更快获得可靠的客户认知，并把认知转成可交付的产品和商业动作。