Client Team
The client team is the complete set of UTA personnel that currently, or formerly, once had or now have a role to support and service the needs of a particular client.
The client team is not limited to agents. It is also not constrained to any department where the UTA employee works, nor is it limited by whether or not the UTA employee participates in any compensation-related role with respect to that client.
To understand why we have this definition, let's examine the use cases for client teams:
- Financial. Most interested in revenue allocation, beyond the scope of this document.
- UX and Personalization. Many things UTA builds will need a list of "my clients" or "everyone on a particular team."
- Authorization. There are data and transactions where access must be limited to those on the client team.
These use cases seem similar but have significant differences, for example:
- Assistants could have authorization access as described above, but would not be part of a financial consideration.
- There may be assignments to teams that are highly stewarded (e.g., "responsible agent") and others were it may be sufficient to allow the team itself to self-organize.
We must balance the use cases with a design that works across all of them. Getting the client teams right is vital to the success of Authoritative Data.
There has been some previous planning around fixing the the client teams[1], including some that were in flight when the Authoritative Project started. Those are generally deprecated as we move this effort forward in Authoritative Data.
Connection to Areas of Representation
The client team is closely related to the client's areas of representation. The connection that ties agents and others from around the agency to clients is the client team. The client team is associated with individual agents that handle the client's work in one or more areas of representation.
Approach to modeling
The connection of the employee, usually an agent, to a client begins with creating an Assignment node that details the role that employee plays on the team, such as "Responsible Agent." The employee party is connected to this assignment node via the HAS_ASSIGNMENT relationship:
The Assignment is then attached to the Representation through the ASSIGNED_TO relationship:
In addition, the Assignment can have its own attached GeoArea indicating that this assignment is focused on a particular territory. ("[Agent] is the Responsible Agent for a musician client in this territory")
Team roles are captured within the Assignment node include "Responsible Agent" (the primary agent responsible for this client) and "Agent Team" (a team of agents representing this client). A full list of team roles can be found on the Assignment node.
Putting the models for area of representation and client team all together, the graph explodes a bit, but we end up with a useful structure for describing all kinds of representation configurations:
Note that there can only be one assignment per employee to a :Representation node. If one employee is a "Responsible Agent" for two clients, then that employee is connected to two :Assignment nodes, each of which would then be attached to the :Representation node of each client.
Business Rules for Client Teams
- Only the DMO may create a responsible agent assignment.
- All active clients must have at least one responsible agent.
- Any team member (responsible agent, or agent team) can add other team members without DMO approval.
- Team members must be parties of type person with an Employee role.
- When deactivating a team member relationship, only a responsible agent can deactivate another responsible agent.
- We will reject deactivating the last active responsible agent if the assignment is to a representation for a client that is still active with the agency. In other words, clients can't be orphaned with no team.
- For all agents added to the team, regardless of role, the assistants on the desk are automatically added to the team implicitly (they need not be explicitly named).