SaaS 早期合伙分工：从 0 开始先写角色契约，再谈股权和头衔

开场：很多合伙问题不是价值观问题，而是角色没有写清

从 0 开始做 SaaS，很多团队是朋友、前同事、技术伙伴或业务伙伴一起启动。大家开始时很有热情，也相信彼此。但几个月后，矛盾开始出现：谁负责客户访谈，谁负责写代码，谁做销售，谁拍板产品方向，谁处理客户支持，谁能承诺功能，谁为现金流负责。

这些问题如果一开始只靠默契，很容易变成情绪。技术合伙人觉得业务合伙人需求变来变去，业务合伙人觉得技术合伙人不理解客户，产品负责人觉得销售乱承诺，销售觉得产品太慢。最后大家讨论的不是事情，而是态度。

角色契约的目的，是在公司还小的时候，把关键责任、决策边界、沟通节奏和退出机制写清楚。它不替代法律协议，但能帮助团队在日常工作中减少模糊地带。

先区分角色，不要只分头衔

早期团队头衔没有太大意义。CEO、CTO、COO、产品负责人，这些词如果不连接具体责任，就只是名片。更应该先列出公司当前必须完成的工作：

• 市场和客户研究。
• 销售触达和访谈。
• 产品范围和原型。
• 技术开发和部署。
• 客户试点和交付。
• 内容和获客。
• 财务、合同和行政。
• 客户支持和问题处理。

然后明确每项工作谁是第一负责人，谁参与，谁有最终决策权。一个人可以负责多项，但每项必须有一个明确 owner。没有 owner 的事情，最后一定会掉。

例如，客户访谈可以由业务合伙人负责，技术合伙人每周参与两次，产品范围由双方复盘后决定，但最终由产品 owner 拍板。这样比“大家都关注客户”更可执行。

写清输出物

责任不能只写“负责销售”“负责产品”“负责技术”。要写输出物。输出物能让责任可检查。

比如：

输出物不是为了管理形式，而是让团队知道每周有没有推进证据。如果一个角色连续几周没有可见输出，就要讨论是工作太模糊、能力不匹配，还是优先级有问题。

决策权要提前说清

早期团队最容易在决策上卡住。每个人都重要，每个人都有意见，最后谁都不敢拍板。可以按决策类型明确权责。

常见决策包括：

• 目标客户选择。
• 产品范围取舍。
• 技术架构取舍。
• 客户承诺和报价。
• 是否接受定制。
• 是否招聘或外包。
• 是否继续某个方向。

不是所有决策都要一致通过。小团队需要速度。可以规定：重大方向必须合伙人共同讨论，但日常产品范围由产品 owner 决定，技术实现由技术负责人决定，报价边界由销售负责人和财务负责人共同确认。

同时要设置“升级机制”。如果某个决策影响现金、股权、长期战略或客户重大承诺，就不能由单人随意决定。边界越清楚，日常协作越顺。

客户承诺必须有统一口径

SaaS 早期最危险的合伙分歧之一，是对客户承诺不一致。销售为了推进，说“这个功能可以做”；技术认为至少要一个月；产品认为不该做；客户最后以为这是已经答应的范围。

要建立客户承诺规则：

• 未进入路线图的功能，不承诺具体时间。
• 涉及定制开发，必须评估成本和价格。
• 涉及数据、安全、合规，必须谨慎表述。
• 试点范围必须写成文档。
• 客户会议后的承诺要同步到团队。

销售可以表达方向，但不能随意承诺交付；技术可以评估成本，但不能完全脱离客户价值拒绝；产品要把承诺转成范围边界。角色契约要保护团队，不让任何一个角色单独把公司带进不可交付的承诺。

讨论投入时间和现金压力

合伙人之间还要说清投入时间。有人全职，有人兼职，有人晚上周末参与，这会直接影响公平感和推进速度。如果不说清，后面很容易出现“我投入更多，你却拿一样股份”的矛盾。

至少要写：

