The AI StudioSample engagement · what we build
Sample · Client details anonymized
The AI StudioSample engagement · what we build
Sample · Client details anonymized
The second statement of work. It finishes the other 43 of the 57 and turns the Studio from a very good analyst into an operating platform: agents that belong to each department, automations anyone can build in plain English, and approved actions inside your own systems with a receipt for every one.
The 37 remaining opportunities, plus the three capabilities that make them operable: department agents, plain-English automation, and approved actions in your systems.
Four delivery weeks, with integrated acceptance on your instance and your owners in the room in the last of them. It picks up where Statement of Work A finishes, on the platform that engagement already delivered.
The Studio starts doing, under one pattern used for every action, every time - and never outside the named catalogue in Annex B.
The price is $300,000, the same as the first engagement, which puts the whole 57-opportunity program at $600,000. Everything that follows is the detail behind it. Section 08 is the part most proposals leave out: the four things we could have described more generously and chose not to.
Six finance workflows from the remaining list were absorbed into the first engagement at no charge, because the data they needed was already connected and building them there was cheaper than scheduling them here. This document delivers the other 37. Any of the six not finished when this engagement starts simply moves into it at no extra cost - the arithmetic ends at 57 either way.
The line is drawn capability by capability, so a technical reader on your side can check it rather than take our word for it.
| Capability | Yours under Statement of Work A | Added by the Full Studio |
|---|---|---|
| Questions and outputs | Ask across systems, inspect the sources, save documents, spreadsheets, PDFs and web pages | Recurring operating packs with data checks, comparisons, approval, distribution and exception handling |
| Memory and projects | Personal, project and company memory; standing instructions | Versioned workflow assumptions, reproducible runs, shared template libraries, retained decision history |
| Agents | Save an assistant with instructions and approved data access | Build, test, version, publish and operate multi-step agents with typed tools, approvals and run history, per department |
| Automation | Scheduled jobs and recurring emailed reports | Plain-English automations that wait for approvals and events, recover from failures, and verify the downstream result |
| Permissions | Sign-in, groups, division scope, per-user document access built and ready to switch on | Action-specific authority and business approvals layered on those controls |
| Changes to your systems | Read-only by design; saving and exporting | Named actions in the spend platform, the ERP, the operations database, advertising and event systems - each with preview, approval, execution and read-back |
| Models | Routed across providers behind the scenes | Your choice of provider where it matters, with approved provider policies and workflow-level routing |
| Your team's own work | Approved instructions and templates | Named scripts, models and tools brought into a maintained, tested runtime with an owner |
| Presentation | Polished documents, spreadsheets, decks, PDFs and pages | Interactive analytical artifacts, reusable dashboard and report templates, managed recurring publication |
Someone who is not technical describes a recurring job in plain English and it runs. “Every Monday, pull the weekend counts for every show on sale, compare them with the same act’s last tour at the same days out, flag anything more than ten percent behind, and send it to me and the COO.”
Under Statement of Work A the Studio can schedule a report. This adds the rest: steps that wait for a person’s approval where money or an outside system is involved, steps that wait for an event such as a settlement landing, recovery when a source is down, and a check that the downstream result actually happened. Each automation shows its next run, its last run, and what it did.
Each division and the executive team get agents that know their world: their data, their conventions, their vocabulary and their approvals. A booker’s agent knows the venue history and the offer template that division uses. The subsidiary’s agent knows the Monday settlement cycle and the box-office fields. The executive agent knows how leadership likes a briefing shaped.
Power users build and version these in the Builder; everyone else just uses them. Shared knowledge such as venue records is shared deliberately. Private conversations and restricted financial records are not.
The platform stops only reading and starts doing - under a single pattern used for every action, every time:
| Step | What happens |
|---|---|
| Propose | The agent drafts the exact change and its reason |
| Preview | You see the fields, the target and the amount before anything moves |
| Approve | The right person, by business authority, not by seat |
| Execute | Once, with a duplicate-prevention key |
| Verify | The result is read back from the system |
| Receipt | Who, what, when, and how to reverse it, in the audit log |
Changing a proposed action invalidates its approval. A failed action is told apart from one that succeeded but timed out. Reversal is specific to the system: a filed report can be restored to a prior version; an ad budget can be reset but spend already incurred cannot be undone; posted accounting records are corrected by reversal, never deleted. The first catalogue of actions is finite and named in Annex B. Your contractual approval and financial posting rules continue to apply.
Cash and working-capital forecasts, audit support packs, three-way settlement reconciliation, forecast variance, margin explanations and a reproducible scenario model, all in one saved workspace. The arithmetic runs in versioned code with saved inputs; the model explains the result rather than inventing the math.
“Prepare the settlement, reconcile the documents, show me what needs approval, and send the approved result to the next system.” One visible job tracks collection, missing inputs, review, the approved action and its verification.
Turn an existing script or model into a supported tool with test cases and a chosen provider, attach it to a workflow, and publish it to the division that needs it.
Interactive dashboards and reusable report templates, published on a schedule to the people who should have them.
The evaluation numbered 57. Statement of Work A covers 14, and six more finance workflows were absorbed into it at no charge. This document delivers the 37 below, plus the broader slices carried forward on opportunities already counted once.
| Outcome package | Opportunities | Count | What changes |
|---|---|---|---|
| Cash and working capital | F7, F8 | 2 | A maintained thirteen-week cash forecast and artist-level working-capital forecasts, with traceable assumptions |
| Ticketing operations and decisions | T1, T2, T4, T5, T6, T7, T8, T9, T10 | 9 | Feed monitoring, counts history and show setup, daily pacing and profitability, sold maps outside the primary vendor, an email assistant, and supervised price recommendations |
| Marketing intelligence and execution | Mk1, Mk2, Mk3, Mk4, Mk7, M1, M2 | 7 | Reconciled conversion evidence, approved advertising actions, usable audiences, spend and velocity analysis, and an operated search-marketing handoff |
| Booking intelligence and learning | B2, B4, B5, B7, B8, B9, B10, B11, B12 | 9 | Shared venue knowledge, better offers and routes, ancillary scenarios, demand underwriting, a reproducible Monte Carlo model, and feedback from decisions back to outcomes |
| Event operations and service | EO2, EO3, EO4, EO5, iEO2, iEO3 | 6 | Settlement packs, production template review, the contractor and tax-form workflow, venue and mileage integration, customer assistance, and specialist phone payments |
| Cross-system workflow | WA1, WA2, WA3, WA4 | 4 | Ad packs, continuous document intake, the three re-keying chains removed, and approved event creation in the subsidiary |
| Total | 37 | Plus the carried-forward slices: the full advancing repository, legacy venue seeding, and the completed learning measures on the marketing rollup |
A row counts as delivered when a named owner on your side has run the workflow and accepted the result - not when it is technically reachable in a chat window. Every row’s acceptance condition and the input it depends on are in Annex A.
Four streams run in parallel from the day we start.
The agent runtime, the automation builder, interactive artifacts, and the one shared action service described in section 02.
Cash and working capital, reconciliation, forecast variance, margin explanation, and the reproducible scenario model.
Venue knowledge, routing, pacing, profitability, settlement and production workflows.
Advertising actions, the venue hub, the counts platform, the box-office and legacy-records interfaces, and the phone-payment specialist.
Each stream has a delivery owner on our side and a business acceptance owner on yours. Integration discovery with every partner starts in the first week, not in the phase where it is demonstrated. Where a supported export and import fully automates a workflow, that is an acceptable route; replacing a missing integration with manual re-keying is not.
Approved instructions and templates; typed remote interfaces; and reviewed, versioned scripts or models. The named tools included are inventoried before signature. An arbitrary personal chat session is not automatically an importable agent - saying so up front is cheaper than discovering it in week six.
Four delivery weeks, with integrated acceptance and handover in the last of them. Start whenever you like - starting sooner only means the extended build is ready sooner. It builds on the platform Statement of Work A delivered, so day one here is not day one of an integration.
| Window | Demonstrable result |
|---|---|
| Week 1 | The action engine and agent runtime; feed watchdog, daily counts with pacing, document intake, offer scaling, operations-database-to-counts-platform setup, marketing exceptions, and the search-marketing handoff live |
| Week 2 | Venue knowledge and routing, counts history, tour-over-tour analysis, settlement assembly, production review, ad packs, the reproducible Monte Carlo model, the advancing repository |
| Week 3 | Cash and working-capital forecasts, audience activation, spend and velocity analysis, approved advertising control, rebate and route decisions, the learning loop, contractor workflow, the re-keying chains, customer assistance |
| Week 4 | Price recommendations, calibration records, subsidiary event creation, phone payments with the specialist |
| Final days | Integrated acceptance on your instance with your owners present, replay and recovery tests, documentation and handover |
The same way the first engagement’s are. The ledger that tracks each of the 57 opportunities as built, accepted or adopted stays open to you throughout - you do not have to ask us where it stands.
Several of the remaining workflows need an input only you or a partner can supply. They are listed here by owner, so nothing waits on “someone”, and we ask for each one as its piece of work starts. Each is tied to the acceptance case it affects in Annex A.
| Input | Owner | Needed by | What it unlocks |
|---|---|---|---|
| The cash-control policy: zero-balance subsidiaries, concentration account, targets and minimum transfer | CFO | Statement of Work A | Daily transfer filing moves from “policy not entered” to real files |
| Survey recipient rules: who is surveyed after a show, and on what trigger | Technology or operations lead | Statement of Work A | Post-event surveys issue on their own |
| ERP access to deposits, payments and transfers for the integration user, or an accepted bank feed or export | CFO and the ERP administrator | Weeks 1–2 | The thirteen-week cash forecast and artist working capital (F7, F8); also strengthens audit support |
| The official forecast from the planning module or its accepted export; representative finance packs; the outside auditor’s actual request list and delivery channel | CFO | Statement of Work A | Forecast variance, audit support, settlement review files |
| Reviewed examples of how search-advertising charges should be coded, and a decision on administrative buckets | CFO and accounts payable | Week 1 | Search-advertising invoice coding can be validated - see section 08 |
| The counts platform’s supported import and setup operations | Technology lead, with the vendor | Week 1 | Historical backfill and show setup (T2, T6) |
| A runnable venue-hub interface and its owner, or an agreed replacement plan | Venue-hub owner | Week 1 | Venue hub and mileage grids, routing, contractor pay math (EO5, B5, EO4) |
| Advertising-platform action scope, and owner capacity for approved campaign changes | Advertising-platform owner | Week 1 | Budget management, marketing exceptions, audience activation (Mk2, Mk3, Mk4) |
| Supported box-office and legacy-records interfaces, and a selected, funded phone-payment provider with a delivery slot | The ticketing subsidiary | Week 1 | Event creation, the box-office chain, phone payments (WA4, WA3, iEO3) |
| A named operator for the search accounts and sites, with editorial approval authority | Marketing lead | Week 1 | The operated search-marketing handoff (Mk7) |
| A decision on switching per-person document access on, and the order of divisions | CFO and technology lead | The company-wide rollout | Document-store answers scoped to each person’s own permissions |
An unfinished model or a missing adapter is our work, never a client dependency. A row is blocked on you only when an identified input or approval is required and unavailable while the engineering that can proceed is already ready.
Four things we could describe more generously and have chosen not to. This section is in the delivered document, at this length, in this position.
The ERP integration user can see journal entries on the bank accounts but no deposits, payments or transfers: thousands of journal lines and zero cash movements. A balance snapshot is not a cash forecast, and we will not dress one up as one. We ask for the access in section 06 rather than promising the outcome without it.
Measured against the client’s own historical coding, the larger ad platform’s invoices code correctly 82.2% of the time. Search advertising agrees 0.0%: their team codes those charges to administrative buckets rather than to shows, and only two of twenty-four coded charges carry campaign detail. Until we have reviewed examples and a bucket policy, search-advertising coding is listed for review only, never proposed automatically. A third channel’s 80% rests on four invoices, and is quoted as such.
During the executive beta every system is read through one shared login, so everyone in a group sees the same data. That is right for four executives and wrong for 160 people. The rollout switches it on, division by division, and each person connects their own account as part of that.
The venue hub was an incomplete prototype at the evaluation. The counts platform’s supported operations, the advertising platform’s action scope, the box-office and legacy-records interfaces, and the phone-payment provider all need confirming in the first week. The thirty days become a commitment for those rows when that discovery passes.
Demand underwriting, price recommendations and calibration are accepted on reproducible runs, held-out evaluation and usable uncertainty. We can prove at delivery that the model works; we cannot prove months of future revenue on installation day - and this document does not claim to.
The verification loop from Statement of Work A continues unchanged: we connect and self-check, your named owner verifies against the source, we remediate, your owner signs off. Three states are tracked for every one of the 57 - and only the second one counts toward delivery.
The implementation exists on your instance. This is the state most vendors report as “done”.
A business owner on your side has run the real workflow with real data and accepted the output, or the action and its receipt. This is the one that counts.
Your people use it on an ongoing basis. Measured after delivery, never claimed at it.
All 37 rows in Annex A are accepted against their stated conditions; the carried-forward slices are closed; every new action has been exercised with a representative success and a representative failure; the automation builder and the department agents have been used by your own people to build something that runs; and documentation and ownership records are handed over. Anything not accepted is not paid for.
The same two shapes as the first engagement, at the same price: $300,000, which puts the complete 57-opportunity program at $600,000. The scope, the acceptance conditions and the ownership are identical either way - the difference is only where the money sits and what releases it.
Simple, standard, and the lowest total.
Released by acceptances you sign rather than by dates on a calendar. This option carries a modest premium for spreading the payments.
It covers the implementation and integration program in Annex A, including the specialist deliveries named there, training for the people who will build automations and agents, and handover. Model usage, Studio Care and the server stay as they are today, in your name. Media spend stays yours; approved actions move budgets you already fund, and the Studio never spends on its own. Any partner or provider fee for a supported interface is named before we start.
Invoices are issued when the trigger is met and are due on your standard terms. A payment schedule tied to dates transfers schedule risk to you; one tied to acceptances keeps it with us.
The platform, the code, the agents, the automations, and everything your team builds. The whole platform stays reproducible from a script, on a server in your name.
Every action added by this engagement is named, previewed, approved and receipted. There is no general “write to everything.”
No purchaser name, email, phone or address is available to any Studio user, and no setting can lift that. It is enforced below the application, not by policy.
Studio Care continues at the rate set at signature, with the same response commitments. Day-to-day administration stays with your own administrator, and your advertising engine remains yours under its own contract.
Each row lists the outcome, when a named owner on your side accepts it, and the input it depends on. Delivery windows refer to section 05. Every row is accepted on your instance, with your data, verified by your owner.
| ID | Outcome | Window | Accepted when | Depends on |
|---|---|---|---|---|
| F7 | Maintained thirteen-week cash forecast | Week 3 | Opening cash plus dated receipts and disbursements produce thirteen forward weeks, including artist advances, deposits and prepaids; assumptions persist, the model refreshes weekly, and a known cash week reconciles. | Cash-movement access or an accepted feed (CFO, ERP administrator) |
| F8 | Artist working-capital forecasting | Week 3 | Artist-specific advances, receipts and working-capital release projected onto upcoming dates; backtested on held-out periods; overrides and uncertainty recorded. | F7; complete artist and date cash history |
| T1 | Ticketing feed watchdog | Week 1 | An absent batch, a schema change and a count anomaly are each caught in replay tests; a diagnostic goes to the owner and only approved recovery runs, audited. | Feed manifests and incident examples (technology lead) |
| T2 | Counts-platform historical backfill | Week 2 | The agreed historical window loads, totals reconcile to source, duplicates are rejected, purchaser restrictions are preserved, and incremental refresh is demonstrated. | The counts platform's supported import contract |
| T4 | Dynamic price recommendations | Week 4 | For approved genres and markets, prices are proposed from inventory, velocity and comparable history; historical cases replayed; uncertainty explained; changes routed through the existing booker and artist approvals. | A pricing owner; the comparable set and pricing rules |
| T5 | Daily counts with historical pacing | Week 1 | A daily report to named recipients compares matched shows at equivalent checkpoints, states freshness and coverage, and raises configurable pacing exceptions verified against source. | Comparison rules and recipients (ticketing owner) |
| T6 | Operations database to counts-platform show setup | Week 1 | An approved show confirmation creates or updates the show on the counts platform exactly once, with reconciled dates, tiers and identifiers, and recoverable failures. | Create capability on the counts platform; field mappings |
| T7 | Email management assistant | Week 2 | A user reviews an evidence-backed triage queue and drafts, approves a route, finds the source message, and recovers from a misclassification. No silent relationship decisions. | Mailbox access and triage rules (ticketing manager and selected users) |
| T8 | Internal profitability with ancillary revenue | Week 2 | Ticket revenue plus ancillary economics and non-duplicated costs reconcile to the owner-approved profitability view; external material excludes restricted economics. | Finance and ticketing definitions; a complete ancillary source |
| T9 | Sold maps outside the primary vendor | Week 2 | Current inventories from every in-scope venue format are ingested; sold and remaining reconcile by section and price; age and exceptions are shown; one repeat refresh is proven. | Venue and ticketing feeds or contacts |
| T10 | Tour-over-tour historical feedback | Week 2 | Named current and previous tours produce comparable pacing and final-performance analyses, with the matched-show logic accepted by your side. | T2, or an accepted historical feed |
| Mk1 | Unified conversion evidence | Week 1 | One campaign-and-show view identifies conversion source, attribution window, deduplication and untrackable coverage; totals tie to source. | Advertising-platform owner; campaign, show and ticketing mapping |
| Mk2 | Budget management and dayparting | Week 3 | An approved campaign policy respects daily, lifetime and date-range caps; an approved action, its verification, a pause and a rollback are demonstrated in the agreed account scope. | Advertising-platform action scope and owner |
| Mk3 | Marketing exceptions and visibility | Week 1 | A cross-platform view presents current actionable exceptions on approved KPIs, distinguishes stale recommendations, and shows action outcomes. Marketing can self-serve. | Advertising-platform owner; KPI definitions and account inventory |
| Mk4 | Audience building and activation | Week 3 | Marketing selects an approved cohort, validates size, suppression and consent, and activates or exports it to the supported channel with a recorded round trip. | M1; an authorized activation route and a channel owner |
| Mk7 | Search-marketing operating handoff | Week 1 | A named operator owns the in-scope accounts, sites, measurement and backlog; the initial approved campaign and fixes are live, with reporting and a cadence. | Account and site authority; editorial approvals |
| M1 | Per-artist segmentation and lookalikes | Week 2 | Reproducible artist cohorts with clear rules, stability checks and channel relevance; marketing approves segments beyond simple geography. | Buyer data in approved aggregate form; a marketing owner |
| M2 | Velocity and spend-response analysis | Week 3 | An accepted analysis of pacing and spend response by comparable artist and market; association distinguished from cause; a recommendation tested in an agreed experiment. | Mk1, T5; dated spend and sales; an experiment design |
| B2 | Shared venue and deal knowledge | Week 2 | Users find the approved venue record with specs, contacts, prior terms and provenance; conflicts are resolved by an owner; edits feed one maintained record. | Venue-hub owner; venue identifiers and source owners |
| B4 | Offer scaling auto-population | Week 1 | Selecting a venue and template fills price and scaling tiers correctly, preserves manual holds and comps, and generates the approved offer. | Booker templates and tier rules |
| B5 | Routing, availability and conflicts | Week 2 | An approved tour's candidates produce a feasible route, availability status and conflict list under explicit constraints; booker edits are preserved. | Venue-hub routing; availability and existing-show feeds |
| B7 | Venue rebate and ancillary negotiation support | Week 3 | A named negotiation case compares realized ancillary performance, calculates explainable rebate scenarios, and is accepted by booker and finance. | Validated rebate and ancillary history; a named case |
| B8 | Competitive events and route optimization | Week 3 | Route suggestions flag competing events from documented sources, apply travel, legal and business constraints, and preserve booker approval. | B5; maintained external event data |
| B9 | Artist demand underwriting | Week 3 | A versioned demand model with documented features, evaluated on held-out shows; uncertainty and data-poor cases explicit; bookers review the recommendation. | Ticket history; a booker-approved evaluation |
| B10 | Financial scenarios and Monte Carlo | Week 2 | A saved project reproduces a known result from versioned data, code, assumptions and seed; financial math is separate from demand inputs; scenarios rerun without rebuilding context. | Your team's existing model assets, and their validation |
| B11 | Offer-to-settlement learning loop | Week 3 | Each reviewed variance is retained against offer, venue and artist, and surfaces in the next comparable offer, with its disposition traceable. | Approved settlement records and feedback rules |
| B12 | Human judgment versus model calibration | Week 4 | A booker's prediction or override is recorded before the outcome, compared afterwards, and calibration patterns surfaced - without overruling judgment. | Booker participation; B11 links |
| EO2 | Corporate show-settlement assembly | Week 2 | Artist, venue and co-promoter views generated from approved terms, receipts and inputs; estimate and invoice offsets reconciled; the two-eyes review enforced. | Settlement templates; night-of-show inputs |
| EO3 | Production template reuse and routed review | Week 2 | A show layout template is reused, venue overlay and version tracked, review routed to ticketing, approval and open items recorded. Layout judgment stays with qualified people. | Production and ticketing owners; file formats |
| EO4 | Contractor agreements and tax-form workflow | Week 3 | Approved contractor data and venue-hub-calculated rates produce correct agreements and tax packets; missing data or signatures block completion under finance and HR review. | Venue-hub owner; approved HR and legal templates |
| EO5 | Venue hub and mileage grids | Week 2 | The Studio retrieves the authoritative venue record and produces the correct tour mileage grid through a supported integration; versions, failures and owners are visible. | Venue-hub owner; its interface and routing specifications |
| iEO2 | Customer-service assistance | Week 3 | Routine order and event inquiries are handled in the permitted context; uncertain cases transfer visibly to a staffed human channel with transcript and outcome. | Subsidiary GM; FAQs, order interfaces and a staffed escalation |
| iEO3 | Phone card capture | Week 4 | A customer completes the approved voice-payment flow and returns to the human workflow. Card details never enter the Studio. The provider and your compliance owner accept. | A funded payment provider, telephony access, specialist delivery, compliance review |
| WA1 | Ad-pack generation | Week 2 | The approved template assembles spend, proofs and invoices into a reviewable pack; totals reconcile; a marketer prunes and approves without rebuilding. | Mk1; marketing templates and proof locations |
| WA2 | Continuous document intake | Week 1 | Designated incoming documents are classified, extracted, filed and routed with retry and deduplication; uncertain cases reach an owner; one real recurring cycle passes. | Mailbox source and destination; routing rules |
| WA3 | The three re-keying chains removed | Week 3 | The subsidiary's box-office to legacy-records chain, the Concerts offer chain and the Touring offer-to-contract-and-settlement chain each transfer fields once, with reconciliation and the existing review gates intact. | Subsidiary specialist; the legacy-records interface; division owners |
| WA4 | Subsidiary event creation | Week 4 | Approved parameters create a correct event with tiers, on-sale and configuration; validation, duplicate prevention and a reversible test route proven with the platform owner. | Box-office vendor or engineer; interface and change controls |
Three items were partly delivered under Statement of Work A. The remainder lands here, so no opportunity is counted twice and none is quietly dropped.
| ID | Remainder delivered in the Full Studio | Window |
|---|---|---|
| EO1 | The full advancing repository and venue-ready pack: artist riders, venue specs, attendance and staffing inputs, missing-item flags, and the existing review workflow. Document IV delivers the post-event survey slice of this item; this is the rest of it. | Week 2 |
| B1 | Legacy venue and offer seeding for the complete historical lookup, with provenance kept distinct from offered-versus-settled. Document IV delivers the current-data scope. | Week 2 |
| Mk6 | Complete learning measures and channel coverage on the marketing rollup, as Mk1 and M2 connect. | Across the weeks |
This is the complete list of things the Studio is permitted to change in your systems at the end of this engagement. It is deliberately finite.
| Action | In which system |
|---|---|
| Approved report filing | The document stores |
| Accounts-payable coding handoff | The spend platform |
| Journal drafts and imports | The ERP |
| Selected field updates on offers and shows | The operations database |
| Show creation and update | The counts platform |
| Approved campaign changes within policy | The advertising platform |
| Event drafts, and the specified box-office to legacy-records transfer | The ticketing subsidiary |
Adding an action is a scoped change with its own approval, its own preview, and its own receipt - not a configuration toggle. That is the point of writing the catalogue down.