接上你的工具
把 HubSpot 接给 AI 智能体
CRM 会过时，不是因为它设计得差：而是因为填写它是没人愿意做的活儿。 一个接到 HubSpot 的智能体读取并更新记录、活动、文件和市场内容——通过 HubSpot 的官方接口，而且严格限于接入它的那位用户的权限之内。让这件事变得可治理的，正是最后这一点。
1. 智能体在 HubSpot 里做的事
连接器走的是 HubSpot 的官方服务器，这就保证了范围遵循 HubSpot 的规则，而不是我们的规则。
- 记录。 读取并更新联系人、公司和交易——变过的地址、离职的对接人、案子实际推进到的阶段。
- 活动。 记下发生了什么：那通电话、那次催办、收到的答复。这是永远缺席的一部分，因为它是事后才补的。
- 文件与市场内容。 找回一份资料，查看或备好挂在 HubSpot 上的内容。
2. 智能体继承您的权限，绝不更多
这是核心的机制，值得在接入之前弄明白。
接入是以其权限必须被遵守的那个 HubSpot 用户来完成的。因此智能体没有自己的权限：它以这个人的权限行事。这个账号看不到某条管道，智能体也看不到。这个账号不能删除，智能体也不能。
实际的后果是令人愉快的：您没有新的权限体系要学。 您通过选择用哪个 HubSpot 用户接入，来决定一个智能体的范围——常见做法是建一个权限刻意收窄的专用用户。团队里的每个人也可以接自己的账号，只授予自己的权限。
接入此外还要求点明所涉的门户和对象类型：智能体从不笼统地「接到 HubSpot」。
3. 什么仍留在确认之下
HubSpot 被归入分量较重的连接器，默认设置也体现了这一点：凡是写入或删除的动作，执行前都要人工同意——除非您明确放宽。
实际上，多数团队最后会在更新一条记录或补记一次活动上放宽——风险小而每天都有得益——并在有约束力的事情上保留确认：改动交易阶段、改动金额、删除。这是个稳妥的取舍，而且是一个动作一个动作地设定，不是一刀切。
和往常一样，每个智能体的花费在调用模型之前就已封顶：额度用尽，调用就不会发生。
4. 时间久了会有什么变化
在 CRM 上，第一个月证明不了什么。见分晓的是第十二周。
- 第 1 周。 最近碰过的记录被补齐，缺失的活动被记下。CRM 所说的和实际发生的之间的落差，开始缩小。
- 第 3 个月。 管道映出现实。这是头一回可以靠着它来做决定，而不是「去问跟这单的人」。
- 第 2 年。 历史变成了数据：哪些交易在推进，哪些睡着了，哪些跟进有结果。这些在一个填了一半的 CRM 里，一样也读不出来。
不承诺任何数字化的收益。可以确定的是，一个被维护住的 CRM 胜过一个功能繁多的 CRM——这是另文展开的主题。
5. 常见问题
要不要建一个 HubSpot 应用？
认证用的应用只为 nullbot 建一次；之后每个人在接入时选择自己的 HubSpot 账号并授予自己的权限。因此没有需要按用户重做的配置工作。
智能体能在我不知情的时候改动一笔交易吗？
默认不能：写入和删除的动作在执行前都要人工确认。而且即便在无害的动作上放宽了这道确认，一切仍留有痕迹——在 nullbot 的记录里，也在 HubSpot 自己的历史里，后者会自行记下谁改了什么。
能把一个智能体限制在单个管道里吗？
可以，而且有两条互相叠加的路：接入要求点明门户和对象类型，而智能体所连的那个 HubSpot 用户本身也带着自己的限制。建一个权限刻意收窄的专用 HubSpot 用户，是最简单也最好读的办法。
如果我们用的是别的 CRM 呢？
Pipedrive、Close、Attio 和 Folk 同样在目录里；若您一个 CRM 也没有，nullbot 自带一个。道理不变：智能体在您这边作为基准的那个工具里工作，而不是另建一个终将同样过时的并行库。
延伸阅读
接着读：由智能体维护的 CRM、接入 Stripe，或全部可用的连接器。