Every park has one. A neat path runs round the edge of the grass, and a brown diagonal runs straight across it, worn by thousands of people who needed to get to the other side. Planners call them desire paths.
Most commercial teams I’ve worked with in 20 years have them too. They just live in the systems. The ticket office keeps a spreadsheet because the ticketing system can’t hold what it needs. Hospitality has its own tool. The best list of partner contacts is in somebody’s inbox.
None of that is unusual. People find a way round whatever the system can’t do, and every club I know has a few. But we keep being told AI needs organised data. So do we have to fix ours before we get the most out of AI? And what does fixing it actually mean?
Why does data quality matter more once AI starts acting?
I’ll start with where I agree with the “fix your data first” view, because it’s right about the risk. An AI that answers a fan’s question can be wrong cheaply. An AI that does something for that fan can’t.
Say a member asks for a hospitality upgrade, paid with their loyalty points and charged to their account. The agent has to know exactly who they are, what they’re entitled to and what they’ve already paid for. Bad data sitting in a system is a nuisance. Bad data acted on, quickly and at scale, is a refund you didn’t owe or a seat sold twice.
So yes, it matters more now. And to be clear, the best data is always the best place to be. Nobody sensible says “don’t bother tidying”. What I’d question is what we mean by clean, and how much of it has to come first.
Is clean data the same as trusted data?
“Clean data” is usually two different jobs, and clubs tend to fund them as one.
| The question | What goes wrong | What helps |
|---|---|---|
| Can we find it and read it? | The same fan held three ways across ticketing, retail and the CRM | Matching and joining records |
| Is it true? | A perfectly formatted record that still shows a lapsed membership as active | Knowing which system is the record for each fact |
| Can we act on it safely? | The right fan, but a refund that’s already been paid | Checks and permissions in the system that takes the action |
Tidy work (one record, one format, one place) helps a lot with the first question and a bit with the second. On its own it does nothing for the third. The UK government’s data quality framework says it more politely: “A complete data set may have incorrect values in fields, making it less accurate.”
And sometimes tidying is the wrong move. A “customer” can be a person in ticketing, an account in retail and a household in membership. Merge them into one record and you’ve made it neater and less true.
Why does the mess keep coming back?
Because desire paths always come back. People wear them wherever the official route doesn’t go where they need to, and at a club, where they need to go keeps changing. A new sponsor brings its own platform. Matchday gets a new tool. The women’s team or the academy needs something the main system was never set up for. Seasonal staff find a quicker way. A clean-up project finishes, and within a season new paths are worn across the grass. A park can’t stop people cutting the corner either.
That isn’t IT failing. Security, maintainability and shared standards are real requirements, and somebody has to hold the line. But a plan that only works once the estate is perfectly tidy is a plan that waits for ever.
What do agents change, and what don’t they?
They change the cost of walking the paths. An agent can find the records it needs across several systems, read them in their different formats and work out which ones probably belong together, without a migration first.
Done properly, that matching has an order to it. Match the certain things first: email addresses, card numbers, ticket barcodes. Use a model only on the genuinely ambiguous pairs. Make every match something a person can check.
Our own CRM at Earl works like this on a small scale. When an email mentions someone, it proposes who they are, and if the match isn’t exact, a person confirms it. It once linked a mention of Google Cloud to Oracle, with a perfectly reasonable explanation attached.
What agents don’t change is the gap between “probably the same fan” and “safe to spend their money”. A likely match is somewhere to start looking. None of this is new, either. Integration teams have worked across messy systems for decades. What’s new is how cheaply and flexibly it can be done now.
What does that look like in practice?
Take a season-ticket holder who writes in: “I paid for the upgrade and it’s not showing. Sort it out.”
An agent can pull the evidence together from ticketing, the CRM and payments, within what that signed-in fan is allowed to see. The upgrade rules, and the refund or seat change itself, run in the club’s own systems, which stay the record. OWASP, the security community’s reference for this, puts it bluntly: “Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not.”
If anything that matters is uncertain (who this is, what they’re owed, whether it’s already been done), the agent stops and a person decides. And the stale flag that caused the problem still gets reported and fixed. Getting round a fault once is no reason to keep it.
The club sorted one fan’s problem without migrating a decade of records first.
Where should the clean-up money go?
Instead of “clean everything first”, ask one question about each problem the agent runs into: do we work across it, fix it, or stop?
- Work across it when the evidence is there and the journey is rare.
- Fix it when it causes the same doubt every week, or getting it wrong would be costly.
- Stop and ask a person when you can’t prove who it is, what they’re entitled to or whether it’s already been done.
Work back from the journeys that matter most to your commercial team, and fix what they show you. Agents change how much of the clean-up has to come first, and where it happens. They don’t abolish it.
Pave some paths, fence off a few
Back to the park. Some desire paths should be paved, because everyone uses them. A few should be fenced off, because they cut across something dangerous. Most can stay as they are.
That’s how we design at Earl. We read from a club’s systems of record, inside its own estate and behind its own sign-in, and we don’t build a second copy of the data. The paths will keep changing. How strict you are about the evidence, and the permission to act on what you find along them, shouldn’t.
Frequently asked questions
Do we need to clean all our data before using AI agents?
No. Agents can work across fragmented systems. Fix the problems that block the journeys you care about, and make sure every action is checked by the system that holds the record.
Can AI deduplicate fan records?
It can propose matches well, especially once the certain identifiers have been matched first. A proposed match should be checkable by a person, and it isn’t permission to take a payment or move a ticket.
What is a system of record?
The place a fact officially lives, such as ticketing for seats or the CRM for memberships. An agent should read from it and act through it, not keep its own copy.
Sources
- UK Government, The Government Data Quality Framework (3 December 2020): https://www.gov.uk/government/publications/the-government-data-quality-framework/the-government-data-quality-framework
- OWASP Gen AI Security Project, LLM06:2025 Excessive Agency: https://genai.owasp.org/llmrisk/llm062025-excessive-agency/