Areas of Representation

Agencies represent talent in what shall be called areas of representation. Areas of Representation are expressed in the RepArea categorical variable node. The RepAreas have names such as Writer, Director, Actor, Musician, and so on.

The way to think about this is: you should be able to say, "We represent [Client Name] in their work as a [RepArea]."

Areas of representation are often contractual. When the clients sign with the agency, we agree to represent them "in specific areas," and that implies "not in the other areas.". For example, the agency may agree to represent a client as "Musician" or as "Actor." Or "Writer" and "Speaker".

The model should allow many relationships to be expressed.

Let's build the model from the ground up in an example.

For every client we represent, we create a Representation node with a HAS_REPRESENTATION relationship:

We then attach to that Representation node one applicable area of representation, or RepArea, using the REPPED_AS relationship:

It is not uncommon to represent a client in an area but only for transactions occurring within a specific geographic territory. For example, we may represent a music performer in the United States, but nowhere else. Or we could represent an actor in the USA, Canada, and Europe except Italy. Many combinations are possible.

To model this, we will start with a Representation node for each area of representation. We will also introduce the GeoArea node in order to model a geography.

Below is a Writer we represent in a specific geography, so we attach a GeoArea to the Representation node:

What if we represent the client in "all areas"?

It is better to be specific about the areas in which we truly represent the client, because if we were to attach a REPPED_AS relationship to all the existing RepArea nodes, we would create odd situations where trying to generate a dropdown list of writers might list sports clients. Even if we technically represent the client "in all areas," we're still going to be specific about which ones. If we need to do a deal in an area we haven't attached as a RepArea, we can add it when ready.

When a party is represented in multiple roles, such as both a Writer and a Director, we will create separate Representation nodes for each area of representation. Each Representation node encapsulates a specific RepArea (in the diagram below we've removed the GeoArea for clarity):

Remember, if we represent that party in a RepArea within a specific geography, we attach the GeoArea discussed earlier. You can see that we can have different GeoAreas for each RepArea.

Areas of Representation are closely associated with the client team. Also, see geographic area for more information on the contstruction of :GeoArea for use with Areas of Representation.

Frequently Asked Questions

Aren't these RepAreas just "vocations?" We've used that term before.

Areas of representation are not directly related to a concept like "vocations." A client may be a musician, but that doesn't mean we represent that client as a musician. The list of things a client can do versus what services of theirs we sell are not necessarily the same.

Can't we simply attach clients to a UTA department?

The department is an organizational dimension in the agency, used as a container that holds the identity of one or more leaders as well as a collection of employees. While many agents think of the clients as belonging to their particular department, it is better to acknowledge the client is represented by the agency.

Departments can confuse the concept of representation. For example, take the use case of two departments: MP Lit and TV Lit. Do we associate a writer with one or the other? For the purposes of the agency, we represent the client as a writer. Are we going to tell any writer we represent that we can only sell them into television projects because they are in the TV Lit "department"? No.

The fact that a writer's agents work in MP Lit or TV Lit does not matter to the client. The agency should think of itself as having a roster of Writers. While we can certainly derive a "department roster" bu aggregating all clients with agent in a particular department, it is more natural to create rosters of the clients we represent by area. Here are UTA's "writers." Here are UTA's "actors."

Can't we infer the area of representation by the departments to which the agents belong?

Again, this is conflating the department name with a specific area of representation. There is no hard boundary of the areas of rep an agent can cover, so tying areas of rep to an internal implementation detail like the agency department invites error. Further, we want to be explicit in authoritative data rather than rely on inference.