有没有人曾经configuration过一个帮助台/售票系统，通过相同的迭代过程来创build“正确的”门票类别？
修订1：
一切似乎都很好，直到你意识到你在每个公司的网站上都有上述function，所以你试图把一个网站指标join到层次结构中，而且一切似乎都很好。 然后，大老板会想要知道所有的基础架构票据，但是由于您拥有16个不同的基础架构存储桶（每个站点一个），因此您无法轻松回答这个问题。 等等，等等。
根本问题是，我们试图使用一个静态层次结构来模拟内在多维的东西。 问题不仅在于切分数据。 分层结构越“完整”，服务台分析师就越难以对每张票进行正确的分类（“这是一台服务器，但它在纽约办公室，所以在服务器或纽约州下面呢”）同样的问题存在于关系数据库中，所以最终创build了多维数据集。 它存在的博客post，所以最终你可以标记一个职位与多个类别。 标记是答案，但大多数票据跟踪产品不支持这个概念，所以我们回到了静态层次结构。
考虑到这一点，我很有兴趣看看人们如何制定自己的范畴层级，以便在保持相关性的同时保持尽可能广泛的范围，同时不要让分析师为此付出沉重的代价。
谢谢
当你说问题是你试图用一个分类字段来编码一些固有的多维的东西的时候，你是完全正确的。 其他维度需要额外的字段。
我们使用IssueTrak，它有可用的标准类别层次结构。 但它也有一个单独的字段位置，所以你可以做位置，或按类别，或两者的报告和计数器。 还有其他的领域，可以打开或closures您的特定网站。 例如，如果需要，可以将地点卷起到区域中，如果需要，可以将它们称为与地点和区域不同的地方。 你可以打开部门，如果你想使用这些。 有组织。 有资产项目，例如，您可以将票证与Server01相关联，并且Server01可以拥有自己的一组特征，您可以报告。
再次，我认为尝试将各种维度编码到一个层次结构是一个错误。 在我看来，你需要单独的领域，你可能想报告的各种types的东西。
我无用的答案是尝试支持标签或严重依赖search。
我的经验是，你投入的时间越多，select的时间越长，人们select正确的类别的时间就越less。 默认情况下更容易，或者select最为模糊的类别，而不是花费额外的工作时间来select最具体的类别。
让他们真的很简单，并确保类别反映你将报告。 如果您只想通过服务器或工作站报告故障，那么添加较大的层次结构树对于导航每个日志条目是没有意义的。
如果您对报告不感兴趣，请不要创build预定义的类别。 几乎可以肯定的是，你会遇到不适合你的模式的东西，因此会被误分类。
您正在寻找一个类，类别，types和项目分类。 你被困住了，因为缺less某种configuration数据库（这将有助于ITEM列表）。 另一个问题是，您应该使用帮助台软件来确定哪些服务受到任何问题的影响，而不是哪些服务器的停机时间最长。 如果您select基于服务的模型，确定类，类别，types和项目会变得更容易。 我build议把它作为组（Class），应用程序（类别），服务（types），实际上是什么被打破（项目）也是因为你可以使用时间和票据关系来显示一个问题在你的环境中的影响。 这是一个例子：
用户呼叫，因为他的团队无法得到他们的电子邮件（CCTI可能是Windows，交换，电子邮件，客户端）交换人看看交换和报告交换对其他人都运行正常，并追踪到networking问题。 他的门票应该closures，他开了一张新的门票让networking小组看看基础设施。 交换机票应该与新的（CCTI，networking，内部，连通性，桌面）相关，因为交换机变坏了，所以票以该分辨率closures。 现在，当您针对电子邮件运行可用性报告时，您应该看到中断并且与networking问题有关。
我对你有类似的困境。 目前，我们有3个业务部门需要使用这个跟踪器，我们使用selectmatrix来确定谁应该被通知哪个类别，而且谁可以发布在哪个类别。
因为我们有在企业之间漫游的员工，我们实际上使用商业名称的第一层类别，而在支持的领域使用第二层。 例如：
这个模式还是很新的，所以我们还没有遇到任何问题（还）
有两件事情伸给我; 重新阅读你的问题。
我们有几个卫星办公室，但是他们很小，基本上可以由一个IT人员来处理。 真正的解决scheme不是标记，而是订阅。 能够做出多重任务是一个关键的function，如果你真的不能处理的事情。
另一个例子：Launchpad提供“也影响”，并将注释汇集到一个单独的线程中。 像这样的东西可以订阅NY技术和服务器技术，并logging发生（或不）的交互。