Your Salesforce Is Not a CRM. It's an Archive.

When a global sports and lifestyle brand let us look inside their Salesforce instance, we found a system used almost entirely as a post-hoc record of work done elsewhere. Here's what we found — and how we'd fix it.

The Problem No One Talks About

There is a specific failure mode in enterprise Salesforce deployments that is easy to miss because it doesn't look like failure. The system is live. Licenses are paid. Contacts are being created, meetings are being logged, fields are being filled in. From the outside, it looks like adoption.

What it actually is: a filing system for work that happened somewhere else.

We encountered this pattern in detail during a discovery engagement with a global sports and lifestyle brand preparing for a large-scale Salesforce transformation. Before scoping any implementation work, we ran structured discovery sessions across their CRM, Marketing Cloud, and CDP environment. What the client's own team told us about their Sales Cloud instance maps almost exactly to patterns we see repeatedly in organizations that have been on Salesforce for several years without a deliberate technical governance model.

What We Found: A System of Documentation, Not Intelligence

When we asked which activities, reports, or pipelines were still being managed outside Salesforce, the answer from the client's revenue team was unambiguous:

"Essentially, everything. We monitor sales calls, campaigns, and data collection via Excel and then feed this back into SF. All numerical data — revenues, membership numbers — is drawn from Tableau. All communications are sent via Outlook and then copied and pasted into SF."

Parse that technically. The source of truth for sales activity was Excel. The source of truth for revenue data was Tableau. Communications happened in Outlook. Salesforce received a manual transcription of all three — after the fact, by hand, with no automation, no integration, and no validation layer.

On top of this, the primary use of Salesforce was logging meeting notes — described by the team as "hard to follow and even harder to report on." Unstructured text in activity records, no standardized schema, no downstream triggers, no task automation firing from them.

Their assessment of the biggest CRM pain point was self-aware and direct:

"Lack of knowledge about SF means it is treated as a data dumping ground, rather than a useful tool. Reports from the field are spread across multiple locations, making visibility hard."

This is a technically precise description of a data integrity collapse. Not a bug. Not a missing feature. A complete decoupling of the CRM from the actual operational workflow — sustained over time until the decoupling became the norm.

Why This Happens: Three Root Causes

It's tempting to attribute CRM underuse to change management failures or training gaps. Those are real contributors, but they're symptoms. The technical root causes sit deeper.

1. Implementation Without Integration Design

Salesforce was stood up as a standalone system. The surrounding tools — Outlook, Tableau, Excel, the LMS, the membership platform, the commerce stack — were never connected to it as authoritative data sources. So the only way information got into Salesforce was manual entry.

Manual entry is slow, inconsistent, and the first thing that gets deprioritized under workload pressure. Within months of go-live, the CRM is incomplete. Within a year, it's unreliable. Within two years, nobody trusts it.

The fix is not a training program. The fix is building the integration layer that should have been built at the start: event-driven writes from source systems into Salesforce, so that CRM data is a byproduct of work happening — not a separate task added on top of it.

2. Object Model Not Designed for the Actual Sales Motion

In this client's case, Salesforce had been used almost exclusively to manage store onboarding and store lifecycle — a narrow operational use case that bore no relation to the full B2B and B2C revenue motion. Lead routing, opportunity management, partner health scoring, renewal tracking, commission calculation — none of these workflows were modeled in the CRM object structure.

When a sales team's actual workflow has no corresponding representation in the CRM, they route around the CRM. That's a rational response to a bad tool design, not a behavioral failure.

3. No Feedback Loop Between CRM Data and Business Decisions

The client's revenue forecasting lived in Tableau, pulling from a separate data warehouse. The CRM had no connection to how the business actually made decisions. If the CRM doesn't surface information that helps anyone do their job better, there is no behavioral incentive to maintain it. Data quality degrades because quality has no visible consequence.

The Audit Framework: Four Dimensions Before Any Recommendation

When we encounter a CRM in this state, the instinct from both client and partner side is often to ask: what should we rebuild? Our position is consistent — don't rebuild anything until you've audited what you have.

Dimension 1: Data Quality Baseline

Quantify the problem before proposing a solution. How many Contact records are duplicated? What percentage of Opportunity records have Amount populated? What is the distribution of Lead Stage values — and do those values reflect a real buying stage, or a legacy picklist nobody has updated since implementation? What is the last-modified-date distribution across the object — how many records haven't been touched in over 12 months?

