简要结论
一套协作机器人方案要过会，通常要同时回答五件事：放不放得下、先报哪一款、三款差在哪、交付是否透明、售后谁负责
Roooll 把这五件事拆成五个能力模块，各自解决不同风险，不互相替代
正确顺序是：先 AR 建立空间共识，再 Advisor 定主推，再 Comparison 做参数证明，最后用 RooollTrack 与 RooollCare 承接交付与长期服务
很多项目不是输在机器人本体，而是输在决策过程：前期靠想象，中期靠口头，后期靠追问。这篇总览的目标很简单：把每个阶段该用什么能力、产出什么结果，一次讲清楚。
Roooll 能力总览
| Roooll 能力 | 关键痛点 | 建议产出 |
|---|---|---|
| AR Preview | 看得懂参数，但看不见现场感觉 | 现场可行性初判（占地/干涉/操作位） |
| Product Advisor | 迟迟定不出“先报哪款” | 主推机型 + 升级备选 + PDF 摘要 |
| Side-by-Side Comparison | 决赛圈参数分散，难统一口径 | 三款决赛圈对比结论 |
| RooollTrack | 下单后进度碎片化 | 交付过程可追溯时间线 |
| RooollCare | 售后升级路径不清 | 运维阶段责任清单 |
能力一：AR Preview（先解决“放不放得下”）
先把空间问题看见，再谈参数取舍。
痛点
采购会常见分歧是：规格都对，但没人能确认现场观感与操作路径。只看图纸，容易在 demo 或进场时才暴露干涉与压迫感。
怎么用
在真实工位用手机打开 AR。
放置 1:1 模型，按操作员视角走一圈。
记录三个结论：占地是否可接受、关键动作区是否有干涉、人员站位是否舒适。
与市面常见做法差异
常见流程是先下 CAD、再约样机、再现场确认；Roooll 把第一轮空间判断前移到浏览器端，先筛掉明显不合适方案。
能力二：Product Advisor（把“讨论很多”变成“先报一款”）
先拿到主推，再讨论优化。
痛点
团队常卡在“每个人都有道理，但没人愿意先拍板”。结果是询价晚、周期拖、内部复盘时很难解释为什么这样选。
怎么用
跑完整五问，得到主推机型。
同时记录升级路径（负载/臂展吃紧时的上探档）。
导出结果页 PDF，作为立项或询价附件。
与市面常见做法差异
常见方式是先拉长对比列表再开会；Roooll 先用结构化问答给出“先报谁”，让团队从空泛讨论转为围绕一款主推做验证。
能力三：Side-by-Side Comparison（把“感觉差不多”变成“差在哪几行”）
最终决策靠并排事实，不靠口头偏好。
痛点
决赛圈常见问题不是“没数据”，而是数据在不同 PDF 与表格里，导致沟通靠截图、版本混乱、结论反复。
怎么用
把主推与两款备选放进同一表。
重点核对负载、臂展、重复定位、控制箱与关节参数。
生成可分享链接或一页 PDF，发给采购、工艺与管理层。
与市面常见做法差异
常见做法靠人工整理对比表；Roooll 让“同字段、同口径、同页面”直接成立，减少二次转抄与解释成本。
能力四：RooollTrack（把“追状态”变成“看状态”）
交付透明，不应依赖某个人记得回消息。
痛点
下单后最大摩擦通常来自信息分散：里程碑在聊天里、单据在邮件里、图片在私聊里，项目越忙越容易失真。
怎么用
以项目链接为唯一进度入口。
对齐生产、QC、发运、交付四阶段节点。
把关键文件（票据、清单、报告）绑定同一时间线。
与市面常见做法差异
常见方式是人工报进度 + 多渠道转发附件；RooollTrack 把节点与文件绑定，减少“谁说的是最新版”争议。
能力五：RooollCare（把“售后救火”变成“服务机制”）
交付结束不是服务结束。
痛点
很多项目上线后才发现：问题升级找谁、响应时效怎么算、哪些属于标准支持，内部并不统一。
怎么用
在上线前确认服务入口与联系人。
明确常见问题分类与升级路径。
把支持规则纳入项目交付包，而不是出问题后再补。
与市面常见做法差异
常见做法是“先运行再说”；Roooll 的做法是把服务边界提前对齐，降低停线风险和沟通摩擦。
服务入口参考：全球服务支持
推荐执行顺序（给采购/集成商可直接复用）
AR：先做空间可行性初判。
Advisor：拿主推机型与升级路径。
Comparison：完成决赛圈参数对比并输出共享链接/PDF。
Inquiry：基于主推与对比结论发询价。
RooollTrack + RooollCare：交付阶段看进度，运营阶段按服务机制执行。
