Stop Measuring Salesforce Health. Start Measuring EBITDA.

The Core Argument: Tools vs. EBITDA

Most Salesforce “health checks” and technical org assessments focus on configuration quality, code smells, data volumes, and feature usage—but they rarely tie those findings back to impact on margin, growth, or valuation multiples. That leads executives to fund refactors and re-implementations that make the system cleaner without making the business more profitable or more valuable.

If Salesforce is a major line item in opex, then it should be treated as an investment whose performance is measured with EBITDA, revenue efficiency, and risk-adjusted returns. In practice, that means starting from business outcomes—faster sales cycles, higher net revenue retention, lower cost-to-serve—and working backwards into Salesforce, not starting from Salesforce features and hoping they ladder up to value.

Why Tech-First Assessments Fail

Tech assessments are attractive because they produce tangible outputs—org diagrams, code scans, and best-practice scorecards—but those artifacts are weak predictors of business value on their own. You can have a beautifully architected org that does nothing for revenue, and a messy one that quietly prints money because it is perfectly aligned with a few critical revenue workflows.

Common failure patterns include:

• Over-indexing on Salesforce utilization KPIs (logins, record counts, feature usage) instead of economic KPIs like pipeline conversion, cost per order, or cases handled per FTE.
• Recommendations that maximize technical elegance (rebuild in LWCs, consolidate objects, re-implement flows) without a quantified business case tied to incremental EBITDA or risk reduction.
• Roadmaps that assume Salesforce is always the right answer, instead of questioning where the platform is actually a net drag or should be simplified, integrated differently, or even de-scoped.

The result is a backlog of technically “good” work that competes for funding with projects that have clear revenue or margin upside, and IT gets blamed for being a cost center instead of a value multiplier.

A Value-First Salesforce Framework

A better approach is to treat Salesforce as part of your value creation system and design the assessment around a simple set of questions board members actually care about.

Where does Salesforce touch EBITDA today?

• Revenue: lead-to-cash speed, win rates, average deal size, upsell/cross-sell execution, churn drivers, and sales capacity unlocked per seller.
• Cost and margin: automation that reduces manual effort, error rates, rework, and time-to-resolution in service and operations.
• Risk: compliance, auditability, data governance, and resilience that protect revenue streams and valuation in diligence scenarios.

What is the fully loaded cost of Salesforce as a capability?

• Licenses, add-ons, partner spend, internal admin and dev time, and adjacent tools needed to keep the ecosystem running.
• Hidden costs like slow user experiences, manual workarounds, and change fatigue when the org is brittle.

What are the viable alternatives and opportunity costs?

• Could simpler workflows, fewer integrations, or process redesign meet the same business goals with less complexity and spend?
• Are there parts of the customer journey that should not live in Salesforce at all based on fit, risk, or scaling profile?

Only after those questions are quantified do you decide which technical changes to make. The tech plan emerges from the value plan, not the other way around.

Maximizing Value While Minimizing IT Load

When you reframe Salesforce as an EBITDA lever, one of the most immediate benefits is a ruthless prioritization of work that matters—which directly reduces load on IT.

Key principles:

• Tie every backlog item to a value narrative. If a change request cannot be linked to a clear improvement in revenue, margin, risk, or scalability, it stays out of the roadmap—or gets bundled into a funded initiative with explicit justification.
• Prefer configuration and automation over custom build. Using flows, standard objects, and AI/automation features where possible reduces long-term maintenance and makes it easier for admins and power users to own future changes, instead of relying on scarce dev capacity.
• Standardize patterns and reduce platform sprawl. Consolidating duplicative apps and integrations around a coherent architecture not only cuts licensing cost but also simplifies support and change management.

A concrete example: if you identify that slow quote turnaround is killing win rates, the value case might be “Increase close rates by 3 percentage points and reduce discounting to add X to annual EBITDA.” From there, the Salesforce work (CPQ optimization, guided selling, approval automation) is scoped and funded as a business program with a measurable outcome—and only the minimal technical design necessary to capture that value is executed.

Future-Proofing Capabilities, Not Just Orgs

Future-proofing isn’t about having the cleanest org; it’s about having a CRM capability that can evolve with strategy, market, and technology shifts without exploding cost or risk. That requires architectural and operating decisions anchored in adaptability and economic sense, not just current best practices.

Core elements include:

• Modular, scalable architecture aligned to domains. Design around stable business capabilities (e.g., lead management, pricing, service triage) so that new products, geographies, and channels can be added without re-platforming.
• Data and AI readiness as economic levers. Clean, well-governed data and composable integration patterns enable Einstein and agentic AI to actually deliver ROI, instead of becoming yet another confusing feature bundle.
• A living CRM roadmap linked to strategy. You maintain a multi-year view that connects corporate objectives to CRM capabilities, with regular reviews that add, pause, or retire initiatives based on realized and forecasted returns.

In this model, a “future-proof” Salesforce landscape is one where the business can change its go-to-market, pricing, or service model—and Salesforce can follow quickly with predictable cost and risk—because its design is grounded in business capabilities and value metrics, not just in the current release cycle.

Client Example: An $8B Enterprise with 13+ Business Units

The shift from “Salesforce implementation” to “Capability Implementation” can best be witnessed with one of my clients that had tried a very complex “Org Consolidation” project three times before. The project was only focused on tech debt and the reduction of orgs.

This was the wrong focus. Once we shifted to a “ONE” capability focus—and the value that would drive for the BUs (shared metrics, shared products/services, shared capabilities, and then reduction across the BUs)—the project finally moved forward successfully.

The end result was a single Salesforce org for Marketing, Sales, Service, CLM, CPQ, and Order Management with less than 2% programmatic implementation—meaning the business can make changes when needed and move at the speed of their market. This also turned into a massive consolidation of other duplicative applications and capabilities across the BUs, reducing IT spend across the entire organization.

The key EBITDA levers in this program were:

• Application reduction and cost takeout—both from the five Salesforce orgs and from duplicated capabilities other tools provided across the 13 BUs.
• The ability to move at speed as ONE business, not 13.
• A clear view of customer share of wallet and spend across the 13 BUs, helping to drive better sales and account planning for net new revenue.

What Kind of Companies This Approach Is For

This approach is not for organizations that just want a technical health check and a list of things to “fix” in their org. It is for leadership teams that are ready to ask harder questions about where Salesforce is truly accretive to enterprise value—and where it might be overbuilt, underused, or misaligned.

The ideal partner wants to:

• Translate Salesforce from a line item into a measurable contributor to EBITDA and valuation multiples.
• Give IT the mandate to say “no” to technically-interesting but economically-weak work.
• Build a forward-looking CRM capability that creates optionality for AI, new business models, and strategic pivots—without continually increasing complexity and load.