It should be noted that this comes with significant (as in worth consideration, not necessarily huge) operations and logistical issues. Here's 3:
* Balancing the assignment of users to appropriate agents
* Less flexibility for agents to be specialized (instead of an agent responding to all X related tickets everywhere in the world, an agent must respond to X, Y, and Z from these specific users)
* Handling user coverage when agents are busy, PTO, etc. The spirit of splitting agent access would mean agents would need to request access from an out-of-region authority in order to help with things last minute. An authority who will be expected to be responsive 24/7 without also being an attack vector
For the third point, couldn't you have some overlap between agents, so that each customer is served by N agents, each agent having a different set of M customers ? It is super expensive as an arrangement though.
Yeah that would work, but like you said it is expensive - or at least it is a cost that doesnt exist in the current model and would need specific attention. And we cannot assume customer requests / issues are uniformly distributed - it's not unlikely that 80% of issues come from 20% of customers. But if you give 80% of agents access to the same 20% of customers - you havent really solved the original problem. Albeit the risk factor is certainly lower and I would prefer this setup, who knows if that justifies the additional overhead and access control management.
Technically, the current model is a full M customer x N agents mapping. All customers served by all Agents. Adding some 0's to that mapping should certainly be possible without sacrificing much from current system. No way to know how many is reasonable
All that said, there is a natural logic that arises from this 'analysis' - Limit access to customers who are inactive, or who rarely have issues. A common sense addition would be to raise their default priority for when they do interact.
* Balancing the assignment of users to appropriate agents
* Less flexibility for agents to be specialized (instead of an agent responding to all X related tickets everywhere in the world, an agent must respond to X, Y, and Z from these specific users)
* Handling user coverage when agents are busy, PTO, etc. The spirit of splitting agent access would mean agents would need to request access from an out-of-region authority in order to help with things last minute. An authority who will be expected to be responsive 24/7 without also being an attack vector