DEMETER ICT · Zendesk 上线指南 · EP1
Zendesk 上线准备清单：正式启用前需要准备什么
一份面向实际运营的 Zendesk 上线指南，从品牌与客服渠道，到工单归属、知识库、自动化与上线测试，帮助团队在正式启用前把关键决策准备完整。
你已经购买 Zendesk、添加了客服人员，并连接了客服邮箱。这样就可以正式上线了吗？
系统也许已经可以接收客户请求，但在团队真正开始依赖 Zendesk 之前，还需要明确：每个工单由谁负责、非工作时间如何处理、跨团队协作如何交接，以及主管如何及时发现需要关注的请求。
这份 Zendesk 上线准备清单重点说明“上线前需要决定什么，以及为什么重要”，而不是逐屏讲解配置步骤。如果你还在评估 Zendesk，可以先查看我们的 Zendesk 解决方案概览。
Zendesk 正式上线前需要准备哪些内容？
在 Zendesk 正式上线前，应先明确服务范围、品牌结构、团队角色、客服渠道、工单信息、路由规则、服务目标、知识资源、自动化与报表。之后再进行完整客户旅程测试，并让实际使用系统的人员做好准备。系统配置应该真实反映客户请求如何进入、如何分配、如何解决以及如何持续跟进。
第一天并不需要启用所有功能。先从团队能够稳定执行的服务流程开始，再随着业务需求逐步扩展。
范围说明： 本指南聚焦于使用 Zendesk Suite 构建客户服务流程。具体功能、使用限制、AI 能力及集成方式取决于所购买的版本、附加组件与渠道。正式确定上线范围前，请结合业务需求查看 Zendesk 套餐与价格。
Zendesk 上线准备总览
可以用下表确认在不同准备环节中应该邀请哪些角色参与。实际负责人仍应根据企业组织结构确定。
| 准备领域 | 关键决策 | 建议参与角色 |
|---|---|---|
| 服务范围 | 团队将服务哪些客户与请求类型？ | 服务负责人、业务负责人 |
| 品牌 | 哪些面向客户的品牌身份需要独立体验？ | 业务负责人、市场、CX |
| 团队与权限 | 谁负责处理？谁可以访问或修改哪些内容？ | 团队主管、管理员、IT/安全 |
| Channels | 客户可以通过哪些渠道联系？由谁响应？ | 客服、渠道负责人、IT |
| 工单信息 | 处理工单和报表分析需要哪些信息？ | 客服人员、运营、报表负责人 |
| 路由与责任归属 | 包括交接过程中，谁对工单持续负责？ | 所有接收团队的负责人 |
| 服务目标 | 合理的响应与跟进承诺是什么？ | 服务负责人、团队主管 |
| Knowledge | 哪些知识内容可以被可靠使用？由谁维护？ | 产品、运营、知识负责人 |
| 自动化与 AI | 哪些工作可以自动执行？何时必须由人工介入？ | 流程负责人、管理员、IT/安全 |
| Reporting and testing | 如何验证流程能够正常运行？ | 主管、报表负责人、上线团队 |
1. 在配置系统前先明确服务范围
先明确哪些工作要由 Zendesk 承载。售前咨询、订单问题、技术支持和内部员工请求，可能分别需要不同的信息、责任归属和审批流程。
明确服务对象、请求类型、支持国家与语言，以及参与的团队。同时确认希望改善的运营问题，例如请求遗漏、跨团队交接缓慢、重复问题过多，或缺乏对未完成工作的可视性。
例如，一家零售企业可以先从一个品牌、两个市场的售后服务开始，而不是一开始就把所有客户互动全部迁移到 Zendesk。这样更容易控制上线范围。
准备内容： 服务范围说明、请求类型清单，以及明确的流程负责人。
2. 以客户体验为核心规划品牌结构
品牌结构应反映客户在联系企业时所期待看到的品牌身份。需要确认不同品牌是否需要独立的客服入口、呈现方式或知识体验。
在多个国家运营，并不意味着每个国家都必须建立独立品牌；同样，内部部门也不一定需要单独建立品牌。应先从客户可感知的差异出发，再决定后台如何组织。
- 客户沟通中应该显示哪个品牌名称？
- 哪些联系方式应该共享，哪些应该独立？
- 不同客户是否需要不同的政策或帮助内容？
- 跨品牌绩效应该如何统计？
准备内容： 品牌结构图，以及上线范围内所需的客户侧品牌资产。确定结构前应先确认当前 Zendesk 套餐是否支持多品牌。
3. 明确团队、角色与访问权限
添加客服人员只是开始。还需要明确谁接收请求、谁负责调查、谁审批例外情况，以及谁负责系统管理。
记录每个团队负责哪些工作，以及不同角色需要访问哪些信息。还应包括可能参与处理工单的其他部门，例如财务、仓库或技术团队，并明确协作方式及相关授权需求。
同时指定长期的系统负责人。上线后仍需要有人负责审核业务规则、权限和连接渠道的变更。
准备内容： 责任与权限矩阵、团队成员清单，以及明确的 Zendesk 管理员。
4. 只连接团队真正准备好运营的渠道
上线渠道应根据客户需求和团队实际响应能力来选择，例如客服邮箱、请求表单、网站 Messaging、语音或特定社交消息渠道。
对每个渠道都应明确负责人、服务时间、响应预期，以及非工作时间的客户体验。同时确认账号归属以及维护连接所需的访问权限。
连接一个渠道并不等于建立了背后的服务流程。例如，如果网站接入 Messaging，就需要提前定义无人在线时如何处理，以及在转交人工前需要向客户收集哪些信息。
准备内容： 渠道清单、负责人、服务时间、客户提示信息，以及每个上线渠道的端到端测试。
5. 明确每张工单需要哪些信息
客户只说“我的订单有问题”，通常不足以让后续团队立即处理。需要明确客服人员为了理解、路由和解决请求而必须掌握哪些信息。
根据不同业务场景，可能需要记录问题分类、产品、订单编号、国家、首选语言和业务影响等信息。字段定义应保持一致，才能用于后续报表分析。
应区分“首次受理时必须收集的信息”和“调查过程中再补充的信息”。过早要求填写过多字段，会增加客户与客服人员的负担。同时应明确哪些敏感信息不应被要求或存储在工单中。
准备内容： 工单字段字典、不同请求类型的必填信息，以及清晰的数据收集规则。
6. 建立路由规则与工单责任归属
路由决定工作流向哪里，责任归属决定谁持续负责推动问题解决。两者都必须明确。
需要决定请求如何进入正确的团队或客服人员、无法分类时如何处理，以及由谁监控仍未分配的工单。Zendesk 可通过业务规则以及在适用情况下使用全渠道路由来实现分配，但应先明确运营规则，再选择具体配置方式。
跨团队交接时，应提供足够上下文，让接收团队能够继续处理。同时必须明确在其他团队调查期间，谁负责持续向客户更新进度。
准备内容： 路由图、交接要求、异常队列，以及明确的客户跟进负责人。
7. 设置服务时间、服务目标与升级规则
“尽快回复”并不是一个可管理的服务标准。应明确服务时间、时区、节假日、优先级标准以及可衡量的响应目标。
如果使用 SLA，应确认适用指标，并明确目标按工作时间还是自然时间计算。首次响应、后续更新和最终解决属于不同承诺，应根据团队真正能够交付的服务水平设定。
明确工单接近服务目标时由谁接收提醒、逾期工单如何升级，以及等待其他团队处理的请求由谁继续跟进。自动确认消息也不应让客户误以为人工已经完成调查。
准备内容： 服务目标矩阵、营业时间表与升级责任。
8. 准备帮助中心与内部知识
先从客户和客服人员最常需要答案的问题开始，例如订单查询、账号访问、故障排查和退换货政策。
明确哪些内容适合公开自助服务，哪些内容必须仅供内部使用，例如调查流程或审批指引。为重要内容指定负责人，并建立产品或政策变更后的审核机制。
并非所有上线都必须等待一个完整的帮助中心。可以先从少量高准确度、高频使用的文章开始。如果计划让 AI 基于知识回答问题，还需要确认所选知识源能够覆盖预期问题，并适合目标受众。
准备内容： 按优先级排列的知识清单、发布/访问规则，以及每个重要主题的内容负责人。
9. 为自动化和 AI 明确定义工作边界
明确哪些工作适合自动化，例如确认已收到请求、自动分类、路由或提醒团队处理未完成工单。对于 AI，还应明确支持的任务、知识来源以及必须转交人工的情况。
为每个自动化流程定义触发条件、所需信息、正确结果以及失败时的处理方式，并检查不同规则之间是否冲突或反复触发。
例如，“解释退款政策”和“批准退款”是两种完全不同的责任。AI 能生成答案，并不代表它自动拥有执行财务操作的权限。
准备内容： 自动化与 AI Use Case 清单，并明确边界、审批机制、Fallback 路径与验收测试。同时单独确认产品与使用额度。
10. 准备报表、上线测试与团队培训
先明确主管为了运营服务需要看到哪些信息，例如：哪些请求还没有负责人？哪些工单等待时间过长？哪些交接环节容易卡住？哪些问题反复出现？
然后使用演示数据测试完整客户旅程。通过每个计划上线的渠道提交请求，检查路由和必填信息，进行回复、添加内部备注、变更状态，并确认客户最终看到的结果。
- 非工作时间会发生什么？
- 当请求缺少必要信息时如何处理？
- 其他团队接手时，是否可以避免让客户重复说明所有信息？
- 原负责人无法处理时由谁接手？
- 工单标记为已解决后，客户再次回复会发生什么？
- 当自动化或 AI 无法继续处理时，团队如何接管？
培训客服人员时，不应只教“在哪里点击”，而应围绕这些真实场景进行演练。同时指定上线支持负责人，并设定上线后的复盘日期。
准备内容： 报表需求说明、完成的验收测试、运营指引与上线后复盘计划。
示例场景 · 非真实客户案例
这些准备工作如何串联起来：订单缺件场景
假设一家零售品牌收到客户反馈：订单中少了一件商品。客服团队需要仓库协助调查，才能确认下一步处理方式。
- 记录上下文：客服记录订单编号、缺失商品和问题分类。
- 明确责任归属：仓库负责调查期间，客服仍然负责对客户进行跟进。
- 发起内部协作：通过既定协作流程，将仓库调查所需信息完整传递过去。
- 跟踪进度：团队记录下一次更新期限，如果调查停滞则及时跟进。
- 确认处理结果：任何补发或退款都应先按照既定审批与系统流程完成，再向客户确认。
这个场景把工单信息、访问权限、路由、服务目标和知识连接在一起。自动读取订单数据或执行退款可能需要额外系统集成，不能因为工单存在于 Zendesk 中就默认这些动作可以直接完成。
Zendesk 上线前需要一次启用所有功能吗？
不需要。应区分哪些能力是稳定上线的必要条件，哪些功能可以在团队运营稳定后再逐步加入。
| 上线前应建立 | 可考虑后续阶段加入 |
|---|---|
| 明确的服务范围和工单责任归属 | 业务需要时再增加品牌或市场 |
| 可正常运行且负责人明确的渠道 | 人员和流程准备好后再增加更多渠道 |
| 必要的工单信息与路由 | 更复杂的路由与系统集成 |
| 准确的运营指引与核心知识 | 更完整的多语言帮助中心 |
| 基本运营可视性与已测试流程 | 更深入的分析、自动化与 AI Use Case |
实际顺序取决于业务场景。某些在这里列为“后续阶段”的能力，对你的业务来说也可能从第一天起就是必需项。
上线范围应该匹配团队人员、业务流程以及 Zendesk 套餐要求，而不是只根据客服人数选择套餐。
Zendesk 正式上线准备清单
请与实际负责服务交付的团队一起逐项确认。
- 已确认上线范围与支持的客户群体。
- 品牌结构与客户体验一致。
- 团队角色、访问权限与系统管理责任已经审核。
- 每个上线渠道都有明确负责人，并完成服务流程测试。
- 工单能够记录后续处理所需的信息。
- 路由、交接与客户跟进责任明确。
- 已确认服务时间、服务目标与升级规则。
- 核心知识内容准确，并有明确内容负责人。
- 自动化和 AI 的边界与 Fallback 路径已经测试。
- 主管能够识别未分配及等待过久的工单。
- 客服人员已经演练真实业务场景。
- 已指定上线支持负责人和上线后复盘日期。
如果某一项尚未准备好，应评估对客户的影响，再决定上线前解决，还是缩小首阶段上线范围。
Zendesk 上线配置常见问题
可以先只用 Email 上线 Zendesk 吗？
可以。如果 Email 已经满足当前客户需求，那么先从 Email 开始是一个实际可行的方式。但仍然需要明确责任归属、路由、关键工单信息、响应预期并完成测试。团队准备好后再逐步增加其他渠道。
Zendesk 上线前必须先完成 Help Center 吗？
不一定。是否需要完整公开的 Help Center，取决于自助服务在你的服务模式中的重要程度。至少应为客服准备可靠的内部知识；如果计划启用 AI，也应先确保有合适的知识来源。
每个国家或事业部都需要独立 Brand 吗？
不需要。应根据客户侧品牌身份、联系方式和知识需求来决定，仅仅因为国家、语言或内部部门不同，并不足以成为新增 Brand 的理由。
是否应该在正式上线前就配置 AI？
只有在 Use Case、知识、边界和人工交接机制都准备好时才建议这样做。完全可以先上线稳定的人工流程，之后再加入 AI。如果 AI 属于首阶段服务的一部分，就必须纳入验收测试。
Zendesk 上线配置通常需要多久？
时间取决于渠道数量、团队、品牌、系统集成、数据迁移以及审批要求。建议先确定范围与验收标准，再承诺正式上线日期。
什么时候应该引入 Zendesk 实施服务伙伴？
当企业需要把业务流程转化为可运行的系统配置、协调多个团队、连接其他系统，或希望更有计划地完成上线时，可以考虑引入实施伙伴。如果已经在使用 Zendesk，也可以通过 DEMETER CX Optimization Service 来识别值得优化的环节。
规划 Zendesk 背后的客户服务流程
一个可靠的上线应该从可控范围开始：客户能够联系到你，客服拥有处理所需的上下文，每个工单都有负责人，主管也能看到哪些工作需要关注。
DEMETER ICT 可以结合你的实际客户服务运营，一起梳理 Zendesk 的上线与优化需求。无论你正在准备新系统上线，还是希望检查现有配置，都可以带上当前使用的渠道、团队结构，以及几个目前最难管理的客户请求场景与我们讨论。
你也可以进一步了解 Zendesk 解决方案概览，查看 Zendesk 套餐与价格，或了解我们的 DEMETER CX Optimization Service。
