Our CRM had been live for six years when I finally asked why nobody trusted the reports. The answer took a Salesforce consulting services team three weeks to produce, and it was not what I expected. Nothing was broken. The platform had simply accumulated six years of reasonable decisions made by people who had since left.
That is the common situation, and it needs a different engagement from a new implementation.
The problem is rarely the platform
We assumed we needed to upgrade something. We did not.
We had over three hundred custom fields on one object, most of them empty. Four different definitions of an active customer, all correctly calculated. Automation rules that fired in an order nobody could explain, some of them cancelling each other out.
Every one of those was added for a reason by somebody solving a real problem. Nobody had ever removed one.
That is what six years of unowned configuration looks like, and it is where good Salesforce consulting services earn their fee.
Fix the definitions before anything else
The first recommendation we received was to agree what our core numbers meant.
Active customer. Qualified opportunity. Closed won. Each had multiple definitions in use and nobody had written any of them down.
We now define each once, in words and in the platform, with an owner. That work took five weeks and ended an argument that had been running through our management meetings for years.
No technical change would have fixed it. It was a business agreement that nobody had made.
Then remove what nobody uses
Our consultant asked for field usage data before proposing anything, which I now consider the test of a serious engagement.
About two thirds of our custom fields had been populated on fewer than five per cent of records in a year. We removed most of them over two quarters.
The benefit is not storage. It is that every field is a small cost paid by every user every day, and a record with three hundred fields hides the eight that matter.
Adoption improved measurably and we had changed no functionality.
Sequence the phases so each one lands
We ran the cleanup in three phases and finished each before starting the next.
Definitions first, because everything downstream depends on agreeing what a number means. Then field removal, which is visible to users and builds confidence. Then automation, which carries the most risk and benefits from the confidence the first two produced.
Running them in parallel was proposed and would have been faster on paper. It would also have meant changing definitions, fields and automation at once, with no way to tell which change caused a problem.
Salesforce consulting services scoped as one large programme tend to produce exactly that.
Untangle the automation
This was the hardest phase and the one with the most risk.
Six years of rules, built by different people in different tools, firing in an order determined by history rather than design. Two of them wrote to the same field in a sequence that depended on timing.
That is where our data quality problems were coming from. Not bad input, but automation contradicting itself.
We rebuilt it deliberately, one process at a time, with the old rules switched off rather than left dormant. Dormant rules are how this state returns.
Where the wider estate came into it
Our CRM does not sit alone, and the consultant was right to look outward early.
A meaningful share of our data quality issues originated upstream, in an order system that predates most of the company. Classic legacy system problems, and no amount of CRM configuration was going to fix data that arrived wrong.
Two of our integrations ran on infrastructure our own team built years earlier and nobody maintained. We moved those onto our Azure cloud computing estate, where they are monitored like everything else. That removed a recurring source of silent failures. Our Azure cloud computing team owns them now.
Neither of those was in the original scope. Both mattered more than half of what was.
What I ask a consultancy now
- What will you look at before proposing anything?
- Show me the field usage data before you recommend changes.
- What would you remove rather than add?
- Which of our problems are outside the CRM?
- What will our own team be able to maintain when you leave?
The third question is the most revealing. A consultancy that only proposes additions is describing a longer engagement rather than a healthier platform.
Common questions
Does this need an outside firm?
Often, for the willingness to delete. Our own team knew what was wrong and nobody wanted to be the person who removed a field somebody might still use.
How long does a cleanup take?
Ours ran three quarters in phases. Definitions first, then field removal, then automation. Each phase delivered something on its own.
Should we rebuild instead?
Rarely. A rebuild inherits the same absence of ownership that produced the mess, and you will be back here in six years.
Who should own it afterwards?
One named person who understands the business, with authority to refuse a field request. We did not have that for six years, which is the whole explanation.
Is this worth the cost?
Ours was, and the benefit arrived as adoption and trust rather than as a feature. Salesforce consulting services aimed at cleanup are harder to justify and easier to measure than most projects.
What actually changed
Nobody got a new capability. The platform looks broadly the same.
Our management meetings no longer open with an argument about whose number is correct. Our sales team fills in fewer fields and uses the system more. Support tickets about data being wrong fell by about half.
That is what good Salesforce consulting services produce on an established org. Not new functionality, but the removal of six years of accumulated decisions that nobody was ever responsible for reversing.
