Intercom 实战避坑指南（3）：HubSpot Service Hub 集成 Intercom 工单系统落地实践

发布时间：2026年06月15日 | 作者：优阅达-小优

本文结合真实项目 Use Case，详解 Service Hub 与 Intercom 工单系统的集成思路、关键流程与实施注意事项，帮助你快速搭建统一的客户服务入口。

作为 #Intercom 官方合作伙伴，DKM Ecosystem（优阅达）在服务众多中国本土及出海企业的过程中，发现企业在部署、实施和运营 Intercom 的不同阶段，经常会遇到各种技术难题、流程挑战和业务落地问题。

为此，我们推出「Intercom 实战避坑指南」系列，结合真实项目经验，系统梳理企业在客户服务、AI Agent、自动化流程、数据管理、多渠道集成等场景中的高频问题与实践经验。

1️⃣为什么通过 Intercom 发送 WhatsApp 消息会失败？

2️⃣移动端用户识别，为什么 User 不一定代表已登录用户？

无论你是客服、运营、产品经理、技术开发，还是企业管理者，都能在这里找到贴近业务场景的解答与启发。

典型场景：Service Hub 与 Intercom 工单系统的集成方案

在实际项目中，很多企业会搭建自己的客户服务门户（HubSpot Service Hub），为用户提供统一的服务入口，例如在线客服、知识库、工单查询以及问题提交等功能。

在这种架构下，Service Hub 通常承担的是“前台入口”的角色，用于承接客户的咨询与请求；而真正的工单处理、分配与跟进，则往往仍然依赖像 Intercom 这样的专业客服系统来完成。

因此，一个在项目实施中非常常见的问题是：如何让客户在 Service Hub 中提交工单的同时，后台能够自动进入 Intercom，并由客服团队统一处理？这不仅关系到系统之间的集成方式，也直接影响客户体验与客服效率。

本文将结合一个实际 Use Case，介绍 Service Hub 集成 Intercom 工单系统的整体方案，以及从工单提交到客服处理的完整流程。

01、项目背景

在本次方案中，客户希望在 Service Hub 页面中提供统一的服务入口，主要包含以下几个模块：

Live Chat
Your Tickets
New Ticket
Knowledge Base

其中，New Ticket 是本次集成的核心功能。

用户无需登录 Intercom，也无需切换到其他系统，只需在 Service Hub 中提交问题，系统即可自动在 Intercom 中创建对应工单，并交由客服团队后续跟进处理。

Service Hub 原型页面总览

02、技术方案概览

整体架构采用“Service Hub 前端入口 + Ticket 提交页面 + 后端 API + Intercom Ticket”的集成模式。

其中：

Service Hub：负责提供客户侧入口和提交体验
Ticket 表单：负责收集用户问题信息
后端 API：负责处理数据并调用 Intercom 接口
Intercom：负责工单管理与客服处理

整个流程对客户来说是无感知的，用户始终停留在 Service Hub 中完成操作，而客服团队则继续使用熟悉的 Intercom 工作台处理工单。

03、工单创建流程

Step 1、用户发起工单

用户登录系统后进入 Service Hub 页面，可以查看知识库、历史工单以及在线客服入口。当用户点击右上角的 New Ticket 按钮后，系统会打开或嵌入工单提交页面。

根据项目需求，提交页面既可以采用独立页面跳转方式，也可以通过嵌入式表单集成到现有 Service Hub 页面中。

Service Hub 中 New ticket 入口与 Your tickets 区域

Step 2、填写工单信息

在工单表单中，用户需要填写问题相关信息。常见字段包括：Name、Email、Subject / Title、Description。

同时也支持根据业务场景扩展更多属性，例如：Platform、Root Cause、Customer、Ticket Type 或附件上传。

通过这些字段，客服团队能够更快速地了解问题背景并完成分类处理。

New ticket 提交表单弹窗

Step 3、提交请求并创建 Ticket

用户点击 Submit Ticket 后，表单内容将提交至后端接口。

系统会首先完成必要的数据校验，包括：

必填字段检查
Email 格式验证
请求参数完整性校验

校验通过后，系统开始执行工单创建流程。

Step 4、自动关联客户信息

为了保证工单与客户身份正确关联，系统会根据用户提交的邮箱地址查询 Intercom Contact。

如果客户已存在：直接关联现有 Contact；
如果客户首次提交工单：自动创建新的 Contact 或 Lead。

这样可以确保所有工单都能与对应客户信息建立关联，方便客服查看历史记录和后续跟进。

Step 5、自动创建 Intercom Ticket

完成客户身份匹配后，系统会自动调用 Intercom Ticket API 创建工单。表单中的标题、描述以及业务字段会自动映射到对应的 Ticket 属性中。

对于客服团队来说，收到的工单已经包含完整的问题信息，无需再次手动整理或录入。

Step 6、处理附件信息

如果用户上传了截图或相关文件，系统会同步处理附件内容。需要特别注意的是：当前通过 API 上传的附件不会直接显示在 Ticket 属性区域，而是作为附件内容保存在对应的 Conversation 中。

因此，客服在查看工单时，可以在左侧 Conversation 区域查看用户上传的截图、图片或其他文件。

Step 7、返回工单结果

当 Ticket 创建成功后，系统会向前端返回工单编号。用户将看到类似：Ticket Submitted 以及对应的 Ticket ID。

至此，一次完整的工单提交流程完成。

Step 8、客服在 Intercom 中处理工单

工单创建成功后，客服团队即可在 Intercom Inbox 或 Ticket 页面中查看对应记录。

在工单详情中，客服可以查看：Ticket 信息、客户资料、工单分类字段、历史记录、上传附件等信息。随后根据实际情况进行回复、转派或跟进处理。

整个过程无需人工创建工单，也无需在多个系统之间复制信息。

工单从 Service Hub 提交后，在 Intercom 中查看 Ticket 详情与附件位置

04、实施过程中的几个注意事项

在实际项目交付过程中，以下几个环节建议重点关注：

Point 1、Ticket Type 配置

确保 Ticket Type 已提前在 Intercom 中创建并配置完成，否则可能导致工单创建失败或字段映射异常。

字段	是否必填	说明
name	是	客户姓名 / 提交人名称。
email	是	用于查找或创建 Intercom Contact。
title	是	Ticket 标题，对应 _default_title_。
description	是	Ticket 描述，对应 _default_description_。
platforms	否	客户遇到问题的平台，例如 Web、iOS、Android。
rootCause	否	问题根本原因，用于 Ticket 分类或内部分析。
customerTicketType	否	客户 Ticket 类型，例如 Issue、Question、Support Request。
file	否	客户上传的截图、图片或相关文件。

Point 2、字段映射保持一致

前端表单字段、后端处理逻辑以及 Intercom Ticket 属性应保持统一命名，避免出现工单创建成功但属性未正确写入的情况。

前端字段	Intercom Ticket Attribute	说明
title	_default_title_	Ticket 标题。
description	_default_description_	Ticket 主要问题描述。
platforms	Platforms	客户问题发生的平台。
rootCause	Root cause	问题根因分类。
customerTicketType	Customer Ticket Types	客户工单类型。