Deal Engine

The Deal Engine is a backend service that enables storage of and computation against the terms of agency financial transactions as they evolve through the sales cycle. The primary function of the deal engine is to turn information about deal transactions into structured data, which will:

1. Enable analysis, comparison, and forecasts across deals, departments, and time periods

2. Serve as the "glue" between departmental systems and client processing, eliminating the need for rekeying and translating deal terms between systems

3. Allow automated tracking of contingent compensation and bonuses, reducing risk of missed or delayed revenue and opportunities

4. Reduce operational costs by eliminating manual work involved in tracking deals

Departmental systems use the deal engine as their database of financial transactions. Because the deal engine is exposed to departmental systems as an API, the use of deal engine will be transparent to business users, because they see the engine through their system. This means departmental systems will not implement their own deal modeling or computation logic, but will instead rely on the deal engine to provide these capabilities.

Definition of Deal

A deal is the commercial agreement, expressed as a set of contract terms, that monetizes one or more engagements.

The scope of a deal transaction is constrained: deals do not contain extensive data about the surrounding opportunity; they are instead intended to be "attached" to opportunities. Deals do not track all the pitching, status, activity tracking and other pre-sales efforts associated with creating the deal.

Deals vs Opportunities

It may help to describe where deals fit in to the overall opportunity management flows in the company.

Opportunity management consists of several elements:

Element	What it is	Why it matters	Part of Client Framework?
Project	A work being created outside the agency (film, TV series, podcast, tour, brand campaign)	Projects generally (but not always) happen with, or without UTA	No
Opportunity	A specific, fillable element of a Project that we can sell into (lead role, showrunner seat, podcast host slot, tour stop needing a headliner, or consulting engagement).	Defines the thing we are selling	No
Engagement	A link between the specific seller (usually our client, but could also be UTA in the cases where UTA provides direct services) and an Opportunity while it is being pitched or negotiated. For touring artists, for example, each Show is an Engagement.	Lets agents track pipeline stage (“submitted”, “offer”, “hold”) and allocate staff effort per client.	No
Deal	The commercial agreement that monetizes one or more Engagements. As stated above, this is structured data, and in many cases is complete enough to generate a contract document, as well as pass to client processing	Deals turns pipeline activity into revenue; feeds invoicing, royalties, and forecasts.	Yes

The relationship of these four elements can be visualized as follows:

graph LR

    %% ---------- NODES ----------
    Project((Project))
    Opportunity((Opportunity))
    Engagement((Engagement))
    Deal((Deal))

    %% ---------- EDGES + CARDINALITIES ----------
    Project -->|has opportunity<br>0:n| Opportunity
    Opportunity -->|has engagement<br>0:n| Engagement
    Deal -->|covers<br>1:n| Engagement

A specific example of this model in action might concern a movie project:

graph LR


    %% ---------- NODES ----------
    Project((Avengers<br>Project))
    Opportunity((Bruce Banner<br>Opportunity))
    Opportunity2((Tony Stark<br>Opportunity))
    Engagement((Mark Ruffalo<br>Engagement))
    Deal((Talent Deal<br>Deal))

    %% ---------- EDGES + CARDINALITIES ----------
    Project -->|has opportunity<br>0:n| Opportunity
    Project -->|has opportunity<br>0:n| Opportunity2
    Opportunity -->|has engagement<br>0:n| Engagement
    Deal -->|covers<br>1:n| Engagement

Elements like projects, opportunities, and engagements are tracked within departmental systems. Deals are tracked through the deal engine.

As is customary in a sales process, nascent forms of the deal are visible in the departmental systems and a certain number of these deals evolve into more concrete contracts as the deals close. Closed deals are traditionally called bookings in the agency business, but throughout the client framework it is best to reconsider bookings as simply a stage in the deal process, in which the client processing framework is signaled that it is time to collect payments and possibly recognize revenue.

The customer

The primary customers of the deal engine are not individual users, but systems that depend on the deal engine:

Customer (System)	Description
Departmental Systems	Systems built within UTA that create deals as part of opportunity management workflows
Client Processing	The system that tracks payments, invoicing, and revenue recognition for deals
Analytics and AI Systems	Systems that analyze deal data, along with other data sources, to surface trends, insights, reports, and forecasts

block-beta
    columns 1
    de(("Deal Engine"))
    block:ID
        ds(("Departmental Systems"))
        cp(("Client Processing"))
        an(("Analytics and AI Systems"))
    end
    de --> ds 
    ds --> de
    de --> cp
    cp --> de
    de --> an

    style ID stroke:none

Departmental systems create deals. Client processing consumes the deals. Analytics and AI systems report on the deals.

This is another view that illustrates the interaction of deals, departmental systems, and client processing:

flowchart LR
    DeptSystems((Departmental<br>Systems))
    DealEngine((Deal Engine))
    ClientProc((Client Processing))

    DeptSystems -->|Deals of<br>various types| DealEngine
    DealEngine -->|Deals receiving<br> payments| ClientProc
    DealEngine -->|Comps, Calcs,<br>and What-ifs| DeptSystems