Deal modeling

Before deciding on any architectural or technology approach, we must first establish a conceptual viewpoint on how we think about entertainment and sports deals of interest to the agency. This process of working out the semantics and construction of deals we call deal modeling.

Deal modeling concerns itself with two broad areas:

1. How we decompose a financial transaction into its parts
2. How we organize ourselves to gain a comprehensive understanding of the business context for entertainment deals in order to build and evolve the models quickly and accurately

Here we are not concerned with exactly how we implement -- we are simply starting with agreement on decomposition and approach. We'll get into implementation when we get to architecture.

Decomposing financial transactions

Deal modeling breaks the domain of sports and entertainment deals into deal types and clause primitives.

Deal types

All deals break into "types" (touring deal, writer deal, talent deal, endorsement deal, etc.) that generally bound the domain that the data schema, business rules, and calculations will need to implement the capabilities described earlier, for that particular deal type.

Thinking in deal types allows us flexibility in discovering and evolving the specific business rules around a particular deal domain over time.

We will need a registry of deal types that are supported. The includes the versioning of the deal types as they evolve over time. This will allow calling programs to learn what capabilities are supported by each deal type.

Clause Primitives

WARNING

The following primitives are described logically. In the architecture section we will discuss an implementation approach, but for now, think of these primitives as logical constructs.

All deal models are composed from a series of clauses. A clause is a discrete deal term. The catalog of clause types that can be used to model deals are called clause primitives.

There are two types of clause primitives:

Clause Type	Description
Simple	Non-financial terms that need only be captured as text.
Financial	The specific conditions under which money is paid. Financial clauses are composed of subtypes, described below.

Simple clause primitive

A simple clause will generally be passed through as text and has no monetary implications the agency needs to track. A typical example might be:

Artist to receive headline billing.

Financial clause primitive

The financial clause primitive is in turn divided into two subtypes:

Clause Type	Description
Guarantee	Describes payments due that are not dependent on something that may not happen. Guarantees are paid on a schedule, even if there is only one payment.
Contingent	Describes payments that may or may not become due based on either the performance of the client, or some achievement or external event occurring such as “worldwide box office” or “net box office receipts.” A contingent clause describes a scenario that is merely possible: something must activate the clause.

graph TD
  deal((Deal))
  simple((Simple))
  financial((Financial))
  guarantee((Guarantee))
  contingent((Contingent))

  deal --> simple
  deal --> financial
  financial --> guarantee
  financial --> contingent

Clause Block primitive

These financial clauses -- guarantee and contingent -- can be grouped together as clause blocks to form more complex contractual structures.

graph TD
  deal((Deal))
  f1((Financial Clauses))
  g1((Guarantee Clause))
  c1((Contingent Clause))
  cb1((Clause Block 1))
  cb2((Clause Block 2))
  f2((Financial Clauses))
  f3((Financial Clauses))
  g2((Guarantee Clause))
  c2((Contingent Clause))
  g3((Guarantee Clause))
  c3((Contingent Clause))

  deal --> f1
  f1 --> g1
  f1 --> c1
  deal --> cb1
  deal --> cb2
  cb1 --> f2
  cb2 --> f3
  f2 --> g2
  f2 --> c2
  f3 --> g3
  f3 --> c3

Common primitives

The following common primitives can be used to connect clauses and clause blocks:

Primitive	Description
Clause Operator	Define how two or more clauses (or clause blocks) are combined in a deal model. They describe logical or financial relationships between clauses, similar to how AND, OR, or mathematical functions connect terms in an expression
Clause Conditional (when)	Define when a clause (or group) becomes active. A conditional references an event defined elsewhere in the model

Building deal understanding

The point of building primitives as described above is to give some sort of transition from a business-level understanding of the deal to the actual building of the software that implements the rules of that particular deal type.

The workflow looks something like this:

block-beta
  columns 5

  gather["Capture<br/>domain knowledge"]
  space
  model["Describe<br/>inputs and calculations"]
  space
  generate["Generate<br/>deal template "]

  gather --> model
  model --> generate

Capturing domain knowledge is the most difficult part of building a deal management system. There are many options for doing the actual technical build (or buy) but there is no way around having the ability to learn deeply how the deals are negotiated, constructed, and executed.

The process is non-trivial. Department personnel have to be interviewed, contract and bookings reviewed, and then the data, anecdotes, lore, and wisdom must be synthesized in order to understand specific deal structures in different domains. From that discovery work a model of a deal type can be constructed.

Experience shows that this modeling effort is about 20% technical work, and 80% acquiring in in-depth understanding of the underlying business. Gaining that understanding is harder than it looks: the modeler soon realizes it is common to find no single point person in a department that understands all the nuances of a particular deal type. The collective department often needs to be consulted to get a full picture.

Gaining this experience and knowledge is challenging for those of us outside of the agency's dealmaking sphere. There are some specific challenges to overcome:

Incomplete information

While agents participate in the deal negotiations, it is not uncommon to lack final contract documents. This often surprises newcomers, but this is due to the business context of a talent agency:

The talent agent and agency are often not a party to the deal

The agency may represent the talent, but the talent makes the deal with the buyer. The deal documents therefore typically pass between the client's attorneys and the buyer.

In some cases, such as touring, or where UTA provides direct services, such as consulting or advisory services, the agency creates the contract and thus has direct knowledge of and responsibility for constructing the clauses.

In other cases, the agency participates in negotiations for the deal but the final deal terms between the buyer and seller parties are memorialized outside of the agency’s systems world by the respective attorneys. Thus the agency’s knowledge of the final deal terms may, at best, show up as a PDF copy of a contract document that was emailed by the buyer or the seller -- after the deal is concluded.

Time demands on experts

The modelers will need to know the domain well enough to ask the right questions. Just dealing with the logistics of setting the modeling meetings with the correct business affairs, sales operations, and agent personnel in the departments will itself take a great deal of time.

Confidentiality concerns

TODO

Evolvability

We continually learn new facets to deal construction, and new sorts of structures are invented. Union guild rules change. Concepts like "packaging" go away.

Deal management must be built with the understanding that a deal model will change, both because the modeling process is imperfect and not all information will be collected on the initial implementation, and because the industry evolves contract clauses all the time.

Exceptions

The system design must not assume absolutely every deal type can be perfectly templated. For any generalized business rule, there will always be a need to override it, or a particular clause structure might need to be constructed for a specific deal.

Concentration of expertise

If modeling becomes a slow and complex multi-year effort, this can lead to considerable expertise building up in a “chief modeler,” a rare individual who is entirely comfortable with deal complexity. The modeling effort risks bottlenecking on this individual who has become the “one person who knows how to model,” resulting in exponential delays in delivering deal management.

Overcoming these challenges

These challenges are not insurmountable, and moving forward incrementally capturing what deals we can will accrue significant benefits: as experimentation with deal modeling moves forward, the agency begins to codify knowledge previously held in in a few people’s heads. The more the agency models deals, the better it understands deals.

To mitigate the risks described above, it is crucial that modeling deals into a catalog must be made as straightforward as possible. The design goal would be any analyst in a sales operations role should be able to construct a deal type that is robust, correct, and well-documented, and get it registered to accept transactions. Similarly, as new information is learned, updating the deal models should be a simple effort.