曾经，Social Discovery Group 的业务支持部门面临着清理积压了四年多的 1500 份工单的艰巨挑战。 管理如此大量的问题是一项艰巨的任务，我们发现自己一直在努力跟上 KPI。 尽管我们尽了最大的努力，但门票不断从一个冲刺到另一个冲刺，让客户感到沮丧，我们也感到不知所措。 在这篇文章中，我们想分享我们解决这个看似不可能的任务的经验，让我们想起传说中的赫拉克勒斯第六次劳动。 我们将带您了解 SDGroup 团队面临的挑战以及我们为重建部门流程而采取的步骤。 我们采用了 STATIK 方法，事实证明，它在帮助我们清理积压工作并为我们的团队带来急需的帮助方面非常有效。 因此，如果您正在寻找解决工单积压的实用见解，请继续阅读！ 我们如何结束 1,500 张票的队列 作为业务支持部门，我们负责处理包含客户对我们服务的投诉和建议的工单。 例如，如果客户在使用我们网站的支付系统时遇到困难，他们可能会向 SDG 技术支持团队提出问题。 同事收集所有相关信息，包括问题重现步骤和屏幕截图，并在 Jira 中创建工单，分配给我们部门。 然后我们运行额外的测试以确保问题不是暂时的客户故障，而是我们这边的实际问题。如果得到确认，我们将创建错误报告，确定优先级，并将其转发给开发团队以供解决。 平均而言，我们过去每天收到 20-30 张门票。我们花了 2-3 个小时重现问题，但每当我们需要其他部门的帮助时，例如案例细节、服务重启、数据库中的数据或开发团队的分析，我们的任务往往会卡住。 我们的同事通常无法及时做出回应，而且没有单独的开发人员团队负责处理我们的错误报告。此外，与业务任务相比，我们的开发票的优先级较低。 结果，即使是高优先级的工单也可能在几个月内无法解决，而低优先级的任务则会在董事会上停留数年。  如您所见，这种流程导致在截止日期前出现太多不确定性，这引起了我们和我们的客户的不满。这种情况导致了几个问题： 当客户的问题没有得到足够快的解决时，他们会感到压力和沮丧，而我们也无法提供明确的时间表。 我们的支持团队感到很沮丧，因为客户几乎每天都要求更新未解决的问题。 支持团队写信给我们并收到相同的回复：“问题尚未解决。” 我们的团队不堪重负，无法接手旧任务并将它们链接为重复发生的案例。 当我们看着董事会上 1,500 项令人生畏的未解决任务时，我们感到绝望。我们知道我们需要改变我们的方法才能取得进展。 这就是那个时期票证生命周期的样子。  让我们来看看我们在管理问题积压时遇到的一些问题： 支持团队缺乏脚本来及时记录和过滤问题。 处于“新”状态的任务常常陷入困境。当我们没有足够的信息或访问权限来解决问题时，它会进入“升级”状态，我们会寻求其他部门同事的帮助。不幸的是，他们可能需要几周甚至几个月的时间才能做出回应。有时，由于大量传入任务，我们错过了评论。 一旦我们最终验证了这个问题，我们就将其转移到“等待修复”状态。由于开发资源长期短缺，这些问题可能多年都得不到解决。客户没有关闭工单，希望我们以后能得到更多的资源。 大量任务积压导致重复。很难合并和关闭它们，因为我们经常难以记住前几年已经开始的任务。 这种组织不善的方法导致 。 4 年内积压了 1,500 份未解决的工单  STATIK 方法和赫拉克勒斯的第六项工作 我们意识到我们的部门过于专注于处理票证，而不是解决解决客户问题的核心目的：提高他们对 Social Discovery Group 产品的忠诚度以及检测我们服务和网站中的漏洞。 您可能想知道，“如果您无法处理工作量，为什么不雇用更多员工呢？”然而，经验表明，通过建立有效的流程，我们可以在没有额外资源的情况下进行。 同样，赫拉克勒斯独自完成了他的工作，他将河流重新引向奥吉亚马厩，仅一天就将马厩清理干净。 为了简化我们的票务板，我们参考了 Mike Burrows 的书 并实施了 STATIK 方法，这是一种执行看板方法的系统策略。 “内部看板” 在实施 STATIK 方法时，我们遵循以下 ： 五个步骤   ，并得出结论认为客户需要对所提供的支持感到满意。为此，我们需要确保以下几点： 1. 我们确定了客户对我们业务支持部门的期望 我们任务工作的透明度使客户能够在任何给定时刻了解他们的请求发生了什么。 我们处理任务的及时性，为任何问题状态的反馈提供了明确的时间。   内部源是阻碍我们并导致我们自己工作受挫的原因。 2. 我们定义了不满意的内部和外部来源。 外部来源让我们的客户感到沮丧并阻碍了他们的体验。    我们检查了提交给我们部门的工单，并根据它们来自的部门、频率以及客户对响应时间和解决方案的期望对它们进行了分类。  3. 我们分析了工作量的来源和性质。   在这个阶段，我们评估了我们处理工单的效率，并确定了我们在一周内实际可以处理多少任务。 4. 我们评估了我们当前的能力。 此外，我们计算了从票据发起到发布生产中的错误修复所需的平均时间。   5. 我们重建了工单生命周期并创建了一个新流程。 我们的初始门票生命周期   利用获得的见解，我们开发了一个新的任务生命周期。 接下来，我们实施了一个全面的方法来解决前面提到的所有问题。我们采取了以下步骤： 我们为我们的支持团队创建了脚本，以在初始级别过滤任务。 我们为需要客户输入以调查问题的任务引入了临时的“返回报告者”状态。如果三天内没有提供必要的信息，任务将自动关闭。 我们删除了“已升级”状态，并将其替换为更具体的“问题确认”状态。 我们花了两个多月的时间审查和关闭重复的任务，在我们开始的 1,500 张票中，我们只剩下 800 张独特的票。 我们实施了服务水平协议 (SLA) 并为每个状态设置了计时器。 “问题确认”状态的计时器为 7 天，而“开发”状态的计时器为 30 天。 处于“问题确认”状态的任务促使我们联系我们的同事以寻求回应。我们改变了我们的沟通方式，使用私人消息或 Slack 线程而不是在 Jira 中发表评论。这将响应时间缩短为一天，而之前需要数周。 虽然我们没有为“Awaiting Fix”状态设置计时器，但我们分配了更多时间用于客户沟通和讨论。如果一项任务被认为不可行，我们会通知客户并优先处理更重要的任务。这导致暂停任务减少了 50%。此外，我们开始组织会议，让客户解释任务的重要性，帮助我们更好地确定工作量的优先级。 对于“开发”状态，我们设置了 30 天的计时器，并将此状态下的任务数限制为四个。这帮助我们专注于在设定的时间范围内修复错误，避免被看板上“开发”状态下 20-40 项不必要的视觉干扰所淹没。 为了确保我们的做法是可持续的，我们引入了 90% 的原则，这意味着 90% 的任务必须按时完成，由每个状态的计时器确定。我们使用 Jira 的控制图和 Jira-helper 插件来监控这一点，以构建第 90 个百分位数。 最后，我们为团队引入了额外的动力，承诺如果遵循第 90 个百分位原则将获得奖金，就像 Augeas 向 Hercules 承诺将十分之一的马匹作为奖金一样。  通过实施这种新方法并重建我们部门的流程，我们终于能够解决困扰我们四年之久的问题。 该解决方案不需要任何额外的时间、精力或预算，但我们显着减少了堆积任务的数量。在短短五个月的时间里，在只有两名聪明员工的团队中，我们设法将排队的门票从 1,500 张减少到仅仅 150 张。 这种经验告诉我们找出问题的根本原因以有效解决问题的重要性。 它还强调了拥有精心设计的流程的重要性，因为糟糕的流程将不可避免地导致问题的积累，正如我们亲身发现的那样。 由 Social Discovery Group 的软件测试工程师 Dimitri Andrews 撰写 


Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

解决客户支持的 Augean Stables：我们的成功故事

About Author

註釋

標籤

这篇文章刊登在

Related Stories

架构师指南：构建 AI/ML 数据湖参考架构

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

扬帆起航：利用数据湖开发生产级 RAG 应用程序

如何将您的工作流程提高 10 倍：17 个必备应用程序

架构师指南：构建 AI/ML 数据湖参考架构

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

扬帆起航：利用数据湖开发生产级 RAG 应用程序

如何将您的工作流程提高 10 倍：17 个必备应用程序

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps