The AI StudioSample engagement · what we build
Sample · Client details anonymized
The AI StudioSample engagement · what we build
Sample · Client details anonymized
A six-week, evidence-based evaluation of where artificial intelligence genuinely benefits the business - and where it should not be applied - across Finance, Event Operations, Booking, Ticketing, and Marketing.
The front section is designed to be read in about fifteen minutes. The material behind it is supporting reference.
You engaged us to provide a candid, evidence-based evaluation of where artificial intelligence can genuinely benefit the business. This document presents that evaluation. It opens with the executive summary, then the method, the systems and workflow maps we drew, the findings for each operating area in order of interview depth, the baseline measures, the full 57-item opportunity inventory, and a recommended implementation sequence. The evidence was gathered directly from your people, and the findings follow from that evidence.
The items presented are findings, not directives. Where an opportunity is listed, it is because the evidence surfaced it - in most cases more than once, and often unprompted. Where a figure appears, someone on your team stated it on a dated call.
Over six weeks we interviewed fifteen people across your divisions and mapped where AI can deliver genuine value to the business - and where it should not be applied. Three principal findings emerged.
Not “AI could help someday.” 57 concrete, named opportunities, several already carrying figures your own team provided: five to seven hours every Monday on subsidiary settlements; one to three hours a day re-keying box-office data; a full admin-day each month coding ad invoices; two temporary hires already working in accounts payable whose work better tooling makes unnecessary. Every recommendation ties back to a verifiable figure.
Your own staff have already shown what these tools can do. The CFO connected a model to the ERP himself, built a multi-market demand model in a weekend, and caught a genuine posting-date error in the year-over-year numbers. A marketing lead cut a two-hour task to fifteen minutes with a spreadsheet of his own design. What is missing is shared infrastructure: systems whose work persists, that connect to where the data lives, and that turn a proven individual solution into a durable tool for the whole team.
Every interview independently drew the same boundaries: augment judgment rather than replace it; keep a human in the loop on anything that moves money; build systems that retain context; and give every workflow a named owner. Because they came from your people, we present them as findings in their own right rather than as our caveats.
“I don’t want dashboards. I want to ask the question and have it figure out the answer.”
Reporting that can be queried conversationally, memory that persists, and a small number of connectors to the systems that hold the data. The remainder of the findings follow from that foundation.
Nobody systematically compares what an offer projected against what the show actually settled for. Four interviews across three divisions surfaced this independently - booking wants it, finance attempted it by hand and couldn’t keep up, operations checks it by eye, and ticketing’s profitability view cannot see ancillary revenue at all. We recommend scoping this once, as shared reconciliation infrastructure, rather than four partial versions.
Offer automation stays transparent - no black boxes over the bookers’ sheets. Tool changes happen with teams, not to them. No autonomous money movement. No AI in the relationship layer. No AI-generated creative on artist campaigns. And nothing that duplicates what your own builders already have in flight - the in-house work under way in the Touring division was reviewed together, and the roadmap coordinates with it rather than rebuilding it.
We interviewed people across Finance, Event Operations, Booking, Ticketing, and Marketing; mapped the systems each division operates and how they connect; documented the core workflows end to end; and captured the baseline figures each team already tracks. Every opportunity was then evaluated against a single test: how defensible is the return before any investment is made in building it.
Sessions ran from late May through mid-July: a first sizing conversation with the CFO and the data owner, then division-by-division operator interviews (Touring booking, Concerts booking and ticketing, event operations, produced events, marketing planning and execution, settlement, the ticketing subsidiary), executive follow-ups, and a closing working session with finance leadership on governance. Every finding below carries the interview it came from.
Marketing findings are execution-side; the strategy and budget-rationale layer sits with the planning team and was out of scope for this pass. Per-task time baselines for Touring settlement, advancing, and contracting were not captured in this window; where a number wasn’t stated by someone who would know, we left it to be quantified rather than estimate it.
These recurred consistently across the interviews. They are your own standards, and every recommendation in this evaluation assumes them.
Your bookers carry twenty-year track records. AI proposes and flags; a human decides. A demand model that works against the people who know the markets is an obstacle, not a solution.
Anything that touches the books remains under human confirmation or override. Reporting is sequenced first precisely because it is read-only: straightforward to verify, minimal risk.
The single reason proven individual solutions have not reached production is that they retain nothing between sessions. Systems that carry context forward convert a proven one-off into a durable tool.
A process without an owner is not a process that can be automated. Every recommendation assumes a named owner on your side.
The objective is not to move anyone onto unfamiliar tools. Where a change is warranted, the replacement operates the way people already work - the change happens in the plumbing, not the process.
Work begins where results are verifiable and risk is low. Broader, money-adjacent automation is extended only after the pattern has demonstrated reliability.
Capture, don’t migrate. Automation observes and normalizes existing workflows - talent buyers keep their working sheets; working them is how buyers learn deal structure. Admin layer, never the relationship layer. Roughly 90% of one division’s shows are booked with relationship-driven venue partners, and the value is in that relationship. Nothing we recommend inserts a tool between your people and a venue partner, an artist, or an agent.
The whole operating estate on a single diagram - booking and offers, operations and settlement, ticketing and counts, the data spine, finance, and the ticketing subsidiary. The color of each connection tells you its health at a glance.
A great deal already works well. These are the connections that are healthy today - the foundation any future automation should extend rather than replace.
| Connection | Mechanism | Health |
|---|---|---|
| Spend platform ↔ ERP | Live two-way sync | Solid - most expenses auto-ingest coded to show |
| Ticketing vendor → CRM feed → operations DB | API auto-import | Solid - covers ~80% of Concerts shows |
| Ticketing vendor → SQL warehouse | Nightly batch (60M+ rows, 24 hr lag) | Stable - occasional dev fixes, no monitoring today |
| SQL warehouse → BI | Stored procedures | Working - the thin analytical layer |
| Operations DB → automation hub → downstream (show confirmation) | Fan-out: folders, contract, master sheets, ERP, industry database, timeline, Slack | Best automation in the company - venue-fee field + two-eyes check deliberately manual |
| Box-office audits → daily-count platform (Concerts) | Email forwarding + AI parse (~98–99%) | Solid - absorbed a full-time person’s worth of work |
Where two systems don’t talk, a person moves the data by hand. Each row is a recurring labor cost, and each has a clear path to being closed.
| Bridge | Cost today | What addresses it |
|---|---|---|
| Subsidiary box office → legacy database | 1–3 hrs/day manual CSV | The subsidiary box-office integration (PCI-scoped) |
| Subsidiary box office → BI | Daily CSV via a manual script | Rides on the same integration |
| Operations DB → daily-count platform | Template / manual entry per show or tour | Connecting counts to offers |
| Non-vendor venues → sold-map visibility | Manual PDF requests (~20% of Concerts shows) | The non-vendor venue-visibility opportunity |
| Offer sheet → downstream departments (both divisions) | Manual re-keying per department | Letting the offer feed downstream instead of being re-keyed |
| Ad-platform invoices → spend classes | ~1 admin-day / month manual coding | The invoice-categorization opportunity |
| Venue ticket audits → Touring count sheets | Weekly manual pulls, difficult formats | The ticket-audit parsing opportunity |
| Touring daily counts (no counts platform) | Fully manual, 2×/wk (hourly during on-sales) | A change-management conversation on tool adoption |
These are the structural gaps that shape everything else. They are not failures of any team - they are the natural seams between systems that grew up independently. Each is addressable.
Touring - the best back-office automation in the company (the operations-DB + automation-hub chain), sitting above fully manual counts and personal-tool advancing; the spreadsheet culture is both fast muscle memory and a fragmentation risk. Concerts - the most automated counts and the only division fully on the operations database, but offer creation is still manual-lookup-bound and pre-2024 history lives outside every system. The ticketing subsidiary - a separate business with its own proprietary stack and a PCI Tier-1 constraint on every integration; its manual bridges are its single biggest cost.
Where the work starts, how it moves, and what each map makes possible next. Every node traces to something a member of your team told us in an interview; nothing here is an assumed process.
This is how a tour becomes a confirmed set of dates - from a talent buyer sourcing a deal, through leadership sign-off, into a heavy stretch of venue outreach, and out to the departments that execute it. It’s a well-drilled relay; the map shows exactly where the hand-offs and the manual duplication happen.
The two heaviest steps - 600–700 outreach emails per tour and rebuilding the event offer off the tour offer - are exactly the kind of high-volume, template-driven work where assistance pays off fastest, without touching the relationships or the sign-off that make the deal.
Look at what isn’t on this map: no arrow returns from settlement back to the offer. The feedback loop that would let actuals sharpen the next estimate simply doesn’t exist yet - the most consequential missing connection this diagram points to is one it can’t draw.
Once a show is confirmed, one action “kicks the snowball off the mountain”: an automation fans a single confirmation out to folders, contracts, master sheets, the ERP, the graphics timeline, and Slack - then weekly counts flow into the settlement sheet, and nothing leaves without two sets of eyes. This is the strongest existing automation in the company, and it already knows where to stop.
The purple steps - the live venue-fee negotiation and the SVP’s final two-eyes check - are deliberate human checkpoints, not gaps to be closed. This is the core principle in one picture: automation fills in everything around the checks, and never runs through them.
The two weakest links are input-quality problems, not decision problems: parsing difficult venue-audit formats and categorizing venue expenses. Raising the quality of what reaches the settlement sheet makes the reviewer’s job easier while leaving the two-eyes gate exactly where it is.
Advancing is the weeks-out choreography that turns a confirmed show into a smooth day-of: the event manager works the venue through riders, questionnaires, production, and a week-of sweep, staying the relationship holder the whole way. Each EM runs it with their own preferred tools - a strength worth preserving, not standardizing away.
Every automation on this map stays in the admin layer - questionnaires, sweeps, the post-event survey that today depends on someone remembering. The relationship edges are out of scope by design.
Two easy wins sit in plain sight: making the post-event survey automatic instead of memory-dependent, and seeding the venue hub that already exists rather than building anything new - capturing what each EM already does in their own tool, not forcing a migration.
From the confirmed-show timeline, the planning leads set the plan and budget split, hand off per tour in Slack, and an execution team of about eight runs a campaign per city - six figures a month in paid social - through pre-sale, on-sale, and a “finish strong” final month. It’s a high-tempo machine that rarely gets a moment to look back.
Three high-leverage openings, all additive to a team that already runs at scale: capturing end-of-tour spend lessons that are currently lost on the way to the next tour, tightening conversion-tracking accuracy so the KPIs stand on firmer ground, and reclaiming the admin-day a month spent hand-coding ad invoices.
The Concerts division originates offers three ways - agent-led, as exclusive booker, or direct with unrepresented artists - then runs intake and risk analysis, builds the offer in the operations database, and routes the geographic puzzle to confirmation. The whole flow hinges on one manual step: looking up venue expenses by hand.
A well-known industry system once let anyone crank out 30–60 offers a day on auto-populated venue expenses - and one of your own executives helped build it. That is the target state for the one manual step above. The division’s stated goal of growing from ~400 to 550 shows a year rides directly on relieving this exact bottleneck.
Auto-populating venue expenses at the offer step turns a ~20-minute manual lookup into a fast, repeatable action - and because that same offer can then feed downstream instead of being re-keyed into every department’s folder, one fix pays off twice.
The ticketing data lives in two worlds. The operational layer - daily counts - is fast and accurate. The analytical layer - two years and 60M+ rows of purchaser-level history in a cloud SQL warehouse - is deep but reachable only through BI. The two sit side by side and never connect.
Because the vendor API can’t reach the deep history, a purpose-built connector is the only path in - and closing that gap is a prerequisite for most of the other analytical opportunities in this evaluation. Build that one connection and today’s daily counts finally have two years of history behind them.
Beyond their role in this evaluation, the six diagrams are reusable artifacts - useful for onboarding, cross-team training, and settling “how does this actually work?” questions. They belong to you.
Areas are presented in order of interview depth: Finance and Event Operations first, then Booking, Ticketing, and Marketing. Summaries appear here; the complete detail for each area is in the addendum.
Finance is the most rigorously organized area of the business, and the one with the clearest and most defensible opportunities. The ERP is the source of truth; the spend platform handles expenses and bill pay; the load-bearing calculations still live in spreadsheets that, in the team’s own words, “people break.” The finance leader already operates a read-only model against the ERP but cannot keep it in production, for two structural reasons: it has no memory, so every session starts over; and no cached schema, so it re-pulls everything to answer a simple question. Both are platform problems, not model problems.
| Documented pain | What it costs today |
|---|---|
| AP field-coding is wrong, forcing two temporary staff to re-code centrally | Two temps at roughly $40–45/hr loaded - on the order of $170–185K a year at those loaded rates - and the leader notes it grows with volume, not shrinks |
| Settlement accounting spikes sharply after shows play | Three people on one high-volume pillar; “once we hit October they’ll be drowning” |
| Cash forecasting done weekly, by many hands, and not trusted | One to two people per unit for half a day to a day, plus a day to consolidate centrally |
| Reporting is laborious to build and run in the ERP | “I don’t want dashboards, I want to ask the question.” The stated first task to hand off |
Principal opportunities: natural-language reporting (read-only, the appropriate first build, and the foundation subsequent work reuses); the pre-coding agent, which displaces the temporary staffing and scales where hiring does not; settlement accrual preparation delivered as a reviewable journal-entry file the leader uploads himself; and cash-forecast consolidation.
Event Operations is the seam where a confirmed offer becomes a contract, a settlement, and cash. Today that hand-off is manual: dates and amounts are re-keyed, the estimate-versus-invoice gap is tracked by hand, and the settlement pack is rebuilt from scratch for each show. It is also the area where the Touring division is already building its own modules; our recommendations are reconciled against that work rather than duplicating it. The ticketing subsidiary carries its own settlement seam: 30 to 40 settlements processed by hand every Monday - five to seven hours a week of bounded, recurring, already-quantified work.
Principal opportunities: show-settlement assembly (drawing expenses, revenue, ticketing, and the original deal terms into one reconciled pack with receipts matched); ad-pack and advancing-pack auto-assembly; production-template reuse; and contractor-agreement plus 1099 document generation - the produced-events components scoped in coordination with the in-flight internal build, which already covers the pay-calculation logic.
Booking is the area where your professional judgment is strongest and your tooling least developed. One division runs booking on an operations database with a genuine financial model embedded; the other still books from spreadsheets and copy-paste. A demand model exists but resides on a single machine, and the bookers do not yet trust it because no feedback loop exists to teach it what they know. As one put it: “a lot of times we’re running so fast that it’s just get the offer out.” No systematic double-check exists today.
Principal opportunities: venue-expense auto-population at offer creation, with anomaly flagging immediately behind it (this serves the growth goal directly and augments the booker without overriding); an offer-vetting check that compares each new offer against history; an ancillary-revenue model to strengthen rebate terms, where much of the real margin resides; and productionizing the demand model with a feedback loop under the bookers’ control.
Three systems carry ticketing, and they exchange very little. A new daily-count layer ingests box-office audits but begins from a blank slate with no history. A cloud SQL warehouse holds roughly 60 to 65 million records spanning two years of ticketing history, and today it goes almost entirely unused because the people who want answers from it cannot reach it. The daily feed that fills it fails periodically, and a developer must notice and repair it by hand.
Between the ticketing transactional set and your own first-party buyer database, the business holds audience data most promoters would work hard to acquire - and almost none of it is being modeled today. Making it reachable is the largest dormant asset identified in this evaluation.
Principal opportunities: a feed watchdog that detects a broken or shifted feed the moment it occurs; a daily-count assembler that formats counts and flags pacing; a connector that makes the two-year dataset answerable in plain English; and per-artist segmentation that converts dormant transactional data into stronger audience seeds.
Marketing is the most manual and least measured of the five areas, and the one where your own people have already begun solving their problems individually. The media buying itself is well executed. The friction sits in four seams around it: coding spend back to shows, producing the artist ad-packs, measuring whether the spend performed, and the search and SEO channel, which is effectively unaddressed today. Across roughly a thousand shows a year, the institutional learning captured is close to zero - in the team’s words, “we’re moving so fast that we’re on to the next tour.”
Principal opportunities: the spend-to-show coding agent (the same coding problem identified in Finance - a single build serving both areas); an ad-pack finisher that extends a spreadsheet the team has already built; spend-to-sales reconciliation; and establishing the search and SEO channel, which the team identified as its single largest untapped opportunity. Marketing is the thinnest area by interview count, and the findings are presented with that limitation stated rather than overstated.
Every observation is drawn directly from interviews with your team. Where we characterize how much exposure something carries, that is our read as assessors - a starting point for discussion, not a rating you have signed off on. This is meant as a plan, not a complaint list.
| Observation | Exposure | Evidence | What addresses it |
|---|---|---|---|
| Venue and deal knowledge lives in inboxes and heads, and leaves when people do | HIGHER always on | Two leaves in three months meant months of retraining (Touring booking) | A shared venue-knowledge repository that captures existing workflows rather than replacing them |
| The data plumbing rests heavily on one person | HIGHER always on | A single owner handles feed fix-ups, the test parser, the settlement stopgap, and the database merge | Feed monitoring plus a data connector - repeatable rather than person-dependent |
| No offer-to-settlement reconciliation loop exists anywhere | HIGHER always on | Raised in four interviews across three teams, unprompted; one team tried it manually and “couldn’t keep up” | The offer-to-settlement reconciliation build |
| The 60M-row, two-year dataset is unreachable for analysis | HIGHER always on | The vendor API can’t query deep history; consumer AI tools can’t reach the database | The data connector |
| Ancillary revenue is invisible to every profitability surface | HIGHER decision quality | Shows can be misread as unprofitable (Concerts ticketing) | The profitability-visibility build, with a hard access-control boundary |
| A financial-write automation error would be high-cost and hard to catch | HIGHER on build | The CFO’s rationale for keeping a human in the loop | The settled file-generation-for-review rule - AI drafts, a person enters |
| Every ticketing-subsidiary integration carries PCI Tier-1 scope | HIGHER on build | “A pretty heavy lift because of the compliance” | PCI-scoped gating on each subsidiary integration |
| End-of-tour marketing reconciliation is skipped entirely | MODERATE always on | “On to the next” - spend lessons never captured across ~1,000 shows a year | An end-of-tour reconciliation step |
| Settlement quality depends on one final reviewer | MODERATE always on | The SVP of Operations is the last external check on everything | Pre-fill that raises input quality - the two-eyes gate itself stays by design |
| Secondary-market sales are recorded at face value | MODERATE always on | Resale reports aren’t integrated | Correcting how secondary-market sales are recorded |
| Senior staff resist any mandated standard tool | MODERATE on rollout | “Everybody has their best method” | A capture-don’t-migrate posture - meet people in the tools they already use |
| In-house AI development is already under way in one division | PRIORITY · now | Module inventory reviewed together | A scope-reconciliation step so you fund one coordinated effort rather than parallel builds |
| Data lag is 24 hours - fine for history, wrong for any real-time ambition | LOWER always on | Nightly batch | A scope note on real-time use cases |
Three observations are structural, and nearly everything else hangs off them: the unreachable data spine - rich history no analytical tool can query; the missing reconciliation loop - projections and actuals never systematically meet; and knowledge held in individuals - expertise with no home outside the person. All three share the same remediation shape: connected, governed access to the systems you already own. Said plainly - this observations list and the opportunity roadmap are the same picture seen from two sides.
Every figure was stated by a member of your team on a dated call - nothing modeled, nothing inferred. These are the measured facts any future work should hold itself against.
| Area | What we measured | The figure |
|---|---|---|
| Touring | Show volume | ~900–950 shows/yr in settlement · ~90–100 tours · 50–60 artists; the booking team runs ~1,000 booked shows/yr, growing ~200/yr |
| Touring | Team shape | 5 talent buyers (~200 shows each) · 7-person booking team · ~10 event managers + up to 7 seasonal contractors · 70–80 shows per EM |
| Touring | Produced events | ~40 tours / ~530 shows · 3-person team · 70–80% of division revenue |
| Concerts | Offer volume vs the growth goal | ~400 offers/yr today, targeting 550 |
| Concerts | Ticketing team | 5 people; daily-count platform live since January at ~98–99% parse accuracy |
| Marketing | Paid social | Six figures a month across two ad accounts · campaign-per-city · ~80% of conversions via the primary vendor · working KPI thresholds CPC $0.30 standard / $0.10 hot, CTR 1–3% |
| Marketing | Search / SEO baseline | Effectively zero - ~$500 spent of a $10K example budget |
| Ticketing subsidiary | Scale | 20-person company · 530+ events on sale · 550–650 partners/yr · PCI Tier 1 |
| Data spine | The dataset | 60M+ rows · 2 years · purchaser-level detail · nightly batch, 24 hr lag · drop counts 85–90% average |
Baselines are only half of measurement. Their real value is as the fixed line every future phase measures itself against. If work proceeds, each figure gets re-measured on the same terms - baseline → 90-day → steady-state - so improvement is demonstrated, not asserted.
Every opportunity from the interviews, force-ranked and sequenced into waves. Where a per-task time baseline was not captured, the inventory gives the volume and a confidence rating instead of an invented number - so the ranking stands on volume denominators plus qualitative confidence.
| ID | Opportunity | Tier | Confidence | Sizing (interview-stated) |
|---|---|---|---|---|
| F1 | AP pre-coding agent (plus mis-code flagging) - first instance of the categorization core | HS | H | Two AP temps already hired at ~$40–45/hr loaded → ~$170–185K/yr, a derived estimate; grows with volume |
| F2 | Ad-spend allocation agent (200-line invoices) | HS | M | Six-figure monthly paid-social spend; budget rationale sits with the planning team |
| F3 | Natural-language finance query layer (the CFO = named power user) | SC | M | Manual-pull count not quantified |
| F4 | Forecast-variance flagging | SC | M | Not quantified |
| F5 | Accounting-settlement automation - file-generation-for-review, NOT autonomous posting | HS SC | L | Depends on EO2 |
| F6 | Income-recognition + accruals agent - file-generation-for-review | HS | H | Close frequency not quantified |
| F7 | Cash-forecast auto-population (the controller’s #1) | HS SC | M | 1–2 people per unit, half a day to a day weekly, plus a consolidation day |
| F8 | Working-capital forecasting by artist | SC | L | Not quantified |
| F9 | Audit-support assembly (external auditors) | HS | M | Not quantified |
| F10 | Settlement three-way variance compare - cross-departmental | SC | L→M | Number of shows un-analyzed not quantified |
| F11 | Margin-anomaly explainer - reads variance directly from the ERP | SC | M | Not quantified |
| F12 | ZBA daily transfer automation | HS | H | Posting volume not quantified |
| F13 | New-vendor completeness check | HS | H | Percent incomplete not quantified |
| ID | Opportunity | Tier | Confidence | Sizing (interview-stated) |
|---|---|---|---|---|
| T1 | Feed watchdog agent - “generally stable, occasional dev fixes” | HS | M | Break frequency + dev hours not quantified |
| T2 | Daily-count platform historical backfill (a ~90% in-house test parser = head start) | HS SC | M | Vendor-tier cost not quantified |
| T3 | SQL warehouse connector - feasibility confirmed; the only path to the two-year record | SC | H | 60M+ rows · 2 yrs · nightly batch · 24 hr lag |
| T4 | Dynamic price-recommendation engine (genre + city/region; feeds the existing approval step) | RU | L | Depends on T3 |
| T5 | Daily-count dashboard + historical-pacing flags | SC HS | M | Distribution effort not quantified |
| T6 | Kill manual daily-count entry (operations-DB auto-pull) | HS | H | Setup time per tour not quantified |
| T7 | Email management assistant (a ticketing lead’s stated #1) | HS | M | Volume not quantified |
| T8 | Internal profitability dashboard incl. ancillary “secret money” - hard access-control constraint | RU SC | M | Cost of misreads not quantified |
| T9 | Sold-map visibility for non-vendor venues (~20% of Concerts shows) | SC | M | 20% share known |
| T10 | Historical feedback loop (tour-over-tour) - vendor upload stopgap vs T2 pipeline | SC | M | Vendor tier cost not quantified |
| ID | Opportunity | Tier | Confidence | Sizing (interview-stated) |
|---|---|---|---|---|
| Mk1 | Single source of truth for conversion data (~80% via primary vendor) | SC | M | Enabler |
| Mk2 | AI budget management + dayparting (lifetime budgets conflict with standard settings) | HS RU | M | Budget-rationale layer sits with the planning team |
| Mk3 | Actionable-flag + visibility dashboard (CPC / CTR thresholds already in use) | SC HS | M | Thresholds known |
| Mk4 | Audience building / lookalikes from ticket-buyer history | RU | M | Qualitative |
| Mk5 | Ad-invoice auto-class-coding - categorization core instance | HS | H | ~1 admin-day / month |
| Mk6 | End-of-tour reconciliation / “what worked” rollup - skipped entirely today | HS SC | H | Baseline = zero; value = learning loop × ~1,000 shows/yr |
| Mk7 | Search ads + SEO channel - owner-endorsed; a service engagement, not a platform build | RU | M | Near-zero baseline |
| M1 | Customer segmentation + lookalikes on the SQL warehouse | RU | L | Depends on T3 |
| M2 | Ticket velocity / efficient-frontier modeling | RU HS | L | Depends on T3 |
| ID | Opportunity | Tier | Confidence | Sizing (interview-stated) |
|---|---|---|---|---|
| B1 | Auto-populate venue expenses + historicals at offer creation (VP of Booking: “a game-changer”) | HS | H need / M build | ~400 offers/yr → 550 target; ~20 min per offer today |
| B2 | Centralized venue / deal-knowledge base - ONE shared build with EO1 / EO5 | HS SC | M | Knowledge-loss case: two leaves in three months → months of retraining |
| B3 | Automated offer-sheet / tour-offer → event-offer templating | HS | H | 15–16-city tours, ~8 wks, concurrent |
| B4 | Auto-populate scaling tiers | HS | H | Compounds B1 |
| B5 | Routing base + availability / conflict integration (+ cannibalization gap) | SC RU | M | 50+ outreaches per show; 600–700 emails per tour |
| B6 | Anomaly / risk flagging on offers (rent, taxes, fees, stagehands, break-even) | SC | M | Swing scale: “tens of thousands” on rent |
| B7 | Venue rebate / ancillary optimizer - single-source, directional until validated | RU | L→M | Rebate delta not quantified |
| B8 | Competitive-analysis + routing-optimization bolt-on (phase 2, after B5) | RU | L | - |
| B9 | Artist evaluation / underwriting demand model - no reliable streaming → sales correlation | SC | L | Not quantified |
| B10 | Financial vs demand model + Monte Carlo productionization | SC | L | Not quantified |
| B11 | Offer → settlement reconciliation loop - cross-division shared build (4 interviews, unprompted) | SC HS | M | Needs structured settlement data first |
| B12 | Intuition ↔ data bridge (judgment-vs-outcome calibration; piggybacks B11) | SC | L | - |
| ID | Opportunity | Tier | Confidence | Sizing (interview-stated) |
|---|---|---|---|---|
| EO1 | Show-advancing repository + pack assembly (capture-don’t-migrate; post-event survey = embedded quick win) | HS SC | M | ~700–800+ shows/yr, ~10 EMs + ≤7 contractors |
| EO2 | Show-settlement assembly agent (absorbs ticket-audit parsing + venue-expense categorization; populate-never-bypass) | HS | M | ~900–950 shows/yr, ~90–100 tours |
| EO3 | Production template-reuse + routed review - assist-only | SC HS | L | Method not yet documented |
| EO4 | Contractor agreement + 1099 automation (“the single biggest sideways-energy drain”) | HS | M | ~40 tours/yr, 3-person team, 70–80% of division revenue |
| EO5 | Venue-data hub (produced events) + mileage-grid automation - coordinate with the in-house build | HS | M | ~40 tours/yr |
| iEO1 | Ticketing-subsidiary settlement automation | HS | H | 30–40 × 10 min = 5–7 hrs every Monday (PCI scope) |
| iEO2 | Ticketing-subsidiary AI-assisted customer service (deflect-and-escalate) | HS SC | M | CS volume not quantified |
| iEO3 | Ticketing-subsidiary PCI-compliant phone card capture | HS | L | QSA / vendor scope |
| ID | Opportunity | Tier | Confidence | Sizing (interview-stated) |
|---|---|---|---|---|
| WA1 | Ad-pack auto-assembly - 2 hrs → 15 min per pack already proven by the team’s own spreadsheet | HS | H | ~87% already banked by the DIY version |
| WA2 | Email / attachment intake agent | HS SC | M | Doc volume not quantified |
| WA3 | Cross-system re-keying elimination - 3 instances (subsidiary box office ↔ database 1–3 hrs/day; offer → downstream; offer → contract → settlement) | HS | M–H | 1–3 hrs/day on instance (a) |
| WA4 | Ticketing-subsidiary event-build automation | HS | L | PCI scope |
| WA7 | Expense / document-categorization shared core - ONE build, three deployments; confirm-or-override, never auto-post | HS | H | ~1 admin-day/mo (ad invoices) + AP + venue expenses |
Build order is set by dependencies, not by enthusiasm. One connector gates a dozen items; one categorization engine deploys three times; one knowledge base was asked for by three teams independently.
AP pre-coding (F1) → ad-invoice coding (Mk5) → venue-expense mapping (the settlement slice). Build once; the second and third deployments are near-free.
The most leveraged single dependency in the map, now de-risked (feasibility confirmed with your data owner). A design constraint travels with it: flag-don’t-black-box the spreadsheets, and remember the ~24-hour lag - this data is analytical, not real-time.
The sequence is designed to establish momentum through early, verifiable results before advancing to more ambitious work. Reporting leads because it is read-only, verifiable, and the foundation subsequent builds reuse.
A finance question asked in plain English returns its answer directly, with no manual report construction. Read-only by design, so it cannot touch the books - and it is the shared foundation every later finance agent reuses.
Safe on-ramp · foundation for the restReads the invoice, prefills the coding, and asks only when genuinely uncertain. This displaces the two AP temporary staff - roughly $170–185K a year in loaded staffing cost that grows with volume - and the same engine codes marketing spend and venue expenses: one build serving three functions.
Cleanest hard-dollar win · cross-bucketAutomates the 30 to 40 settlements currently processed by hand every Monday, returning roughly five to seven hours a week on a recurring, measurable task. Scoped with the PCI review.
Bounded · recurring · quantifiedMakes the two-year, 60-million-row dataset queryable by the people who need answers from it. Significant in its own right, and the gateway to several revenue-side opportunities.
Makes the largest dormant asset reachablePopulates venue expenses at offer creation and flags any offer that runs off pattern. This serves the booking growth goal directly, and it augments the booker’s judgment rather than overriding it.
Revenue-side · augments the bookerDeterministic, fast, visible: ZBA transfer automation · new-vendor completeness checks · income-recognition file generation (for review) · the end-of-tour marketing rollup · offer-sheet templating · the post-event survey slice. Each sits on an owned process with reachable data, and each is consistent with the reporting-first trust logic.
Finance - natural-language reporting (leadership’s own sequencing). Ticketing subsidiary - settlement automation (best-quantified number). Ticketing - the warehouse connector (the prerequisite). Booking - venue-expense auto-populate (growth-goal denominator). Marketing - the end-of-tour rollup (zero-baseline quick win). Event Ops - the post-event survey slice (the team’s own pick).
| Phase | Months | What happens | Gates & dependencies |
|---|---|---|---|
| Foundation | 1–3 | Governance tiering stood up · natural-language reporting live · the categorization core’s first deployment (AP pre-coding) · quick-win cluster under way · subsidiary settlement scoped with the PCI review | Access-tier setup; PCI scope conversation |
| Data spine | 2–4 | Warehouse connector built and validated (nightly-batch data, ~24-hour lag - analytical, not real-time) · feed watchdog · categorization core deployments 2–3 (ad invoices, venue expenses) | Database access; data-owner partnership |
| Revenue tier | 4–9 | Venue-expense auto-populate + offer flagging · profitability dashboard (with the access-control layer) · segmentation and pacing work on the connected spine · venue-knowledge base, coordinated with the in-flight internal work | Connector live; legacy offer-data seeding; access-control design |
| Strategic tier | 9–16 | The offer → settlement reconciliation build (scoped once, cross-division) · cash-forecast auto-population · demand-model productionization (with the honest caution that streaming numbers don’t reliably predict ticket sales) · remaining document-assembly family | Structured settlement data from earlier phases; confidence earned in production |
The strongest story items - the reconciliation loop and the ancillary-revenue profitability view - sit later in the build order because they depend on structured data the earlier phases create. We’d rather sequence honestly than promise them early.
Your AI use today runs through consumer tools with no shared memory, no audit trail, and no way to reach the company’s own systems - the CFO’s own description of hitting a wall trying to connect an AI model to the warehouse is the clearest example. The recommended posture inverts that.
AI runs on infrastructure you control, connected to the systems you already own - the warehouse, the operations database, the spend platform and ERP, the counts platform - through standard connectors, rather than living inside ad-hoc consumer sessions. Persistent memory of the chart of accounts, the show taxonomy, and each user’s own conventions is treated as a property of the environment itself, not something re-established every conversation.
A small group of 3–5 power users who can write and build agents and automations, and standard users who get read-only, natural-language access. The CFO is the named power user for Finance; other divisions name their own as the model extends. Shared skills self-populate from patterns that repeat across users; an individual’s personal corrections live in a separate per-user profile layer.
AI generates the file - for example, an ERP journal entry - and a person reviews and enters it. Direct AI writes into the ERP are explicitly out of scope until sustained confidence is established.
Anywhere AI maps messy input to a category - vendor coding, invoice class-coding, ticket-count ingestion - a person confirms or corrects before it’s final. The pattern already proven in the working ticket-count parser.
Any agent proposed for the data spine must have undo and fallback options and governance controls in place before it’s trusted to act. Trust is earned incrementally, not assumed at launch.
The existing settlement sign-off convention and division-scoped data access stay intact. Ancillary “secret money” and other division-specific figures never leak to surfaces outside their intended audience.
Gatekeeping at scale. The 3–5 power-user model works at small scale; whether it holds org-wide without an equivalent structure is your CFO’s own good question, carried forward to revisit post-rollout. Sprawl risk. Several leaders are already building point solutions to problems this evaluation identifies. That energy is a real asset; without a shared foundation it becomes several uncoordinated builds rather than one governed platform.
Whatever course you choose from here, the evidence points in one consistent direction: genuine value that your own people already create, constrained by the absence of shared infrastructure to sustain it.
The findings, the figures, and the roadmap are yours to act on. We have sequenced the work in the order we believe compounds fastest - reporting is the foundation the rest reuses - but each division’s figures stand on their own should leadership prefer to begin elsewhere. When you are ready to discuss where to start, we are prepared to help scope it.
Independent of any implementation decision, this evaluation gives you a documented map of how your divisions actually operate today, drawn from direct conversations rather than assumption. That map has standing value on its own. The remainder is a question of sequence.
The full delivery package: the systems & data map, the six workflow maps, the current-state observations, the executive summary, findings by area, the opportunity roadmap, the architecture & governance outline, the baseline-metrics sheet, and an addendum carrying every interview, every system mapped end to end, and the derivation of every figure - 135 pages, each document self-contained and bookmarked.