工单分类负责客服配置不 Scale

[leeyeh]

现在的逻辑是找到对应的分类，随机分配给负责该分类的客服，如果没有负责的客服则在所有客服中随机分配。这样的问题是：

分类是从用户遇到问题的维度来划分的，客服很多时候是负责一整个大的分类。二级甚至更低的分类可能变动会很快，每增加一个子分类都需要把所有的这个大类的客服同步过去。而现在操作负责的客服是只能客服自己操作的，这个变更的成本就很高（尤其是当客服数量较多时）。

如果管理员能有一个界面统一修改分类负责的客服能缓解这个问题。但这个开发成本很高而且解决的也不彻底。

一种简单的处理是在这种情况下将子分类的负责人留空，然后在分配的时候发现没有负责的客服就去找上级分类的负责客服。实现上可能需要给「分类 - 客服」的映射加个内存缓存以提高性能。

[leeyeh]

听听 @sdjcw @weakish @sdjdd 的想法。

[sdjdd]

我觉得可以。缓存就没必要了吧，只是在创建工单的时候查询一次，应该不会有性能问题。

[sdjcw]

一种简单的处理是在这种情况下将子分类的负责人留空，然后在分配的时候发现没有负责的客服就去找上级分类的负责客服。

是个解决办法，不过是否会出现某客服将自己设置到了具体的自分类，之后自己就成为这个分类的唯一处理人，他想加别人到这个分类又没权限。

或者换一个思路：一旦有客服，新的分类就把父分类客服都复制到子分类中，当某个客服觉得自己不适合这个子分类后（往往是接到一个工单感觉自己不适合处理），手动将自己从该子分类移除。这样和默认找父分类确认客服达到的效果一样，而且可以自己决定是否退出这个分类。而且这样看起来也免去了缓存的工作。

另外就是可以考虑开放客服与分类关联的编辑权限，任何客服都能编辑任何分类下的人员，只要保留一个操作列表备查即可。对于规模较小的团队这样也是挺方便的。

[leeyeh]

或者不要「复制」，而是分类有个属性标记「是否合并父分类的客服」（达到「同步」的效果）？

[sdjcw]

我感觉复制父类客服没什么缺点。

[leeyeh]

复制与同步的区别类似存储里的 embedded document 与 Pointer。

复制模型理解起来比较简单，但是其实没有改变整个模型的冗余属性。除了加子分类的场景还有一些问题是没有解决的，比如一个分类要移除或增加一个新的客服，还需要手动操作负责所有的子分类。而且对于增加子分类的场景也不是完美的，在我们这种不想复制的用法下，我增加一个子分类还需要再去删除复制过来的客服。

同步模型的优势是，真的只需要改一个地方，并且把是否要「继承」由每个子分类单独控制。主要缺点是相对来说运行时的成本更高。

[weakish]

开放客服与分类关联的编辑权限，任何客服都能编辑任何分类下的人员，只要保留一个操作列表备查即可。

+1