移动设备机群业务定价，是把设备容量、会话时长、并发、支持与客户工作负载风险，转成可计费服务模型。正确价格应覆盖设备、基础设施、路由、人力、监控与恢复，而不只是原始手机数量。
代理商与运营团队的难点在容量规划。一个客户可能要二十台设备撑短时每日发布窗口；另一个只要五个全天账号检查的持久环境。这两类客户不该同一套价。
务实做法：按承诺容量加可变用量。对预留设备或并发收基础费，再为自动化搭建、账号工作区管理、支持与审核循环加工作负载特定费用。
核心要点
- 按预留容量、活跃时长、并发、支持与工作流复杂度定价。
- 仅按手机数量定价很弱：利用率与任务类型差很大。
- 测试云里的设备分钟、设备槽位与并发模型可作参考，但运营工作流还要加支持与账号上下文。
- 锁定客户价前，试点应衡量利用率、失败会话、操作员时间与恢复投入。
- 未定义容量上限、调度规则与超额条款前，别卖「无限执行」。
预搭建输入
常见错误是把设备当简单租赁。客户很少只买一台设备，他们买的是执行环境访问、团队支持、任务连续性与运营可见性。
| 输入 | 要问什么 | 定价影响 |
|---|---|---|
| 预留容量 | 必须有多少设备或会话可用？ | 设定每月基础承诺 |
| 并发 | 同时运行多少任务？ | 定义峰值基础设施负载 |
| 活跃窗口 | 客户何时需要执行？ | 改变调度与支持成本 |
| 工作流类型 | 发布、应用检查、回复、QA、监控、外联？ | 控制搭建与审核投入 |
| 恢复级别 | 谁处理失败运行、登录问题与交接？ | 增加运营人力与 SLA 成本 |
云测试供应商说明了为何这种容量框架重要。AWS Device Farm 以设备分钟计量，也用设备槽位做非计量并发。参见 定价 FAQ 与 设备槽位文档。
对运营团队，云手机执行环境与短时应用测试不同：可能需要持久会话、账号分离、应用状态、文件处理与审核日志。
定价工作流
定价应从工作负载形态走向容量模型。
- 定义客户工作负载。 分开应用 QA、社交发布、客户回复、监控与内容上传。
- 估算活跃设备时间。 每台设备、每天、每位客户的预期分钟或小时。
- 设定峰值并发。 同一时刻必须跑多少设备。
- 选择定价基础。 预留设备、预留并发或基于用量。
- 增加支持层。 搭建、路由、监控、人工接管与报表分开定价。
- 写下超额规则。 超出预留会话或时间窗口时怎么办。
简单公式：
月价 = 预留容量 + 可变用量 + 工作流搭建 + 支持与恢复 + 报表。
预留容量保护基础设施计划；可变用量防止重度与轻度用户吃同样资源；支持费阻止隐形人力消失在设备价里。
定价模型示例
| 模型 | 最佳适配 | 需密切关注 |
|---|---|---|
| 预留设备套餐 | 需要持久移动环境 | 闲置时间与未用月容量 |
| 并发套餐 | 短时峰值执行窗口 | 跨客户峰值冲突 |
| 基于用量的附加 | 月需求不可预测 | 超额报表与客户批准 |
| 托管工作流套餐 | 买执行、监控与恢复 | 操作员时间与支持边界 |
小客户可用固定设备数 + 一条工作流 + 月度报表；更大客户可组合预留设备、峰值并发、搭建费与恢复支持——把设备成本与服务工作拆开。
别把所有工作藏进一个「每手机」数字。客户要额外账号、更长活跃窗口或紧急恢复时，很难辩护。更好的报价分行写：容量、工作流范围、支持限制、超额规则。
合同里写清预留设备、峰值并发、包含支持小时、报表节奏与超额批准，续约与范围变更时争议更少。
如何验证定价模型
别在一天顺利后就下结论。有用模型要扛住峰值日、失败会话、应用更新、操作员缺席与范围变更。
四项检查：
- 利用率： 多数月份不闲置，峰值也不超订
- 并发： 能按承诺并行跑
- 支持： 操作员时间可见，尤其是失败与人工恢复
- 利润： 价格覆盖设备、基础设施、支持与管理开销
Sauce Labs 把并发描述为订阅可同时运行的测试数量（跨云类型与地区），把峰值容量与总月活动分开。参见 管理并发。BrowserStack 的多设备测试同理：并行工作有自己的容量成本。参见 多设备测试文档。
定价常失败在哪
销售过多「无限」容量。多客户同时抢同一设备池时会冲突。
忽视支持时间。设备可用，工作流仍要搭建、交接、更新、路由检查、结果审核与失败恢复。
混用客户环境。共享池可能适合低风险测试；需要分离会话、账号工作区或持久状态时就不合适。
对每种工作流用同一统一定价。内容发布、QA、客户回复消耗的支持与审核投入不同。
容量应按带调度、隔离与运营记录的执行系统定价，而不是简单手机租赁。
首轮报价怎么做
把第一份报价建成受控估算，再测假设。
- 建容量表：设备、并发、活跃窗口、预期月小时
- 把每条工作流标为低 / 中 / 高支持
- 加一次性搭建费（环境准备与工作流配置）
- 加经常性支持费（监控、报表、恢复）
- 客户开工前定义超额规则
- 前两周对照实际利用率复盘
客户需要持久移动环境时，云手机容量更容易作为「预留执行空间」讨论；需要许多协调工作流时，移动自动化应作为托管运营层单独定价。
谁适合
适合向客户销售托管移动执行的团队：代理商、QA 供应商、跨境商务、社交运营服务商，以及向业务单元收费的内部平台团队。
强匹配： 预留移动容量、持久 Android 会话、多个账号工作区、计划执行窗口、支持与恢复、按客户/账号/任务报表。
较弱： 偶尔手动访问一台设备——简单按设备租赁或临时用量可能更容易。
Android Enterprise 通过 Android Management API 与 Device Policy 支持设备与应用管理策略。那不是定价模型，但强化了业务设备机群需要管理控制。参见 Android Enterprise overview。
试点与恢复规则
签长期合同前先用试点价：有限设备、有限并发、一到两种工作流、清晰复盘日期。
容量指标： 预留设备、峰值并发、平均活跃小时、闲置时间。
运营指标： 搭建小时、失败会话、人工恢复事件、报表时间。
恢复规则应写进报价。客户超出容量时要有已知响应：排队、收超额、加预留，或改时间窗口。多客户机群里，账号/应用/客户数据需要分离环境时，设备隔离应作为运营要求进价。
常见问题
1. 最佳定价单位是什么？
预留容量加可变用量。仅设备数量太粗。
2. 按设备还是按客户？
支持、报表与工作流搭建因客户而异时，按客户；更简单的访问模型可按设备。
3. 并发如何影响价格？
并发影响峰值容量。十台依次用，与十台同时跑，不是一回事。
4. 搭建是否应包含在月费里？
通常分开。搭建常含环境准备、路由、工作流配置与入驻。
5. 如何处理超额？
上线前定义：额外设备时长、额外会话、增加并发或排队规则。
6. 手机农场与托管移动机群一样吗？
不完全。手机农场聚焦设备；托管机群还包括调度、隔离、支持、监控与报表。
7. 首个试点应衡量什么？
活跃小时、并发、失败、支持时间、闲置时间与恢复事件。