Dimension 2: Process-to-Model Alignment

Map the actual sales and account management workflow against the CRM configuration. Where does the workflow leave Salesforce — and why? In this client's case, the exit point was almost immediate: work started in email and Excel, Salesforce received a record of it later.

This mapping also identifies which workflow steps have no CRM representation at all. If your partner account health review process happens in a spreadsheet because there's no Account Health object or scoring model in Salesforce, you have an object modeling gap that no amount of user training will close.

Dimension 3: Integration Coverage

Enumerate every system that should be writing to or reading from Salesforce — and for each one, document whether the integration exists, what protocol it uses, how frequently it syncs, and what the failure mode is when it breaks.

For this client: Outlook was not integrated. Tableau was not feeding back into CRM. The LMS — which tracked course completions and certification status for hundreds of thousands of members — had no connection to Salesforce contact records. The membership platform that managed club enrollment, renewals, and lapses was similarly isolated. The CRM was an island surrounded by systems that had no awareness of each other.

Dimension 4: Usage Pattern Analysis

Login frequency and record creation rates tell you where adoption is real. Field completion percentages tell you which fields the team finds meaningful versus which ones they skip. Report and dashboard usage tells you whether anyone is actually getting value from the data that does exist.

In this engagement, usage analysis confirmed what process mapping had suggested: the heaviest Salesforce activity was in activity logging (meeting notes), with very low engagement with pipeline views, forecast reports, or account-level dashboards. The tool was being used as a notepad, not a revenue system.

What the Audit Changes About the Implementation Recommendation

Running this audit before scoping implementation work produces a fundamentally different technical recommendation than jumping straight to "what should we build."

For this client, the audit revealed that the primary problem was not a missing Salesforce feature. It was a missing integration layer and a CRM object model that had never been aligned to the actual sales process. The remediation sequence we recommended:

Phase 1: Data Model Cleanup

Rationalize objects, standardize picklists, define mandatory fields that reflect actual sales stages — not inherited legacy values — and establish clear field ownership. This work is unglamorous and typically underestimated. It is also the most consequential thing you will do in a Salesforce remediation project.

Phase 2: Integration Layer

Connect the surrounding systems as authoritative sources. Email activity should sync from Outlook or Gmail via Salesforce Inbox or a native connector — not manual copy-paste. Revenue and membership data should flow from the data warehouse into Salesforce via scheduled or event-driven sync. The LMS should write certification completions to Contact records as they happen.

Phase 3: Workflow Redesign

Once the data model is clean and integrations are live, rebuild the process flows — lead routing, renewal triggers, partner health scoring — as Salesforce-native automation. Flow Builder for deterministic logic. Einstein for scoring models once there's enough clean data to train on. At this stage, and only at this stage, does automation become trustworthy.

One additional finding worth flagging: mid-discovery, the client raised the possibility of replacing their existing support platform with Salesforce Service Cloud, and bringing in Experience Cloud for partner portal functionality. Both are reasonable candidates in a mature Salesforce environment. Neither should be scoped until the Sales Cloud foundation is stable.

The Transferable Lesson

The pattern we found — CRM as post-hoc archive, work happening elsewhere, manual re-entry as the integration layer — is not unique to this client or this industry. It shows up in organizations of all sizes that implemented Salesforce without investing in integration architecture, and without designing the object model around the actual sales motion rather than an idealized version of it.

The technical principle is straightforward: a CRM that doesn't reduce friction in the workflow will be routed around. Not because users are resistant to change, but because rational people choose the path of least resistance. If Excel is faster than Salesforce for capturing a call note today, Excel wins — and over time, Excel becomes the system of record by default.

Making Salesforce the system of record requires making it the lowest-friction option for capturing work as it happens. That requires integration, not training. It requires object model design, not change management decks. And it requires an honest audit of where the CRM actually stands before a single line of new configuration is written.

Axelerant works with enterprises on Salesforce strategy, CRM re-implementation, and multi-cloud transformation. If your team is navigating a degraded CRM instance or preparing for a multi-cloud engagement, we'd be glad to talk through how we approach it.

When a global sports and lifestyle brand let us look inside their Salesforce instance, we found a system used almost entirely as a post-hoc record of work done elsewhere. Here's what we found — and how we'd fix it.

The Problem No One Talks About

