09-01 B端在线协同产品的收费策略与问题
收费策略
目前在线工具类的产品很一致：订阅制，按月或者按年；
这个逻辑很清晰，毕竟服务器要钱的，更新产品养团队也是要钱的。
C 端这个收费策略没什么大问题，但是在 B 端一旦涉及到协作，就有些问题了。
在线工具的优势
协作工具的核心是尽可能的多的把相关内部工作流和人员囊括进来；从我的理解来说，这也是 B 端工具价值的衡量标准之一，判断并尽可能扩张产品的边界。
举个例子，A 同学需要做一张图。
传统流程
传统的流程是 Photoshop 做完图，导出图片，发给 B 同学，B 同学觉得这这这要改一下，然后 A 同学在 Photoshop 里面修改，再发给 B。多次往复。
在线流程
新的在线协作流程是，A 在协作工具上做了图，通过链接或平台内分享给B，B 标记要改的地方或者直接上手改，A 和 B 一起调整完。
整个流程都在工具内部完成，在这个流程中省掉了大量的导出文件、审阅反馈意见、本地版本管理、双方对齐版本的过程。
这个体验相比传统流程来说是非常好的，而且工具平台上能囊括的流程和拉进来的人越多，整个团队的体验越好。
现实中的问题
比如上面提到的简要做图流程，此间有两个角色参与其中：设计师 A 和 审阅人员 B。
A 需要全程的参与整个的设计过程，B 可能只在 A 完成之后进行审阅的工作。在时间上来说 A 可能会有5天的时间来参与，B可能花半天的时间就审阅完了。
换个角度来说，对企业来说，A 账号是充分使用了的，B 账号是多数时间都在闲置的。
而大多数平台会针对账号/席位进行收费，团队需要花钱养这两个账号。这样的话，B账号相对来说就没这么划算了，团队就会纠结要不要花这笔钱。这就和我之前说的尽可能的拉进来人和囊括流程的初衷相抵了。
举个比较现实的例子，创业团队的基础产研团队配比可能是这样的：1设计，1产品，2前端，2后端。设计工具的话至少想要把 设计、产品、前端这三个职位4个人囊括进来，但是重度使用的其实只有设计一个人。团队为了一个人买4个席位？平时会有3/4的账号是闲置状态的。
“不可能的，我们还是用 Sketch 或者 Photoshop 吧？”
Figma 的按角色收费
所以按角色或者功能来给不同类型的席位进行定价是一个好的选择。
Figma 用能否编辑来划分出了两个角色，普通的用户是免费的，Editor 是收费的。
这是一个好的策略，非常好的策略。Figma 这么做就尽可能的把团队里面的所有人员都囊括进来了。
设计师、产品、前端、后端都可以参与到 Figma 的平台，养成习惯。随着团队的日常工作拓展，还可能把 CEO、隔壁团队、合作伙伴 等等也拉到 Figma 的平台上（毕竟只查看是免费的）。
有人、有流程就有业务范围横向扩展的可能性。
plus: 固定席位的问题
坦白说，按功能划分角色虽然很讨巧也很不错，但是其实并没有解决之前提到的账号闲置的问题。
举个例子，Figma 现在也有原型功能，产品原型的制作流程也可以放在 Figma 上，但是产品原型阶段很短，大部分时间产品人员的账号还就是闲置的。有些对价格敏感的团队可能就不会把原型阶段的流程放在 Figma 上。
这就会与平台方的初衷相抵了，也不是功能限制能解决的，可能需要在定价策略上下点功夫。
ps1: 举例2 其他团队或者合作伙伴加入到业务流程中的处理。
ps2: Figma 做“产品原型工具”的基础在于它吸引了很多 PM 到平台上。
动态席位
这俩天重新开始看文档协同方面的内容，在看 CRDT 的时候，反复的出现了 serverless，顺便仔细的看了下；btw AWS 的 lambda 已经上线好些年了。
意识到对于工具类的产品是一项挺有意义的技术 —— 按需收费，按使用收费；和电&水一样。如果能按天/小时进行收费，就算单价贵一点，作为一个临时的席位，大多数团队是可以接受的。
动态席位在产品上的意义并不只是给中小团队节省费用，而是促使尽可能多的人员和流程移到平台上。
动态席位的产品形态其实可以有多种：不指定到账号的席位、随开随关的席位、按使用量自动计费的席位等等。后续有时间再探讨。
总结
- 协作工具的核心是尽可能的多的把相关内部工作流和人员囊括进来；
- 编辑席位的价格，对于某些较少进行编辑的角色来说，是不划算而有门槛的；
- 需要更灵活动态的定价策略；
hmm…