夜雨聆风客户背景：智能支付终端背后的复杂服务生态
随着移动支付和数字化零售的发展，智能支付终端已经成为零售、餐饮、商超等场景中不可或缺的基础设施。
本案例客户是一家全球领先的智能支付终端研发制造企业，产品广泛应用于门店收银、商超结算、餐饮支付等场景，并长期保持国内市场领先地位。
从表面看，企业提供的是支付硬件设备。但实际上，每一台终端设备背后，都连接着复杂的支付生态，包括：银行接口、财务系统、库存系统、会员系统、第三方支付平台等。
每一次支付行为的完成，都意味着多个业务系统之间正在协同运作。
因此，企业真正的竞争力并不仅来自硬件本身，而是来自硬件背后的服务能力、生态连接能力和持续支持能力。
随着业务从国内市场走向全球，客户服务体系开始承受更大压力。原有模式在国内市场尚能运转，但面对全球客户时，问题迅速放大。
假设一位南美客户遇到设备故障，需要紧急技术支持。在过去的服务模式下，处理过程往往是：
对于支付业务而言，设备故障往往直接影响交易、门店运营和客户体验。这样的响应周期显然无法满足全球客户的期望。
随着产品不断迭代，企业积累了大量文档：不同设备型号、不同固件版本、不同软件版本、不同语言资料、不同客户场景说明等等。
问题不是没有知识。问题是知识太分散、结构太复杂，客户很难快速找到自己真正需要的内容。
很多客户明明可以通过文档自助解决问题，最终仍然不得不提交工单。
客户需要完成的动作不限于：查阅产品文档、下载工具资料、提交技术工单、联系客户经理、查看服务状态等等。
但这些动作分散在不同系统中。对于客户来说，这不是“服务体系”，而是一组割裂的工具。
企业内部同时运行多个系统，比如：Salesforce 管理客户信息、邮件系统处理支持请求、知识库管理产品文档、服务系统处理工单、身份认证系统管理账号权限等。
管理员需要维护多套账号、多套权限和多套客户信息。系统越多，协同成本越高。
最终，原本用于支持业务增长的系统，反而成为阻碍业务扩张的负担。
企业意识到，单点优化已经无法解决问题。
修补邮件流程，不能解决全球响应问题
迁移文档系统，不能解决客户找不到内容的问题
增加人工支持，无法长期支撑全球业务扩张
客户真正需要的是：
一个能够连接客户、知识、流程和服务团队的统一服务平台。
这个平台需要实现三个目标：
项目团队选择 Jira Service Management 与 Confluence 作为核心平台。
但重点不是“上线两个工具”。重点是把服务流程和知识体系连接起来。
Jira Service Management 负责管理：服务请求、工单流转、SLA、自动化分派、服务状态通知等。
Confluence 负责管理：产品文档、使用手册、培训资料、开发者指南、FAQ 知识库等。
两者结合后，客户不仅可以提交问题，也可以在同一个服务体系中找到答案。
对于一家服务全球客户的企业来说，平台稳定性是底线。如果选择本地部署，企业需要持续投入资源处理：服务器维护、系统升级、安全漏洞修复、跨地区访问稳定性、运维团队负担等问题。
而 Atlassian Cloud 能够帮助企业降低这些复杂度：
全球客户需要随时访问服务平台，服务不能因为维护、升级或本地基础设施问题中断。
Cloud 能够持续获得 Atlassian 最新功能，包括 AI、Rovo 以及 Service Collection 相关能力。
企业不需要采购硬件，也不需要投入大量人力维护系统基础设施。
团队可以把更多资源投入到业务本身。
过去，客户进入知识库后，需要自己判断：
应该看哪个产品型号？
当前设备对应哪个固件版本？
文档是否支持自己的语言？
这篇内容是否适用于自己的场景？
这对客户来说很不友好。
项目团队通过 Confluence 与 Scroll Sites，将知识库重新设计为面向客户的服务门户。
客户进入门户后，可以直接按照：设备型号、固件版本、语言等维度筛选内容。系统会自动呈现符合条件的文档。这意味着，客户不再需要在复杂目录中搜索，而是可以直接获得与自己设备和场景相关的答案。
过去，客户通过邮件提交问题后，内部团队需要人工判断：
这是谁的客户？
属于哪个地区？
应该由哪个客户经理跟进？
是否需要技术团队参与？
应该如何通知客户？
每一步都可能产生等待。
项目团队通过 Jira Service Management Automation，将这些判断自动化。客户提交工单后，系统可以自动：
识别客户类型
判断所属区域
匹配客户经理
分派服务团队
发送状态通知
这让客户在提交问题后，第一时间知道自己的请求已经被接收并开始处理。这种透明度本身，就是客户体验的重要提升。
为了实现真正的一体化服务体验，项目还整合了 Salesforce、Jira Service Management、Confluence 与统一身份认证平台。
当 Salesforce 中完成客户签约并分配客户经理后，系统会自动触发后续流程：
客户看到的是一个完整、统一、专业的服务入口。内部团队看到的是一个贯通客户数据、知识库和服务流程的平台。
通过统一服务平台建设，企业实现了关键转变。
客户不再需要在多个系统之间切换，而是通过一个门户访问知识、提交工单并获取支持。
工单不再依赖人工转发，而是根据客户信息和服务规则自动流转。
文档不只是被存放起来，而是变成客户可以快速获取和使用的服务资源。
Salesforce、Confluence、Jira Service Management 和统一认证系统被连接起来，形成端到端服务链路。
知识、流程、客户数据和服务记录被持续沉淀，为后续 AI 应用提供上下文基础。
平台上线并稳定运行后，客户开始提出新的问题：
能否在现有平台基础上，进一步提升服务效率？
这也是 Service Collection 与 Rovo AI 能发挥价值的地方。过去，企业服务平台主要解决的是流程问题：
如何提交请求？
如何分配工单？
如何追踪状态？
如何管理知识？
而 AI 加入之后，平台开始进一步理解信息。Rovo 可以帮助服务团队：
汇总历史工单
检索相关知识
推荐解决方案
生成回复草稿
加速问题处理
这意味着，服务平台不再只是记录流程，而是开始主动协助团队工作。
企业真正需要的 AI，不是一个简单的问答工具。因为企业服务场景中，问题通常不是孤立存在的。
一个客户问题背后，可能关联：某个客户、某个设备型号、某个固件版本、某个历史工单、某个客户经理、某个产品团队、某篇知识库文档等等。
如果 AI 不理解这些上下文，它只能给出泛泛而谈的答案。
Teamwork Graph 的价值在于，它能够把人员、知识、流程、项目和数据连接起来，让 AI 更好地理解企业内部的工作关系。当 AI 理解了上下文，它就不只是回答问题，而是能够真正参与服务协作。
这个项目真正的价值并不是上线了一套新的服务系统。而是企业完成了服务体系的重构。
客户能够更快获得支持。
服务团队能够更高效协同。
知识资产能够被持续复用。
管理团队能够获得更清晰的服务流程。
AI 也能够在未来基于真实的知识、流程和数据发挥作用。
数字化转型的目标，从来不是让企业拥有更多系统。而是让团队把时间从“维护系统”中释放出来，重新投入到服务客户和推动业务增长之中。
真正的价值，不是从本地部署迁移到云端，而是让企业从“维护系统”重新回到“服务业务”。
