$485M in entertainment sales. 18 teams. One system that didn't exist—until we built it.
A large hospitality enterprise processed $485M annually in entertainment ticket sales across 18 property teams. Two sales channels existed: direct (sold through company properties) and third-party (distributed through external vendors and resellers). Third-party represented the higher-margin channel but carried regulatory complexity.
Multi-state licensing requirements mandated pricing approval chains and contract term validation for every resale agreement. When regulatory inquiries arose—and they were frequent—teams reconstructed documentation manually, pulling files from email, shared drives, and individual machines.
No platform existed to manage third-party ticketing. Not at this company. Not at industry peers of similar scale.
Property teams ran third-party sales through spreadsheets and email. Pricing in Excel workbooks with inconsistent formats. Contracts in Word templates maintained independently by each team. Vendor relationships tracked in email threads and shared drives.
I was asked to reduce friction in third-party sales. What I proposed was building the platform the industry didn't have.
Each of the 18 property teams developed independent processes. But the core issue wasn't process variation—it was structural. Spreadsheets couldn't enforce relationships between data.
The 65% rework rate wasn't a "process problem." It was a data model problem. Errors weren't caught at entry—they were discovered downstream when systems couldn't reconcile.
| Problem | Metric | Business Translation |
|---|---|---|
| Time to onsale | 8.9 days average | Every day a ticket sits in "processing" is a day it isn't selling. 7+ days of lost sales window per event. |
| Rework rate | 65% of transactions required correction | Pricing inconsistencies, contract mismatches, scheduling conflicts discovered after tickets went live. Manual fixes created compliance exposure. |
| Audit response time | Weeks | Multi-state regulatory inquiries required manual reconstruction. Documentation scattered across email, drives, property files. |
Built workflows tailored to their specific venues over years. Viewed consolidation as headquarters imposing control without operational understanding.
Observed previous consolidation efforts fail. Their position: better to manage fragmentation than invest in another platform that won't get adopted.
Needed audit trails. The current state made them nervous, but they'd adjusted processes around manual documentation. Change carried its own risks.
Digitizing the existing spreadsheets and Word documents. Faster to ship. Would have preserved familiar workflows. It would have automated the dysfunction rather than solving it.
Unstructured document-based workflows can't enforce relationships between data. A Word contract and an Excel pricing sheet are just files—they don't know about each other. Validation happens manually, if at all.
Because of the multi-state licensing requirements, we couldn't just trust user input. We built a Compliance-as-Code layer: the system wouldn't physically allow a ticket to be listed unless the pricing model matched the approved contract terms.
This turned compliance from a manual audit into a software constraint.
Property teams resisted headquarters control. Finance was skeptical of another platform initiative.
I reframed the value proposition.
Teams hated headquarters oversight. But they hated audits more.
The platform wasn't "consolidation." It was "protection." Every transaction logged. Every decision documented. When regulators called, teams could pull the trail in minutes.
Direct sales were simpler—internal channels, fewer compliance requirements. Third-party had complex contracts, multi-state licensing, more stakeholders.
The harder case forced the Compliance-as-Code model. Constraints produced durable architecture.
Staff reductions mid-project compressed the team. Multi-state regulatory review added cycles. Lean team, clear priorities.
The platform connected the ticketing system, financial system, and workflow engine into one pipeline. Data flowed from event creation through pricing through contract generation through accounts receivable—replacing manual handoffs with automated validation.
I ran prototype demos across properties to build buy-in. Working software converted skeptics. By launch, the teams that pushed back hardest became the strongest advocates—they'd seen what audit immunity looked like.
This reads like efficiency. It's actually revenue.
Every day a ticket sits in processing is a day it isn't selling. Third-party vendors have sales windows—the earlier tickets go live, the longer the selling period. Cutting 7 days of latency extended the sales window by approximately 20% per event.
Velocity isn't just speed. It's inventory utilization.
The shift: from "fix errors after discovery" to "straight-through processing." Validation at entry meant transactions either succeeded cleanly or failed immediately with clear reasons.
The platform became the system of record for multi-state licensing requirements. When inquiries came in, teams queried the system instead of reconstructing from scattered files.
18 property team workflows unified into one system. Third-party and direct sales on shared infrastructure for the first time.
Third-party had stricter requirements than direct—complex contracts, multi-state compliance, more stakeholders. Those constraints forced the Compliance-as-Code model. The temptation is to start with the easier case. The discipline is recognizing that harder constraints produce cleaner design.
"8.9 days → 1.6 days" sounds like efficiency. Frame it as inventory utilization: every day in processing is a day not selling. The 7-day reduction extended sales windows—that's revenue impact, not just operational speed.
Regulatory requirements were the adoption lever. Teams that resisted consolidation embraced audit immunity. The same platform, framed differently, went from "headquarters control" to "protection I want." Product positioning isn't just marketing—it's how you design the value proposition to flip resistant stakeholders.
The 65% rework rate looked like "people making mistakes." It was actually "systems that couldn't validate relationships." Solving at the process layer would have added checkpoints. Solving at the data layer eliminated the category of error.
The ask was reducing friction. The diagnosis revealed a deeper problem: 18 teams running third-party sales through documents that couldn't validate each other. The 65% rework rate wasn't carelessness—it was structural.
The bet was building Compliance-as-Code: referential integrity that made invalid configurations impossible. The adoption strategy reframed the platform from "headquarters control" to "audit immunity"—protection property teams actually wanted.
The results: 82% faster time to onsale, 65% less rework, audit response in hours instead of weeks. $485M in annual volume on a platform that didn't exist before.
Constraints produced the architecture. The architecture produced the outcomes.