• 每个人每周投入多少小时。
• 是否全职。
• 是否有其他工作或项目。
• 什么时候评估是否全职。
• 现金不足时谁承担什么压力。
• 是否有工资、报销或延期补偿。

这些话早说会有点尴尬，晚说会更痛。创业初期关系好，不代表未来不会遇到现金和时间压力。写清楚不是不信任，而是保护长期合作。

退出机制不能等到关系破裂才谈

合伙人可能因为个人原因、能力不匹配、方向分歧、现金压力退出。退出机制如果没有提前约定，后面会非常复杂。

至少要讨论：

• 股权是否有归属期。
• 未完成归属的部分如何处理。
• 退出后是否继续持有股份。
• 退出后是否能继续参与决策。
• 竞业或保密边界是什么。
• 已经负责的客户和代码如何交接。

具体法律安排要咨询专业人士，但业务层面的原则要早定。尤其是 SaaS 这种长期服务，合伙人退出可能影响客户、代码、域名、账号、合同和数据。不要把这些都留到冲突发生时处理。

设定固定沟通节奏

早期团队忙起来后，很容易只在出问题时沟通。建议建立固定节奏：

• 每日 15 分钟同步：昨天完成、今天计划、卡点。
• 每周 90 分钟复盘：客户证据、产品进度、销售漏斗、现金状态。
• 每月 2 小时方向会：是否继续当前市场、是否调整 offer、是否需要资源变化。

会议不需要多，但要有议程和输出。尤其是每周复盘，必须看证据，而不是只聊感受。客户访谈、试点结果、现金跑道、产品交付，都应该进入同一张表。

沟通节奏能避免小问题积累。合伙人不是因为没有分歧才合作，而是因为有机制处理分歧。

角色契约的简版模板

可以用下面结构写一页文档：

当前阶段目标：
未来 8 周要验证什么。

角色分工：
谁负责客户、产品、技术、销售、交付、财务。

每周输出：
每个角色必须交付什么可见成果。

决策边界：
哪些事谁拍板，哪些事必须共同决定。

客户承诺规则：
哪些话能说，哪些必须评估后说。

投入约定：
每人时间、现金、工资、报销安排。

沟通节奏：
每日、每周、每月如何复盘。

退出和交接原则：
如果有人退出，如何处理股份、资料和客户。

这份文档不需要很长，但必须具体。写完后每月复看一次。随着公司阶段变化，角色也会变化。

用场景测试角色契约

角色契约写完后，不要只放进文档。可以用几个真实场景测试它是否有效。

场景一：客户在 Demo 后要求两周内增加一个导出功能，否则不进入试点。谁判断这个功能是否值得做？谁评估开发成本？谁和客户沟通边界？如果文档里没有答案，说明客户承诺规则还不够清楚。

场景二：技术负责人认为当前代码需要重构两周，销售负责人认为必须先交付试点。谁拍板？依据是什么？是否看现金跑道、客户承诺、技术风险？如果只有争吵，没有决策机制，说明技术和商业取舍边界不清。

场景三：业务合伙人连续两周没有完成访谈目标，因为还有全职工作。团队如何处理？是调整目标、重新分工，还是讨论全职时间点？如果不提前说，后面就会变成个人指责。

场景四：某个合伙人想接一个高价定制项目，但项目会占用一个月开发资源。是否接受？谁评估现金价值、产品价值和机会成本？如果只看收入，很容易把 SaaS 做成项目公司。

这些场景能暴露角色契约的漏洞。文档不是为了好看，而是为了在压力出现时仍然能行动。

合伙分工要随阶段变化

从 0 到 1 的不同阶段，角色重点会变化。最早期可能客户发现最重要，技术只需要支撑样例和 MVP；进入试点后，交付和客户成功变重要；有付费客户后，稳定性、支持、合同和续费变重要。

所以角色契约不能一写三年。可以每月复盘一次：

• 当前阶段最关键的三件事是什么。
• 现有分工是否支持这三件事。
• 哪个角色负担过重。
• 哪个角色输出不清。
• 是否有工作没人负责。
• 是否有角色需要交接或合并。