There is a specific failure mode in enterprise Salesforce deployments that is easy to miss because it doesn't look like failure. The system is live. Licenses are paid. Contacts are being created, meetings are being logged, fields are being filled in. From the outside, it looks like adoption.

What it actually is: a filing system for work that happened somewhere else.

We encountered this pattern in detail during a discovery engagement with a global sports and lifestyle brand preparing for a large-scale Salesforce transformation. Before scoping any implementation work, we ran structured discovery sessions across their CRM, Marketing Cloud, and CDP environment. What the client's own team told us about their Sales Cloud instance maps almost exactly to patterns we see repeatedly in organizations that have been on Salesforce for several years without a deliberate technical governance model.

What We Found: A System of Documentation, Not Intelligence

When we asked which activities, reports, or pipelines were still being managed outside Salesforce, the answer from the client's revenue team was unambiguous:

"Essentially, everything. We monitor sales calls, campaigns, and data collection via Excel and then feed this back into SF. All numerical data — revenues, membership numbers — is drawn from Tableau. All communications are sent via Outlook and then copied and pasted into SF."

Parse that technically. The source of truth for sales activity was Excel. The source of truth for revenue data was Tableau. Communications happened in Outlook. Salesforce received a manual transcription of all three — after the fact, by hand, with no automation, no integration, and no validation layer.

On top of this, the primary use of Salesforce was logging meeting notes — described by the team as "hard to follow and even harder to report on." Unstructured text in activity records, no standardized schema, no downstream triggers, no task automation firing from them.

Their assessment of the biggest CRM pain point was self-aware and direct:

"Lack of knowledge about SF means it is treated as a data dumping ground, rather than a useful tool. Reports from the field are spread across multiple locations, making visibility hard."

This is a technically precise description of a data integrity collapse. Not a bug. Not a missing feature. A complete decoupling of the CRM from the actual operational workflow — sustained over time until the decoupling became the norm.

Why This Happens: Three Root Causes

It's tempting to attribute CRM underuse to change management failures or training gaps. Those are real contributors, but they're symptoms. The technical root causes sit deeper.

1. Implementation Without Integration Design

Salesforce was stood up as a standalone system. The surrounding tools — Outlook, Tableau, Excel, the LMS, the membership platform, the commerce stack — were never connected to it as authoritative data sources. So the only way information got into Salesforce was manual entry.

Manual entry is slow, inconsistent, and the first thing that gets deprioritized under workload pressure. Within months of go-live, the CRM is incomplete. Within a year, it's unreliable. Within two years, nobody trusts it.

The fix is not a training program. The fix is building the integration layer that should have been built at the start: event-driven writes from source systems into Salesforce, so that CRM data is a byproduct of work happening — not a separate task added on top of it.

2. Object Model Not Designed for the Actual Sales Motion

In this client's case, Salesforce had been used almost exclusively to manage store onboarding and store lifecycle — a narrow operational use case that bore no relation to the full B2B and B2C revenue motion. Lead routing, opportunity management, partner health scoring, renewal tracking, commission calculation — none of these workflows were modeled in the CRM object structure.

When a sales team's actual workflow has no corresponding representation in the CRM, they route around the CRM. That's a rational response to a bad tool design, not a behavioral failure.

3. No Feedback Loop Between CRM Data and Business Decisions

The client's revenue forecasting lived in Tableau, pulling from a separate data warehouse. The CRM had no connection to how the business actually made decisions. If the CRM doesn't surface information that helps anyone do their job better, there is no behavioral incentive to maintain it. Data quality degrades because quality has no visible consequence.

The Audit Framework: Four Dimensions Before Any Recommendation

When we encounter a CRM in this state, the instinct from both client and partner side is often to ask: what should we rebuild? Our position is consistent — don't rebuild anything until you've audited what you have.

Here's the four-part framework we use.

Quantify the problem before proposing a solution. How many Contact records are duplicated? What percentage of Opportunity records have Amount populated? What is the distribution of Lead Stage values — and do those values reflect a real buying stage, or a legacy picklist nobody has updated since implementation? What is the last-modified-date distribution across the object — how many records haven't been touched in over 12 months?

These numbers define the remediation scope. They also reveal whether the problem is localized (a few bad processes over a short time window) or systemic (years of inconsistent data entry across the entire object graph).

Dimension 2: Process-to-Model Alignment

