WorkBuddy代理商：新部门增购先谈三件事

企业已有团队在用 WorkBuddy，新部门又要采购，找 WorkBuddy代理商 时最该先谈的不是单价，而是三件事：这次增购挂在哪个企业下、新部门到底多少人会真的用、落地支持算不算在服务范围内。这三件事定下来，席位数量和费用才有可比的口径；顺序颠倒，后面往往要推倒重来。

一、先定这次增购挂在哪个企业下

已有团队在用的意思是，企业空间、管理员账号和一份有效订阅都已经存在。新部门加入时有两条路径：把成员加进现有企业，或者因为法人主体、预算归属不同而在另一个企业下另开环境。两条路径的管理成本差别很大，必须在报价之前定下来。

容易被忽略的是后台的企业选择。一个管理员账号如果关联了多个企业，进入管理后台时要先选定本次操作的企业，之后添加的成员、分配的许可和设置的可见范围都作用于当前选中的那个企业。选错了，后面所有配置都要重做一遍，还会留下无人认领的账号。

采购前先问清三个归属问题

• 新部门成员的账号加入哪个企业，由谁担任管理员，转岗或离职后谁接手；
• 增购的席位是加在现有订阅数量上，还是新起一份订阅，两者的计费周期和续费时点是否一致；
• 新部门在组织结构里怎么建，资源由谁负责、开放给哪些人。

这三个问题写进采购说明，比在合同里补一句“包含新部门”更管用。

二、把增购需求写成席位清单，而不是人头表

新部门报需求时通常给一个人数，比如“我们部门二十人，先买二十个”。这是组织口径，不是使用口径。直接按人头下单，最常见的后果是买完之后一半席位闲置，另一半人在等分配。

一条任务对应一名责任人

让新部门交一份清单，只保留三列：要完成的具体工作、这项工作固定的责任人、现在用什么办法在做。落到具体责任人的工作才进入候选席位；写“提升效率”“跟上趋势”这类描述的先退回去补充。周期性、需要重复执行的任务优先进入第一批，一次性、偶发的任务放到后面观察。

这份清单还有一个作用：它是后续复盘的基准。任务变了，席位需求才会变；任务没变而席位不够，多半是分配或上手环节出了问题。

已购、已分配、实际使用要分开记

增购场景下最容易混的就是这三个数字。建议在新部门的采购台账里固定三列，只用这三个口径讨论席位：

• 已购席位：订单或合同层面确认的数量，含原有席位和本次增购；
• 已分配席位：已经指派到具体人员、可以开始使用的数量；
• 实际使用：在约定观察周期内真正产生工作记录的人数。

已购明显大于已分配，说明内部分配流程卡住了，先查管理员是否完成指派、名单是否迟迟定不下来；已分配明显大于实际使用，说明选人或上手门槛有问题，这时候继续加量只会把差额放大。把差额当成信号，扩容讨论就从“感觉不够用”变成看数说话。

还有一个动作要提前做：清点原团队里离职、转岗或长期不用的账号，按内部流程回收许可再分配给新部门。很多所谓“席位不够”，其实是旧账号还占着位置。

用阶段代替一次性锁死

建议把增购划成试点、扩展、常规三个阶段，每阶段写明参与岗位、席位上限、观察周期和进入下一阶段的条件。参照产品流程给出的做法，第一批放三到五人，先验证登录、许可分配和一条真实任务能不能跑通，再按部门逐批扩。审批的对象是阶段和上限，不是一次性锁死的总数，这样既能控支出，也不至于流程反复拖慢落地。

三、新部门的落地支持要单独谈

增购不是把席位数字改大就结束。成员添加和产品许可是两个动作：把人员加进组织架构只是建立了账号，还要单独分配 WorkBuddy 许可，成员才算真正可用。成员登录时如果误用了未加入企业的个人账号，也会看不到团队许可和共享资源。这些环节在新部门身上会集中出现，因为这里的用户是第一次接触。

后台里先做三件小事

• 组织结构先按新部门的实际汇报关系建一次，命名规则统一，避免以后靠记忆找人；
• 可见范围和用户组从最小必要开始，按岗位逐步放开，不要默认向全员开放全部企业资源；
• AI 资源和 Agent 先选一两个高频场景试点，明确资源负责人、目标用户和使用边界，再扩大范围。

至于培训、上线配合、场景梳理、后续问题响应是否包含在服务里，属于要按清单逐项确认的事项，不随订购席位自动推定。谈的时候把“谁做、做到什么程度、什么时候交付”写成条目，比笼统约定“提供支持”更省事。不同购买入口的字段和身份方式也可能不同，优惠方案通常有适用范围和有效期，需要单独核对。广州独角兽数码在企业 WorkBuddy 采购优惠方案核对、采购协助与落地应用支持的服务范围内，可以协助把阶段计划、席位口径和支持清单逐条对照；具体版本适用、价格与订单条款仍以实际下单页和合同文本为准。

四、下单与交接：四项复核和续费时点

下单前建议做一次四项复核：席位数量是否与首批名单一致；企业名称是否准确、能否被管理员辨认；订阅时长和自动续费是否符合本次采购计划；当前登录账号是否应当成为该企业的初始管理员。付款完成后不要停在订单结果页，继续进入管理后台完成许可分配，否则新部门仍然用不起来。

交接时分别记录三样东西：本次采购范围、企业内部的管理责任（管理员、部门结构、许可回收）、以及服务方承诺的支持事项。三者混在一起写，出问题时很难判断该找谁。

扩容决策要赶在续费之前

官方续费说明提到，续费时应核对购买企业对应的账号，续费时许可数量不可改变，自动续费价格以实际执行下单时为准。这直接影响增购节奏：新部门的使用观察和扩容评估要安排在续费节点之前做完，不要把续费流程当成随意加减数量的入口。

减量、退款、多人共用一个账号这几件事，属于订单与许可条款范围，不同版本和购买入口的规则可能不一致，需要按实际合同逐条确认，不能凭经验类推。

常见问题 新部门能不能直接用老部门空出来的席位？

技术上要看许可是否已回收、账号状态是否可激活。流程上建议先按内部制度确认回收依据，再指派给新成员，避免旧账号被停用后仍占用名额。同一账号多人共用是否允许，属于条款范围，采购阶段就要问清，不能默认可行。

新部门第一批买几个席位合适？

不按部门人数定，按能落到固定责任人的任务定。第一批以三到五人为宜，能在观察周期内跑通登录、许可分配和一条真实任务即可。等三口径台账出现明确差额，再按既定条件启动扩容评估。

增购之后，落地支持要不要另外约定？

如果希望服务方参与培训、上线配合或场景梳理，应当单独写进支持清单，明确范围和交付物。席位订购本身通常只解决产品可用性，不自动附带这些服务。

续费前能把新部门没用上的席位减掉吗？

续费时许可数量不可改变，这是官方说明中比较明确的一条。减量或退款是否可行、在哪个时点操作，需要按适用版本和订单条款确认。比较稳妥的做法是提前完成复盘，把结论用在下一轮采购决策上。

本文由AI辅助生成。