Your Salesforce Org Is Doing Exactly What You Told It To

Most Salesforce complaints describe a process failure that existed long before anyone bought a license.

Salesforce adoption problems almost always arrive sounding like software problems. The system is too complicated. Nobody keeps it current. The reports don’t match what leadership thinks is true. Half the team quietly went back to a spreadsheet. Those complaints are real and worth taking seriously. They are also, in most of the orgs we see, an accurate description of how the business already ran, rendered in software and finally visible.

What “It’s Too Complicated” Usually Means

A CRM does not invent your process. It records it. If your sales process has four undocumented variations depending on who is running the deal, one of two things happens. Either the system shows you all four and the data looks like a mess, or someone configures it to allow only one and three people stop using it by the end of the month.

Both outcomes get reported the same way: Salesforce isn’t working.

The tells are consistent. Required fields that nobody agreed were required. Opportunity stages with names everyone recognizes and nobody defines the same way. A page layout carrying sixty fields because three departments each asked for their own and no one ever said no. Validation rules written to stop a specific person from doing a specific thing in 2023, still firing today, with no one left who remembers why.

Every one of those is a decision nobody ever actually made, sitting in the system where a decision belongs.

The Pattern We See in Client Orgs

A services firm of about thirty people came to us because their pipeline reports were, in their words, useless. Leadership had stopped trusting the forecast entirely and had gone back to asking the sales manager for a gut read every Monday. They assumed they needed a reporting overhaul, maybe a different edition.

The forecast was built on the Opportunity stage field. “Proposal Sent” turned out to mean three different things. One rep set it when the quote was drafted. Another set it when the proposal actually went out. A third waited until the client acknowledged receipt, because that felt more honest to him. All three were being reasonable. No written definition of that stage existed anywhere, so each person had invented one that made sense to them.

The configuration fix took under an hour: clearer stage names, a short help text on the field, one validation rule requiring a close date before anything could move past Proposal Sent. Getting four people to agree on what the stages meant took two weeks and three conversations. That ratio is the part worth remembering. The technical work is rarely the expensive part.

Their forecast started matching reality within a quarter. Nothing about the platform changed.

Three Questions to Ask Before Anyone Touches a Field

When someone on your team says Salesforce needs to be fixed, these come first:

1. Who decides when a record moves forward, and does everyone know it’s them? If two people can move the same deal to the same stage using different criteria, no amount of configuration will make the data agree with itself.
2. What has to be true before that happens? Write it in a sentence a new hire could follow. If you can’t, the field is not the problem.
3. Who reads this data, and what do they do differently because of it? People maintain the fields they use. A field nobody acts on is a field nobody will maintain, which is a reasonable response to busywork.

If those three questions have clean answers and the system still can’t support them, you have a genuine platform issue. Most of the time, one of them has no answer at all, and that’s where the real work is.

When It Really Is Salesforce

Sometimes the platform is the constraint, and pretending otherwise wastes as much time as blaming it wrongly.

We see legitimate cases regularly. An org on an edition that doesn’t include the automation the team actually needs. A previous admin who built forty custom objects where standard ones would have worked, leaving behind something no new admin can safely change. Integrations wired together years ago by a vendor who has since vanished. Storage limits nobody was watching.

The way to tell the difference is straightforward. Write your process on one page in plain language. If the system genuinely cannot support what’s on that page, the problem is technical and worth real investment. If the page is hard to write because your team doesn’t agree on what it should say, more configuration will only encode the disagreement more deeply.

Where to Start This Week

Pick the one field your team argues about most. Ask three people what it means. If you get three answers, you’ve found something more useful than a reporting backlog, and you can fix it in an afternoon without touching a single line of setup.

That is usually where an engagement with us starts too. Untangling this kind of thing is a large part of what we do through Salesforce consulting, and it tends to look less like configuration work than clients expect. The same dynamic shows up whenever a business rolls out any new system, which is why getting the human agreement in place first is what makes technology changes actually stick.

If you’d like practical Salesforce tips like this one before your next planning meeting, the Iron Insights newsletter is a low-commitment way to keep them coming.

Ready to find out whether your Salesforce problem is actually a reporting problem or an agreement problem? Let’s talk about how your team works before anyone touches a field. Schedule a consultation today!