Thirty-five systems collapsed into one platform
Tottenham Hotspur Football Club ran about 35 disparate systems across its fan-facing estate before it centralised on Salesforce CRM, according to diginomica's report by Sarah Aryanpur. The club now runs Service Cloud and Agentforce, including an Ask Spurs bot answering in around 11 languages, 24 hours a day.
The sentence that deserves more attention comes from Rob Pickering, the club's Chief IT and Digital Officer. "We centralized them in Salesforce. We also had to make sure we had identity across all of our touch points." Two sentences, two completely different projects. The first is a procurement decision and a migration plan. The second decides whether any of it holds together.
Tottenham was founded in 1882 and counts more than 300 million fans globally, which makes the identity problem unforgiving. Pickering describes the last 18 months as a major effort on the digital side of the club. The part nobody photographs is the matching logic underneath all of it.
One platform gives you one place to do the resolving
Collapsing 35 systems into one does not resolve identity. It moves the resolving into a single place where you can finally do it, which is a real improvement and a different thing from having done it. Ticketing records still arrive keyed on an order reference. Loyalty records still carry a membership number. Support records carry whatever email address somebody typed into a form at half time.
Someone has to decide that the account which bought four seats in one block, the membership number in the loyalty scheme and the person emailing about a refund all belong to one human being. No source system ever agreed on a key, because none of them were built to. Ticketing cared about a transaction. Loyalty cared about a member. Support cared about whoever was in the queue.
Exact email matching gets you most of the way and then fails in the cases that generate complaints. Families share an address. A season ticket sits in one relative's name while another relative attends. Each of those is a decision about what a shared customer record really needs, and no platform makes it for you.
The bot is only as good as the record behind it
An Ask Spurs bot running in around 11 languages around the clock raises the stakes on all of this. An agent answering a fan has to know which account it is looking at before it can say anything useful about a ticket or a membership. Where identity resolution is loose, the agent either refuses to help someone it cannot place or answers confidently from the wrong record.
Both failure modes get expensive across a fanbase that size. The refusal generates the support contact the bot was bought to avoid. The wrong record is worse, because telling one supporter about another supporter's booking becomes a data protection incident. Consolidation also makes a bad merge harder to spot, since no second system is left to contradict it, which is why a practical pattern for identity exceptions matters more after a consolidation than before it.
One vendor is a defensible answer with a bill attached
None of this argues against what Tottenham did. Thirty-five systems means 35 upgrade calendars, 35 support contracts, 35 sets of credentials to remove when a staff member leaves and 35 places a fan record can drift out of step. Removing that is worth real money before anything gets smarter, and a single CRM is a call plenty of architects would make with the same estate.
The bill is concentration. One supplier now sits underneath ticketing, service and whatever else moved, which shifts the renewal conversation in the supplier's favour and turns any future exit into a programme rather than a project. Price that trade while negotiating a multi-year renewal, rather than after the estate has been rebuilt around one vendor's data model.
The quieter cost is modelling. The keys chosen during migration outlive the platform choice by years, so durable business keys are worth arguing about while the migration is still open. Changing them later means reopening every match already made.
A platform capability is not a compliant configuration
On data residency, Pickering says: "Because Salesforce is a global company, local protection requirements are built into the platform". That reads as accurate on its own terms, and it describes what the vendor provides.
A capability being available sits some distance from a particular tenant's configuration satisfying a particular regulator. Which regions the data rests in, which staff can read it, how long it is kept and what the matching rules do with personal data belonging to fans in different jurisdictions are all customer decisions. The diginomica article does not claim Tottenham's configuration is compliant, and neither do we.
Identity resolution touches personal data harder than most of a consolidation, because matching across systems means comparing records collected under different notices for different purposes. A platform control can enforce where data rests. It cannot decide whether joining two records was permitted in the first place.
The question to settle before your own consolidation
Answer one thing before signing anything. Which key will every system be required to agree on, and who owns it when two systems disagree. Not the CRM, and not the implementation partner. A named person or team with the authority to declare that two records are one person and to reverse that call when it turns out to be wrong.
Where the answer is that the new platform will work it out, a consolidation delivers a shorter vendor list and the same unresolved argument about who the customer is. Writing down the CRM data model that outlives the CRM is cheap while the migration plan is still a document and expensive once 35 systems have been switched off. Tottenham's 18 months bought one system of record. The identity work Pickering mentions in half a sentence decides whether it can be trusted on a match day.
