买设计工具和买一套普通 SaaS 不一样：价格同时取决于席位怎么算、版本包含什么、数据放在哪里、以及服务包含哪些内容。下面把需要核定的项目按顺序列清，并给出可以直接发给供应商的字段清单。
先确定采购范围：买的是工具，还是协作方式
在询价之前，先把下面的问题在内部对齐：这次采购要解决的是"设计工具换成国产的"，还是"把产品、设计、研发的协作放到同一条链路上"。两种目标的评估重点不同。
如果只是替换绘图工具，重点在文件兼容与学习成本；如果目标是协作与交付，就需要把成员管理、权限分层、资源库、评审与交付一起纳入评估范围，否则会出现"工具换了，协作方式没变"的情况。这一步决定后面所有项目的权重，建议先写成一页内部说明再对外询价。
评估小组的构成同样值得提前确定。设计负责人关注工作流与迁移成本，IT 或安全团队关注数据存放与账号体系，采购与法务关注合同条款与合规要求。三方如果不在同一个评估表上，很容易出现"产品选好了，安全评审卡住"的情况。建议在立项时就明确每个维度的确认人，并在询价阶段同步参与。
席位口径怎么核定
席位是最容易产生理解偏差的一项。同一个 50 人团队，按不同口径算出来的账单并不相同，因此询价时必须要求供应商写明计算方式，而不是只给一个总价。
以 Pixso 的席位体系为例，官方价格页把可编辑席位分为全功能、产品、研发与白板四类，并单独列出查看席位——查看席位免费且不限数量。这意味着只做查看与评审的成员不会推高采购成本，核算时应当把"能编辑的成员"和"只看不编辑的成员"分开统计，再对照 Pixso 价格页的当前口径确认。
实际操作中有三个容易被忽略的细节：只读成员是否需要占席位；成员离职后席位何时释放、能否在合同周期内替换；跨周期的成员增减如何结算。建议把团队的真实人数分别代入三种口径，得到三个可比数字，作为后续谈判的同一基准。版本与功能差异可以对着版本与价格说明先做一次内部对照。
还有一类成员容易被漏算：外包与长期合作方。他们往往只需要查看或评论，但有些计费口径会把他们计入席位。建议在清单里单独列出"外部协作者"这一项，并确认权限范围与计费方式。如果供应商无法按口径给出算例，说明口径本身还不够明确，应继续追问而不是先签约。
版本与功能边界
需要逐项确认的不是"有哪些功能"，而是"我们需要的功能在哪个版本"。建议按团队的真实工作流列一张功能清单，标注每项属于哪个版本，并写明哪些能力依赖更高版本或额外服务。
常见需要单独确认的项包括：成员与权限的分层管理、团队资源库与共享组件、版本历史与评论记录、外部协作者权限、以及是否支持内网或私有化部署。任何一项在报价单里没有明确对应的，先记为"待确认"，不要默认为包含。
版本阶梯同样要写进核对表。按官网价格页当前口径：免费版适合个人验证，限制是 3 个设计文件、3 个白板文件与 3 个原型文件；团队版解除项目与文件数量限制，并开放团队资源库与团队字体库；企业版在此基础上增加高级权限设置、成员席位管理、协作日志管理、企业级资源库、企业级字体库、企业安全管理与企业专属域名，并支持 SSO 单点登录。
还要确认版本的升级路径：如果先采购基础版本、后续升级到更高版本，已有的文件、权限设置与资源库是否保留，是否需要重新配置，升级差价如何计算。把这些问题在签订前问清楚，可以避免第二年因为升级而重新做一轮配置。
功能清单可以按"设计、协作、管理、交付"四组来写：设计组列出绘制、组件、样式与原型能力；协作组列出实时编辑、评论与版本记录；管理组列出成员、权限与资源库；交付组列出标注、切图与代码交付。每组后面标注当前使用频率与是否必须，这样在和供应商对照版本时，可以直接排除用不上的能力。
部署形态与数据要求
部署形态决定数据存放位置，也决定企业需要自备哪些资源。公有云通常不需要自备任何设施；专属云需要准备域名与证书；私有化部署则需要企业提供服务器、网络、证书与账号体系，并安排内部运维人力。
建议在下单前明确四件事：设计文件存放在哪里、成员与权限能否分层管理、离职成员的资产如何交接、以及能否完整导出全部设计资产。涉及内网环境时，还要进一步确认部署形态、网络条件与运维边界，可以参考企业私有化部署方案中给出的部署形态与服务流程。
私有化场景下还需要把责任边界写清楚：服务器由谁提供、日常备份由谁执行、系统故障时的响应与恢复由谁负责、版本升级由谁安排。这些内容如果只停留在口头承诺，出现问题时就很难界定。建议把它们写进服务条款，并与验收标准对应。
服务范围与实施支持
服务范围常被当成附加项，实际上它直接影响落地速度。需要确认的内容包括：实施是否包含环境搭建与数据迁移、培训以什么形式开展、覆盖多少人、问题响应的时效与渠道、以及是否需要企业配备对接人。
如果团队规模较大，建议把"培训完成"和"首批项目上线"写成可验收的节点，而不是笼统写成"提供培训服务"。这样在项目推进中才有明确的责任边界。企业版的具体能力与支持方式，可以参考企业版能力说明。
私有化部署在官网价格页的口径是"按需定制"，公开列出的范围包括本地私有化部署、功能定制化开发、核心数据加密、专属定制方案与专属VIP技术顾问。因此它无法用统一单价比较，需要先由供应商给出书面方案与服务范围，再进入价格谈判。
另外建议约定双方对接人：企业侧由谁负责推动、供应商侧由谁负责实施，以及例会的频次。实践中最常见的延期原因不是技术问题，而是企业侧数据与账号准备不及时、或双方对接人中途更换。
续费、扩容与退出条款
采购谈的是一年，用的是三年。建议在合同中明确：续费价格的计算方式与调整规则、席位扩容的计价方式、服务是否随席位增长同步增加、以及合同终止后设计资产的导出方式与数据保留期限。
其中"退出条款"最容易被忽略。设计资产是团队多年的沉淀，如果无法完整导出，后续更换工具的成本会显著上升。建议把数据导出能力作为一项独立的验收内容。
席位缩容也值得提前确认：如果第二年团队规模下降，是否允许减少席位、按什么规则结算、是否影响已有的历史文件访问权限。与之对应的是扩容规则——新增席位是立即生效还是按周期结算。把扩容与缩容写在同一条款里，可以减少后续沟通成本。
询价前要准备的字段清单
把下面的清单一次性发给候选供应商，回收上来的信息才具备可比性。也可以把它作为内部评审表，逐项标注确认人与结论。
清单里任何一项供应商无法给出明确说明的，建议先记为"待确认"，并在下一轮沟通中追问，而不是先采购后补问题。需要进一步验证产品是否符合团队工作流时，可以通过企业试用申请安排一次真实项目试用。
建议把清单做成评分表：每项按"已明确说明、部分说明、未说明"三档记录，再结合内部权重计算总分。这样报价比较就不再依赖主观印象，也便于在评审会上向管理层解释结论来源。
采购推进的节奏与产出物
企业采购通常会经历五个阶段：内部需求对齐、询价与资料索取、试用或试点验证、安全与法务评审、商务谈判与签约。整体周期常见在一个半月到三个月之间，规模越大、涉及内网环境的项目周期越长。
建议给每个阶段约定产出物：需求对齐阶段输出评估权重表；询价阶段输出报价对照表；试用阶段输出试点结论；评审阶段输出安全与法务意见；签约阶段输出合同与实施计划。产出物明确之后，跨部门协作会顺畅很多，也便于向管理层汇报进度。
最常见的延期原因有两个：一是企业侧的账号、数据与测试环境准备不及时；二是安全评审需要排队。这两个环节都与产品本身无关，却常常占掉一半时间，因此在制定计划时应把它们单独排期，并提前指定对接人跟进。
常见问题
询价前最重要的准备是什么？把席位口径和版本需求先写成内部文件，否则不同供应商的报价无法直接比较。
私有化一定更贵吗？不一定，但它的成本结构与公有云不同：一次性实施费用与企业自备的服务器、运维人力需要一并计入三年总成本。
试用能替代采购评估吗？不能完全替代。试用可以验证产品能力，权限分层、数据留存与服务响应通常要进入采购流程才能确认。
需要几轮询价？通常两轮足够：第一轮用同一份清单收齐信息，第二轮只针对未说明清楚的项追问并确认差异。
服务费用一般占多少？本文不给具体比例。服务范围差异很大，建议让供应商把一次性费用与年度费用分开列出，再按三年周期汇总比较。
评估需要多少人参与？建议至少包含设计负责人、IT 或安全、采购三方；只由使用方评估，容易在评审阶段被权限与数据问题挡回来。三方在同一张评估表上打分，结论更容易被管理层接受。
