将 HubSpot CRM 集成到 Gmail 中，改变了一支销售团队的跟进方式
一位销售主管使用 Manus 构建了一个自定义工作流,将 HubSpot 的详细信息整合到团队已经在使用的工具中:Gmail 和 Slack。目标很简单。当潜在客户给团队发邮件时,销售代表无需离开收件箱,就能弄清楚对方是谁、该公司是否已经在 HubSpot 中,以及这次对话是否与某个进行中的交易相关。
借助 Manus,这位销售主管构建了一个工作流,将合适的 HubSpot 详细信息更贴近地呈现在邮件旁。最终完成的系统将 HubSpot、Gmail 和 Slack 整合到一个工作流中。它可以在 HubSpot 中存在相关信息时为 Gmail 邮件添加标签,在 Gmail 中显示有用的客户信息,并在企业级线索需要关注时通过 Slack 通知团队。
项目源自一个日常的销售难题
该项目始于一个实际的销售问题:销售代表在回复邮件之前应该了解什么?
例如,如果来自 acme.com 的 Priya 给团队发邮件,销售代表需要快速了解她是否已经在 HubSpot 中、Acme 是否为目标客户、是否有进行中的交易,以及谁在负责这层关系。这些信号决定了回复应该是快速处理、转交他人,还是采用其他方式处理。
Manus 帮助将这个问题转化为一个可用的数据层。HubSpot 已经在联系人、公司、交易和所有权记录中存储了这些信息。挑战在于识别哪些字段在回复时真正重要,并让它们在 Gmail 中可访问。
这将问题简化为一组简单的信号:谁发的邮件、他们属于哪家公司、该公司是否已知、是否有进行中的交易,以及谁拥有该账户。这成为 Gmail 工作流的基础。
Gmail 中的浏览器扩展和标签
一个小的产品决策让该工作流更易于销售代表理解。Gmail 标签并未被用作复杂的评分系统,而是作为一个简单的信号。
在这个虚构的模型中,标签即信号。当销售代表点击它时,浏览器扩展会打开,显示回复前所需的基本线索或客户详细信息。
例如,如果来自 Acme 的 Priya 给团队发邮件,而 Acme 已经存在于 HubSpot 中,该邮件会被相应地打上标签。如果发件人已是客户,销售代表可以基于更多账户历史进行回复。如果发件人与某个进行中的企业交易相关,销售代表可以优先处理回复。如果发件人所属公司没有负责人,团队可能需要在回复前分配负责人。
邮件被打上标签后,销售代表可以点击标签,在收件箱内打开扩展并查看相关的 HubSpot 详细信息。
Slack 帮助团队对重要线索采取行动
Gmail 帮助单个销售代表以更充分的信息进行回复。Slack 则帮助团队在重要线索需要关注时进行协作。
在这个工作流中,Manus 构建了一个 Slack 机器人,用于针对 HubSpot 中的企业入站线索发送 Slack 通知。Slack 消息可以告知团队某家高匹配度的公司已主动联系,包含公司名称、显示可能的负责人,并指引大家回到相关的邮件会话或记录。
例如,如果某个企业潜在客户从目标账户发来邮件,且尚未分配负责人,Slack 可以提醒团队。这样可以让该线索对整个团队可见,而不是被埋没在某个人的收件箱中。
Slack 让相同的潜在客户信息对更广泛的团队可见。高匹配度的潜在客户可以在被遗漏之前被看到、分配并跟进。
其他团队能从这个流程中学到什么
该项目之所以成功,是因为 HubSpot、Gmail 和 Slack 被视为独立的层。每一层都被单独构建、独立测试,然后组合成一个适合团队现有销售流程的工作流。
第一层是 HubSpot 数据模型。团队必须确定在跟进时哪些字段是真正有用的,例如联系人身份、公司匹配、负责人、交易状态、潜在客户来源、计划和下一步。Manus 被用于识别有价值的 HubSpot 字段,并创建一个工作流其余部分可以使用的同步数据库
第二层取决于访问权限。在本案例中,团队使用的是 Google Workspace,因此 Gmail 授权可以通过 Google auth 完成。这一点很重要,因为工作流需要权限来读取邮件、将发件人与从 HubSpot 派生的数据库进行比对,并根据自定义规则应用标签。然后使用 Manus 根据这些规则自动为邮件打标签。
第三层是面向 Gmail 的体验。在标签生效后,Manus 被用于构建浏览器扩展程序,该扩展会显示 HubSpot 风格的图标,并在 Gmail 内加载相关的潜在客户或客户详情。同一次构建还需要支持组件:主机插件、登录网站和用户授权流程。这些工作在 Manus 中作为独立的一层处理,然后再与系统的其余部分组合。
对其他团队的实用构建建议是,先检查访问权限级别,然后定义最低限度的有用字段,测试标签逻辑,再构建可见的界面。如果缺少任何一层,这种体验对销售代表来说要么不可靠,要么对团队来说太难采用。
