UTA CLIENT FRAMEWORK – PHASE 2 – DRAFT SCOPE APPENDICES
Appendix A: Phase 2 System Requirements, 19 Sep 2024
These are the requirements anticipated for Phase 2 authored independently by the finance team as of September 2024. Appendix B adds some basic commentary as to how these are generally addressed in this scope document.
1. Onboarding
| No. | Requirement |
|---|---|
| 1 | Onboarding materials/link to be distributed securely with notifications delivered dynamically. This initiates the Client access to their Client Portal (front facing system). |
| 2 | New client data entered into parent record should populate tangential systems accordingly. (Client Processing System, Booking system etc). |
| 3 | Bank account verification automated (currently manual). This can be a link originate out of PaymentHub or future state client processing system link. |
| 4 | New client data entered into parent record system should create a Client card in Booking System (CRM) and Client Payment Processing system. |
| 5 | Client card data includes: RA, Loanout(s), Address, Commission Rate, payment preference type, all client banking information (masked for unauthorized staff), third party participants with agreed commission rates, Accounting representative, VAT registered (UK), client notes area, and tab for attachments. Example: Central Withholding Agreement (CWA) or Letter of Direction. |
| 6 | Changes to Client record to trigger change in tangential systems with audit trail (Changed From; Changed To) with date and staff member responsible. |
| 7 | Changes to Client/Buyer/Participant record to trigger a notification of the change to respective parties. (Agent Asst, Client Team, Accounting Rep). Within these changes to client/participant/buyer records, it's required to make a comment section available to add necessary information. |
| 8 | New Client record that populates into Client processing system should trigger a queue notification to the assigned Accounting Rep. |
| 9 | New Buyer records must be input to parent record system (authoritative data) by Data Team. This must happen as part of any new booking entry where a Buyer doesn't already exist in system. |
| 10 | One client profile – Contains the authoritative data (speakers, music, talent, KLUTCH etc.) |
| 11 | No need for secondary files that agents fill out - agents complete client team and commission % on the client profile and can make updates if it changes |
| 12 | Box/DocuSign digital forms- no hand written forms or personal information emailed |
| 13 | Data Repository on the client record (assistants too much turnover) |
| 14 | Acct Rep access to update records once client is established (approvals needed for financial information) |
| 15 | Client access to directly update their banking |
| 16 | Client payment portal perhaps via client processing system (show open invoices; can pay by credit card if need) |
2. Data Team
| No. | Requirement |
|---|---|
| 1 | Ideally CRM/Deal Management could be first option for Agents/Assistants to route/funnel requests to update and/or add data to client, buyer, or participant records. Slack notifications opening a request could be secondary option. |
| 2 | Slack / Trigger notification to Data Team of record needing changed. This should push forward to populate a Data Team queue in parent record system. |
| 3 | Need to accommodate record change requests via Outlook to Data team. |
| 4 | Need to accommodate record changes stemming from the Client card and stemming from the Booking system. |
| 5 | Once record is updated, notification triggered to requestor and appropriate recipients. Ie "This is complete" and “Change to: / Changed from:” |
| 6 | System that owns parent data needs to hold Client, Buyer, Participant(s) records. |
| 7 | Clarifying questions, or requests for additional information upon a change to a record request should funnel through the system with a paper trail. This should be reflected in the client, buyer, participant card in Client processing system. |
| 8 | SalesOps/Client Payment Processors should have access and authorization to amend client/buyer/participant cards in Client processing system. This should trigger a notification to Data Team for a secondary level of review. |
| 9 | SalesOps/Client Payment Processors should have editing capability with trigger notification to Data Team to review. |
| 10 | Any update to records by Acct Rep in the Client processing system are to expedite payment, so the trigger to Data Team must not cause delay to payment process, but we must consider control aspect of Data Team review and how they are notified. |
| 11 | When the case/change request to record is completed, system should notify requestor of completion. See above #5 |
| 12 | Updates to banking information should be verified systematically and carried out by Data Team. |
| 13 | Ideally Data Team owns two queues. Onboarding notifications and changes to existing records. |
| 14 | Added participants to existing Client records to prompt a notification downstream to Accounting Rep. If this participant is only earning commission on certain deal types, that must be denoted in the change request/note field. Then Acct Rep can cross-reference to add the participant to the appropriate bookings. |
3. Booking Entry and Management
| No. | Requirement |
|---|---|
| 1 | Agent/Asst capability to enter deal (Pending/Confirmed/Cancelled status) from booking card/form in Booking System (CRM/Deal management). |
| 2 | Booking Slip status triggered to Accounting (within Client Processing System). Status to include Pending, Confirmed, Cancelled, Cancelled with Payment. |
| 3 | Booking Slip system information should funnel through populate a Booking Card in Client Payment Processing system. |
| 4 | Booking information populating Client Payment Processing system to include: Client, Loanout, Guaranteed Compensation with corresponding milestones, Contingent compensation (i.e. overages, buyouts, bonus etc.) Commission Rate, Booking Agent/Booking Team, Third Party participants, buyer name, buyer address, buyer contact information, Compensation notes, Invoicing contact information and notes. |
| 5 | Compensation and contract details to auto populate on booking card in Client processing system upon estimated confirmation from Agent/Asst inputting within the Booking Slip System. |
| 6 | Compensation milestones to be reviewed by Acct Rep and set up on receivables lines Client processing system. |
| 7 | Accounting capability to edit wording on milestones. |
| 8 | Accounting capability to edit service dates, compensation against guarantee (not to exceed guarantee). |
| 9 | Client Processing System to include drop-down category for monthly Verification Status exercise (Verified, Unverified, Write-off, TBD) |
| 10 | Client Processing System to include note section on line level of compensation. AR notes, Collection notes, Invoice notes. |
| 11 | Changes to bookings (comp, contacts, dates, status etc.) must funnel through to client processing system. These changes must populate the queue for Acct reps/SalesOps to review and work off of. |
| 12 | Dynamic reporting to include, Client Gross earnings, Client commission paid, Client AR aging, Gross paid to participants, Client statements by booking or bookings, any loan reporting with payout schedule, |
| 13 | Each department (Talent, TV Lit, Music etc.) requires to have their own booking code/departmental code that populates within the record upon entry. This is essential for dynamic reporting. |
| 14 | Each booking should require an Occupation Code to be input on new booking entry. This will help with avoiding issue with cross-departmental booking(s). Leveraging Occupation code for layers of data to pull dynamic reporting. |
| 15 | Acct Reps/Sales Ops require visibility of clients open AR cross-departmentally. |
| 16 | Payee splits are determined by master client record |
| 17 | Salesforce or something similar tracking opportunities and can pull in booking with contracts/ redlining accessible. Acct Reps must have access to Booking Slip system. |
| 18 | Booking Entry Templates in Deal Management to Auto populate by department |
| 19 | Change Requests are tracked in system (not relying on email) |
| 20 | Buyer/Production contacts listed on booking so we can chase money (i.e. Invoicing contact above) |
| 21 | Flag when the deal is confirmed - trigger for booking entry down to client processing system. |
| 22 | Agent/Assistant enters the deal in Booking system. That record flows through to Client processing system and populates the Acct Reps queue for their review and set up. |
| 23 | System must have capability to allow Agent allocations (Booking Agent, RA, Agent team) To further explore with FP&A / Agent group. |
| 24 | No more confidential deals. All deals should be considered confidential. |
| 25 | Ability to account for deals booked in a foreign currency. |
| 26 | Buyer data should be uniform |
| 27 | Profits participation tracking - statements and dates –emails. High level of granularity. |
| 28 | Package tracking. If a Booking becomes a UTA package, must be denoted on the Booking record then reflected in the Client processing system. High level of granularity. |
| Packages and Overalls tracking and processing | |
| Packages and Overalls rebate tracking and processing | |
| 29 | Attach contracts and statements to deals that can live within client processing system. |
| 30 | Deal analysis by buyer for negotiating leverage |
| 31 | Capability to export bookings/earnings into Power BI if a more dynamic form of reporting is desired. |
| 32 | 1099 reporting capability required. |
| 33 | Ability to mass upload bookings –NS functionality currently |
| 34 | Subsidiaries |
| 35 | Role assignments within the Client processing system. (Ie Cash Receipts, Acct Rep etc) |
| 36 | Linking packages - Package bookings have a hierarchy. (Parent Booking, so on and so forth) (MSW to expand) |
| 37 | Linking of projects |
| 38 | Occupation code definitions available for Acct reps to review. |
| 39 | Further to #11: FP&A Requirement: Dynamic reporting capability to view changes to booking compensation on all bookings, this should be inclusive of changes in service dates as well. This should be readily available monthly. Daily is more ideal. |
4. Cash Receipts
| No. | Requirement |
|---|---|
| 1 | Cash receipts require a queue/list that comprises all incoming electronic payments and physical checks received by Lockbox (Unassigned/New/Applied). Client processing system requires full integration with banking platform that pulls this information periodically throughout the day. |
| 2 | Cash receipts require working off of a deposit portal or deposit queue that is populated throughout the day upon receipt of new payments to UTA bank(s), electronic payments (ACH/wire), physical checks, credit card or otherwise. |
| 3 | Deposit queue needs to account for all accepted currencies of incoming wires to UTA. |
| 4 | Deposit queue should be easily sorted by currency, date etc. |
| 5 | Deposit queue should allow for assignment of a UTA client, booking number, or invoice to match. |
| 6 | Deposit queue should allow for a notes section for any pertinent information from Cash Team/Acct Reps. This will assist with wire/ACH assignment. |
| 7 | Deposit queue listing Incoming/Unclaimed wires should be easily distributed to Agents/Assistants or at a minimum, accessed for assistance with claiming and assigning the funds. |
| 8 | Deposit queue needs to be visible within the Booking slip system to enable Agents/Assistants to have access and ability to assist with assigning funds. |
| 9 | Incoming checks from UTA Lockbox should contain the check back up in PDF form. This should live with the deposit record systematically through the life of the funds within the Client Payment Processing system. Clients and business managers request this back up. |
| 10 | Cash receipts need ability to post/apply funds to bookings or client. Does not need to have an invoice to match. |
| 11 | Cash receipts need ability to split deposit funds across multiple clients or multiple booking lines. |
| 12 | Cash Receipts/Acct Reps to have capability to transfer funds across Clients/Client Bookings. Use case example: It is discovered that funds were incorrectly applied. Or also it is discovered that a portion was due to a separate client unbeknownst to the Cash receipts/Acct Rep. |
| 13 | If funds are sent to UTA incorrectly, processors must have the ability to indicate to Cash team that funds be returned to sender. |
| 14 | Client processing system needs to speak back to the Booking slip system to reflect any funds deposited/applied to a booking record. This acts as a proof of payment and notification to Agent/Asst that payment has been received. |
| 15 | Acct Reps should have view only access to bank account to reference incoming wire/ACH funds to assist with the deposit application process. |
5. Invoicing
| No. | Requirement |
|---|---|
| 1 | Systematic request capability. Stemming from Booking system, Slack, or otherwise, to an accounting queue that lives within the Client Processing System. |
| 2 | Explore possibility of having a separate queue for Invoicing requests that stem from Agents. |
| 3 | Assistants need capability to generate an invoice from the Booking slip system. This generated invoice needs to stem to the Client processing system. (This must not hit anything within the General Ledger, as this is merely for billing record purposes). |
| 4 | Invoice requests should contain client, booking number, milestone(s) to be invoiced, compensation amount(s) also to include VAT where necessary. Consider any additional EU requirements for payment. |
| 5 | Acct Reps to open the booking slip detail that contains the booking milestones and guaranteed earnings, wherein they can select a line or multiple lines to invoice. |
| 6 | Acct Rep should be able to generate invoice records from multiple areas within the Client processing system. Ex. If an employee is in a settlement screen and they get tasked with creating an invoice, it should be as user friendly as possible (select AR line, point and click invoice) |
| 7 | If further information is required, communication via the Client Processing system to the requestor (agent/asst) in a dialogue can be tracked, stored and referenced at a later date. |
| 8 | Invoices should be systematically distributed to the buyer contact or invoicing contact denoted in the booking card. That information is pulled from the booking card/booking record. |
| 9 | Invoice record should live on the line level (milestone or milestones) of the booking card and accessible in perpetuity. |
| 10 | Invoice function should allow Acct Reps to select buyer invoice or client invoice. |
| 11 | Client processing system should host invoicing templates that are dynamic and editable (Use case: In UK buyers may require a Guarantee invoice to "originate" from the Client). (ex. Buyer invoice/Client invoice) |
| 12 | Buyer invoice reflects earnings due to Client. |
| 13 | Client invoice reflects commission owed to UTA. |
| 14 | Invoice function should automatically select correct UTA bank/wire details based on the currency in the booking record. If different currency is required, Acct Rep needs to coordinate with Agent's office to amend the booking currency. |
| 15 | Invoice should contain the Acct. Rep email information in the event of questions. |
| 16 | Invoices should be editable/flexible. |
| 17 | When an adjustment to an invoice is made, it should have no effect on the General Ledger. |
| 18 | Invoices are not required to apply and process funds. However, they should be autogenerated and closed once payment is posted in the system. |
| 19 | Acct Rep to have capability to invoice one or multiple lines of AR |
| 20 | Open discussion with IT on Buyer self-serving invoicing process. |
| 21 | Column/Field indicating # of days has passed since invoicing. |
6. Client Payments
| No. | Requirement |
|---|---|
| 1 | Client processing system should host a queue that is user centric. This will be their working "to-do list". This contains information such as new confirmed booking, invoice requests, requests to pay etc. This should be easily sorted. |
| 2 | User queue should also reflect client booking milestones that have now come due. This prompts the processor to either pay out (if we have money), inquire to invoice, or follow-up with buyer/agent on status. |
| 3 | If UTA receives money and funds are cleared for an exercised milestone where services have been rendered, processor should proceed with payment. |
| 4 | System should generate a pre-settlement statement that can be reviewed by Agents/Asst/Client Team members prior to payment going out. This is discretionary by Agent office. Some wish to approve all payments prior to funds going out to Client. |
| 5 | Settlement work that Acct Reps generate should live in draft form until they submit in an actual batch of work to be reviewed/audited by Acct Mgr. and Cash Team. |
| 6 | Payment capability for all participants that are active on the booking record. This includes third parties such as Managers, Lawyers, Business Managers, co-agents. |
| 7 | System must allow for pass through (commission free) funds to be paid to parties such as buyers, clients or vendors. |
| 8 | System must allow for any buyer overpayment, that is recognized, to be paid back to the buyer. Buyers can be set up as an overpayment/reimbursable participant on the booking record. |
| 9 | Client payments can be submitted as a batch of 1 or multiple payments. Wherein multiple clients/bookings are paid within the same batch. |
| 10 | The batched Commission, once posted, should post/transfer to the Commission account automatically. |
| 11 | Batches of settlement/payments should include a batch summary journal detailing the prepared settlements. |
| 12 | Batches of settlements should include the incoming payment (Deposit) remittance back up pulled from the PDF that originates in the Cash Receipts queue. (Deposit records follow the funds record through the entire order-to-cash process). |
| 13 | Batches of settlements are to be systematically sent to a accounting manager for first round of audit approval. This should be triggered by systematic notification to accounting manager. |
| 14 | Batches of settlements are to be systematically sent to a Cash Team member for a secondary round of audit approval. This should be triggered by systematic notification to Cash Team member. |
| 15 | Fully approved batches to be released for payment by Cash Team member. |
| 16 | Fully approved batches released should systematically provide remittance/payment back-up to all members on Client team wishing to be notified. |
| 17 | System should allow for client commission to be withheld from multiple bookings. In this scenario, processor would obtain approval from Client team to recoup UTA commission from existing funds being held in trust for that particular client. |
| 18 | Pre-settlement Statement should summarize the breakdown of payment. This should be line level detail such as Client name, Client Loan out, Client Address, Booking name, Service date, Milestone detail, Gross, Commission rate, Commission paid (UTA and any other participants) and Net to Client or payee. |
| 19 | Pre-settlement Statement should allow for settlement notes to be input by processor/SalesOps. This can provide any additional clarifying information that isn't typically included in the line level detail. |
| 20 | Remittance/Statements to populate Client's portal (or equivalent) platform upon payment being released to client. |
| 21 | System to account for Auto Debit Clients that get commission payments automatically deducted. Ideally those tie out automatically when applied and populate a settlement batch for review. Auto Debit Clients must authorize their accounts to be debited for commissions owed to UTA. |
| 22 | Batch settlements can include commission rebates or commission reimbursements to clients within the batch. This should be systematic in that there would be no manual movement of cash. |
| 23 | Ability to process cash out of other UTA accounts, wherein if Acct Rep needs to pay from separate account, this triggers an internal transfer across bank accounts. (ASK MATT) |
| 24 | Capability to process and apply Direct Commission payments directly to the open AR item and input into an open batch. |
| 25 | Direct Commission defined: Incoming funds from Client or Buyer that account for only UTA's commission portion. |
| 26 | Client processing system should provide DCA compliance / audit compliance and readiness. |
| 27 | Client processing system should have capability to differentiate and set segregation of duties between Cash Receipts team and Acct Reps. |
| 28 | Capability to issue a Client Loan or Client Advance and code it as such for recoupment purposes. |
| 29 | Client loans or Client Advances should be accompanied by a promissory note generated by Legal. This should be stored on the Loan or Advance record for Acct Rep to reference and set up recoupment plan. |
| 30 | Capability to withhold funds for tax purposes. Or account for CWA (Central Withholding Agreement). |
| 31 | Integration for Client booking records with Concur. This can accommodate any Agent expenses that need to tie back to a booking record. (i.e. Travel, shared commissions, misc. expenses). These funds to be recouped from either Client or Buyer and tie out with the Concur system. |
| 32 | Capability to flag a Client Hold. Client Hold defined: UTA is holding on processing any funds to client or commission until notified by Agent. |
7. AR & Bad Debt
| No. | Requirement |
|---|---|
| 1 | Acct Reps require capability to see open AR at all times for the clients and/or bookings they manage. |
| 2 | Acct Reps to have capability to sort AR dynamically: By Agent, By Client, By Dept etc. |
| 3 | SOPs/Processors require capability to run their own AR aging reporting for review with Agents and assist with collection efforts. This should be a standard report. |
| 4 | Communication to Agents/Assts from the Client processing system directly from the booking record/receivable in the system. |
| 5 | Compensation line items require a field for the following: Booking Verification Status and Collection Notes. |
| 6 | Capability to access original invoice and redistribute to receiving parties (buyers, clients, participants). |
| 7 | AR line items to include a column/field for "Last followed up date" |
| 8 | If SOP's/Processors inquire to write-off an AR item, they should be able to inquire directly to Agents/Asst from the Client processing system to start the approval process. |
| 9 | Write-off functionality. Defined: This can be flagged within the Booking system to flow through and be reflected in the Client processing system. |
| 10 | AR items that have been coded/categorized as Write-Off should funnel through into dynamic reporting that can be pulled at any time for revenue department to review. |
| 11 | The write-off process requires dual approval. 1 from Agent group and 1 from F&A group. Preferably the approvals and communication are stored within the Client processing system. |
| 12 | Automated journal entry population. |
###8. Revenue Recognition
| No. | Requirement |
|---|---|
| 1 | Client processing system to host a Verify Bookings tab that will allow SOPs/Processors to conduct their monthly verification process on open AR. Verified bookings defined as services rendered and money is due to UTA. |
| 2 | Client processing system to have capability to pull an ARM type report quickly at any time. ARM defined: Automated Revenue Management |
| 3 | Trend reporting in Revenue. Reflect which seasons are busier across the multiple departments. |
| 4 | Trend reporting capability to be exported into Power BI for FP&A and/or Revenue Department for more dynamic reporting. |
| 5 | Flywheel reporting. Defined: Acct Reps home dept vs other departments. |
9. Offboarding
| No. | Requirement |
|---|---|
| 1 | Upon client departure Agent/Assistant flags in master data record. The change is reflected in the Booking system and also Client processing system. Marks "Departed" |
| 2 | This change from master data record should record a change notification within the client processing system so Acct Reps can reference the date of departure for tracking. |
| 3 | Departed clients with protected UTA bookings should be updated in the Booking system and then reflected down to the Client processing system. Protected defined: UTA is still commissioning the deal. |
| 4 | Mass removal capability of participants from bookings (ability to keep them on some; i.e. Backend) |
10. Glossary of Terms
| Cash Receipts | Team member that is responsible for incoming funds to UTA as well as the releasing of outgoing funds to clients and participants |
|---|---|
| Participant | Any party that is to be included on a client booking record and receive a disbursement. Commission or otherwise. |
| Acct Rep | Team member that manages the booking process from Accounting. On CTA this is currently SalesOps (SOP's) and on Touring this is currently Acct Rep. |
| Booking slip/record | This is the digital deal file that is generated by the Agent's office and reflects the deal terms and compensation for the client. |
| RA | Responsible Agent |
| Data Team | Team member that owns the onboarding process and data management process. |
| Verified | Services have/will be rendered, and revenue is due. |
| Unverified | Have not determined if services were rendered. |
Appendix B – Commentary on Appendix A Requirements
The finance team’s work on breaking down the key processes of client processing and the go-forward requirements will be an invaluable reference. Given the proposed solution in this document, some observations:
| Category | Commentary |
|---|---|
| Onboarding | “Onboarding” and “Offboarding” should now be considered discrete business processes with their own stakeholders and requirements, yet they should take advantage of the components that are in scope. We need to take a longer look at these processes because there appear to be other parties at UTA that have their own onboarding needs, including Legal/Compliance, IQ, UTA Foundation, and others. We’ll need to take their ideas into account. Onboarding and offboarding both have authoritative data connections. Some of the requirements described in “Onboarding and Offboarding” are obviated by some of the features of authoritative data. It is understood that a major part of onboarding provisions core financial information in client processing (banking, commission rates, participants, etc.) that are required to complete transactions. |
| Data Team | Many of the requirements described here are obviated by some of the features planned for authoritative data, particular around the responsibilities of the Data Management Office (DMO) which works with business stakeholders on managing authoritative data, and around the notifications to downstream systems of changes. There is one principle in authoritative data that is entirely in alignment with the original finance requirements in Appendix A: authoritative data scope is limited somewhat by focusing on core entities (client, buyer, participant, venue, and so on) and the relationships between them. Of particular interest to authoritative data are data that are needed across CRM and finance domains. This means generally that data that is governed entirely by finance (for example, banking details) should be controlled “locally” by finance in a finance-centric system like client processing, without a need for central stewardship by the DMO. However, it is critical that the creation and modification of the core entities continue to be stewarded by the DMO, as they are shared globally within the agency. |
| Booking Entry & Management | Many of the data elements described are in scope for the authoritative data, and some of the other requirements involving the “booking slip system” now translate to the CRM systems that are going to be configured by Tech in response to specific department workflows. Some of the requirements described here (e.g., “package tracking”) are part of deal management: extremely important to build deal management to handle legacy package deals. |
| Cash Receipts | No commentary here, other than to say, we propose finance and tech discuss some possibly innovative approaches to handling invoicing and payment processing (discussed in the main section of the document above). |
| Invoicing | See Cash Receipts above. |
| Client Payments | No commentary here. |
| AR & Bad Debt | No commentary here, other than anywhere we refer to “compensation line items” we should talk about “deal management” as described above. |
| Revenue Recognition | No commentary here, other than we do note that many of these requirements require a strong financial reporting capability |
| Offboarding | See “onboarding” above. |
Appendix C: Client Processing Scope drilldown
The client processing application is the primary focus of our scope. We should expect client processing to be essentially a standalone application hosted by UTA, running independently of NetSuite or any of the department CRM systems, though it connects to these and other systems through well-defined, standardized interfaces.
We understand that many readers of this document are entirely familiar with the client processing process, however we do want to fully identify the proposed scope. Please refer to Appendix A for detailed requirements recently gathered by the finance team.
If we “zoom in” to the client processing application, we see that it supports the following activities that should be considered part of our scope:
- Internal interfaces. Client processing will connect to internal UTA systems such as CRM applications, deal management, authoritative data, and the accounting system, as described earlier.
- Booking Management. As bookings arrive from the CRM systems and are processed by finance, various modifications and adjustments to the booking can be made here. These modifications would likely be made in deal management (discussed below) so the CRM systems would pick up the changes in real time. In addition, changes originating in the department CRMs should trigger notifications to the client processing system, and vice versa.
- Cash Receipts. This involves receiving incoming cash and applying it to the correct bookings. This requires a near real-time connection to the banking platform.
- Invoicing. We generate invoices to buyers on behalf of our clients, and we also generate invoices to our clients for UTA commission. Some of the invoices are “automatic” based on a milestone or payment schedule, and some are by request to accounting representatives. And some invoices are generated systematically and closed at the time payment is applied, to keep an accurate billing record. The client processing system must handle all the invoicing scenarios.
- Client Payments. This work is generally dependent on a detailed review by an accounting rep and a two-level audit and approval workflow in the finance department to ensure that clients and participants are properly paid. Once approved, payments are sent out through the client payment system to the client and participants.
- AR & Bad Debt. The features here center around collection tracking, reporting, and proper approval and execution of write-offs.
- Revenue Recognition. The agency must record revenue accurately and timely. Proper revenue arrangements originating in the client processing system will ensure this process is reported and reviewed effectively.
- External interfaces. There are several connections to systems outside UTA that would clearly be a part of client processing: interfaces to banks and payment providers.
Appendix D: Deal Management Scope drilldown
Currently, the deal terms of the booking are generally not captured completely in our systems. Instead, the terms are often summarized to a simple text box in a booking form, with a provision to upload the actual contract between the buyer and the client as an attachment:
We propose that the agency generalize a capability for breaking the deal into its parts into something called deal management. Tech is beginning this process with touring deals, however, to be truly effective we must account for as many different deal structures, or deal types, as we can.
Granular access to deal terms will enable us to perform more sophisticated analysis on our financial transactions, to compare profitability of some deals with others, and to provide our sellers with “comps” about deals done before that match given scenarios.
Over time this would also help us move away from relying on “off-system” methods (people) to remember and track variable compensation bonuses that our clients may be owed.
This will take some time to build out, but we can work on one deal type at a time and build up our deal management capabilities incrementally.
A typical sequencing with deal management would look like this:
Appendix E – Design Tenets
We have two core design tenets:
- UTA takes full ownership for operating its marketplace. This means UTA creates “stickiness” in every area we can, by having our clients and buyers work directly with our systems. This means that as much as we can, we will avoid handing over relationships with our clients and business partners to third parties.
- UTA will build its capabilities in a modular fashion, so that each building block of the overall enterprise system can be independently enhanced, maintained, operated, or replaced.
Appendix F: Problem Impacts
The following table identifies the areas impacted by these problems based on the following categories:
- Revenue: Impacts client management, evaluating agent performance, and reported earnings.
- Efficiency / Cost: Causes non-value-added effort or additional costs.
- Scale: Inhibits growth of the business or complexity of deals.
- Risk: Creates operational, financial, or controllership risk.
- Stakeholder Experience: Negatively affects clients, participants, agents, or financial operations.
| Problem Statement | Revenue | Efficiency | Scale | Risk | Experience | Primary Stakeholder Group |
|---|---|---|---|---|---|---|
| Cumbersome steps and limited flexibility disrupt cash flow and reduce client satisfaction. | ||||||
| Time between cash receipt to distribution is too long. | X | X | X | Clients | ||
| UTA's cash application process is overly complex and inefficient. | X | X | X | Clients Agents | ||
| UTA lacks sufficient options for receiving buyer and client payments. | X | X | Clients Buyers | |||
| Inconsistent and unreliable data on key stakeholders disrupts client service, wastes time, and hinders decision-making. | ||||||
| UTA lacks accurate and authoritative data about clients, buyers, and business partners, costing time, money, and lost opportunities. | X | X | X | Clients Agents Operations | ||
| UTA’s client onboarding and offboarding processes are ineffective. | X | X | X | Clients Agents | ||
| Inadequate tools and processes lead to revenue loss, inefficient financial management, and inhibit scaling. | ||||||
| Manual revenue tracking is effort-intensive, error-prone, leads to lost revenue, and delays cash receipts (if collected at all). | X | X | X | X | Clients Agents Operations | |
| UTA lacks effective tools for generating accurate forecasts and tracking performance. | X | X | Operations | |||
| Financial reporting is highly manual. | X | X | Agents Operations | |||
| Disconnected systems increase costs, security risks, inefficiencies by limiting real-time visibility and data access. | ||||||
| UTA cannot provide real-time visibility into booking data changes for agents and client accounting team. | X | X | X | X | Agents Operations | |
| Lack of visibility into pending deals hinders accurate forecasting. | X | Agents Operations | ||||
| UTA’s reliance on ad hoc integrations raises costs and security risks. | X | X | Clients Operations |