Map the actual sales and account management workflow against the CRM configuration. Where does the workflow leave Salesforce — and why? In this client's case, the exit point was almost immediate: work started in email and Excel, Salesforce received a record of it later.

This mapping also identifies which workflow steps have no CRM representation at all. If your partner account health review process happens in a spreadsheet because there's no Account Health object or scoring model in Salesforce, you have an object modeling gap that no amount of user training will close.

Dimension 3: Integration Coverage

Enumerate every system that should be writing to or reading from Salesforce — and for each one, document whether the integration exists, what protocol it uses, how frequently it syncs, and what the failure mode is when it breaks.

For this client: Outlook was not integrated. Tableau was not feeding back into CRM. The LMS — which tracked course completions and certification status for hundreds of thousands of members — had no connection to Salesforce contact records. The membership platform that managed club enrollment, renewals, and lapses was similarly isolated. The CRM was an island surrounded by systems that had no awareness of each other.

Dimension 4: Usage Pattern Analysis

Login frequency and record creation rates tell you where adoption is real. Field completion percentages tell you which fields the team finds meaningful versus which ones they skip. Report and dashboard usage tells you whether anyone is actually getting value from the data that does exist.

In this engagement, usage analysis confirmed what process mapping had suggested: the heaviest Salesforce activity was in activity logging (meeting notes), with very low engagement with pipeline views, forecast reports, or account-level dashboards. The tool was being used as a notepad, not a revenue system.

What the Audit Changes About the Implementation Recommendation

Running this audit before scoping implementation work produces a fundamentally different technical recommendation than jumping straight to "what should we build."

For this client, the audit revealed that the primary problem was not a missing Salesforce feature. It was a missing integration layer and a CRM object model that had never been aligned to the actual sales process. The remediation sequence we recommended:

Phase 1: Data Model Cleanup

Rationalize objects, standardize picklists, define mandatory fields that reflect actual sales stages — not inherited legacy values — and establish clear field ownership. This work is unglamorous and typically underestimated. It is also the most consequential thing you will do in a Salesforce remediation project.

Phase 2: Integration Layer

Connect the surrounding systems as authoritative sources. Email activity should sync from Outlook or Gmail via Salesforce Inbox or a native connector — not manual copy-paste. Revenue and membership data should flow from the data warehouse into Salesforce via scheduled or event-driven sync. The LMS should write certification completions to Contact records as they happen.

Phase 3: Workflow Redesign

Once the data model is clean and integrations are live, rebuild the process flows — lead routing, renewal triggers, partner health scoring — as Salesforce-native automation. Flow Builder for deterministic logic. Einstein for scoring models once there's enough clean data to train on. At this stage, and only at this stage, does automation become trustworthy.

One additional finding worth flagging: mid-discovery, the client raised the possibility of replacing their existing support platform with Salesforce Service Cloud, and bringing in Experience Cloud for partner portal functionality. Both are reasonable candidates in a mature Salesforce environment. Neither should be scoped until the Sales Cloud foundation is stable. Adding Service Cloud on top of a degraded CRM object model replicates the mess into a second product surface.

The Transferable Lesson

The pattern we found — CRM as post-hoc archive, work happening elsewhere, manual re-entry as the integration layer — is not unique to this client or this industry. It shows up in organizations of all sizes that implemented Salesforce without investing in integration architecture, and without designing the object model around the actual sales motion rather than an idealized version of it.

The technical principle is straightforward: a CRM that doesn't reduce friction in the workflow will be routed around. Not because users are resistant to change, but because rational people choose the path of least resistance. If Excel is faster than Salesforce for capturing a call note today, Excel wins — and over time, Excel becomes the system of record by default.

Making Salesforce the system of record requires making it the lowest-friction option for capturing work as it happens. That requires integration, not training. It requires object model design, not change management decks. And it requires an honest audit of where the CRM actually stands before a single line of new configuration is written.

Read Next

This audit work sits at the beginning of a larger multi-cloud Salesforce transformation. Once Sales Cloud is remediated, the question becomes: in what order do you implement Sales Cloud, Marketing Cloud, and CDP — and why does the sequence matter more than the speed?

→ The Right Order to Implement Salesforce: Why Sequence Matters More Than Speed

Axelerant works with enterprises on Salesforce strategy, CRM re-implementation, and multi-cloud transformation. If your team is navigating a degraded CRM instance or preparing for a multi-cloud engagement, we'd be glad to talk through how we approach it.