比如最初业务合伙人负责销售、访谈、内容和试点，很快会过载。此时要明确哪些工作必须创始人亲自做，哪些可以模板化，哪些可以暂时不做。技术合伙人也可能从纯开发变成要参与客户会议，因为很多技术边界需要现场解释。

角色调整不是否定过去，而是承认公司阶段变了。早期团队如果能主动调整分工，就比被问题拖着走更稳。

股权讨论也要连接贡献节奏

股权是敏感话题，但不能回避。角色契约虽然不是股权协议，但它能为股权讨论提供依据：谁全职，谁兼职，谁承担现金风险，谁带来客户资源，谁负责核心技术，谁持续交付。

常见风险是只按最初想法分股，却不考虑后续投入变化。一个合伙人后来全职投入，另一个长期兼职；一个人持续拿客户和收入，另一个人输出不稳定。如果没有归属期和调整机制，关系会越来越紧张。

因此，正式股权安排要找专业人士处理，但创始团队内部至少要先达成原则：股权对应长期贡献，不只是最初想法；未持续投入的部分要有处理方式；退出后不能继续影响日常决策；核心资产、代码、客户、域名和账号属于公司，而不是个人。

把这些话提前讲清楚，比关系破裂后再谈要容易得多。

早期角色契约的常见错误

第一个错误，是所有人都说“我都可以帮忙”。这句话听起来积极，但会让责任消失。创业团队当然要互相补位，但补位不能替代 owner。每件关键工作都要有人最终负责。

第二个错误，是只分工不设验收。比如一个人负责销售，但没有每周线索、访谈、试点候选这些输出；一个人负责产品，但没有范围文档、取舍记录、客户反馈整理。没有输出，分工就无法检查。

第三个错误，是把技术和业务割裂。技术合伙人只写代码，不听客户；业务合伙人只做销售，不理解产品成本。SaaS 早期需要高频交叉，尤其是客户承诺、数据边界、交付成本这些问题，必须一起看。

第四个错误，是不谈失败。方向不成立怎么办，现金不够怎么办，有人想退出怎么办，客户投诉怎么办。只谈成功愿景，不谈失败处理，说明合作还不够成熟。

让角色契约落到每周

文档写完后，最好把它落到每周看板。每个角色都有本周目标、实际输出、卡点和下周动作。比如客户负责人本周目标是 8 次访谈，实际完成 6 次，卡点是目标名单质量不高，下周动作是改线索来源；技术负责人本周目标是完成导入预览，实际完成 80%，卡点是字段错误样本不足，下周需要客户负责人提供 3 份样本。

这样角色契约不只是关系约定，而是协作系统。团队每周都能看到彼此的真实工作，而不是只在出问题时互相猜测。早期合伙最怕“我以为你会做”。看板和契约一起使用，可以让“以为”变成“确认”。

角色契约要保护客户体验

合伙分工最终不是内部管理游戏，而是为了让客户体验稳定。客户不应该在不同合伙人那里听到不同说法，也不应该因为内部没人负责而等不到回复。可以规定客户问题的响应路径：谁接收、谁判断优先级、谁回复客户、谁决定是否进入产品计划。

如果客户提出 bug，技术负责人要判断严重程度；如果客户提出新需求，产品负责人要判断是否影响当前闭环；如果客户要求报价或扩范围，销售负责人要确认商业边界。每个人都可以参与讨论，但客户侧必须有统一出口。

早期客户愿意相信小团队，很大程度上取决于你们是否一致、可靠、说到做到。角色契约越清楚，客户越少感受到内部混乱。

结尾：先把合作变成可执行系统

从 0 开始做 SaaS，合伙关系不是靠热情维持的，而是靠清楚的责任、边界和节奏维持。角色契约能把很多潜在矛盾提前摊开：谁做什么，谁决定什么，谁承诺什么，谁交付什么，出了问题怎么处理。

好的合伙人不怕把话说清楚。相反，越早说清楚，越能把精力放回客户、产品和收入。SaaS 创业已经足够难，不要让团队内部的模糊分工成为额外风险。