Artur Kolasa
Back to Blog
• 9 min read •
salesforce-architecture independent-advisory

5 Questions That Expose OOTB Feature Gaps Before You Buy [Framework]

Salesforce OOTB features often disappoint after purchase. Use this 5-question due diligence framework to assess real fit and avoid enterprise shelfware.

Due diligence reveals the true TCO, the demo hides it

To evaluate Salesforce OOTB features before purchase, ask five questions: Where does the OOTB flow differ from your required flow? What configurations and customizations are needed to go live? Who are the reference clients using this without heavy customization? How does this feature adapt when your process changes? And how does it integrate with your existing Salesforce stack? These questions expose the gap between demo promises and implementation reality.

I’ve seen this happen too many times. A vendor demos a feature, it looks great, leadership signs off, and then reality hits during implementation. The “out-of-the-box” solution needs so much customization that you might as well have built it from scratch.

During my time at Publicis Sapient, I worked on a Consumer Goods Cloud implementation for Carlsberg. There was significant leadership pressure to follow the “out-of-the-box” approach. The irony? Consumer Goods Cloud itself is far from out-of-the-box. The product was built partly through acquisition, the data models are complex, and the offline mobile app in particular requires substantial customization for any real-world retail execution scenario. We were being asked to go OOTB with a product that doesn’t really have an OOTB path.

That experience, and others like it, taught me to ask harder questions before committing to any OOTB promise.

Here are 5 questions I now ask before buying into any OOTB promise.

1. Where exactly does the OOTB flow differ from our required flow?

Map your core processes step by step. Not the happy path from the demo, but your actual process with all its exceptions and edge cases.

The demo shows a checkout flow in three clicks. Your checkout has complex tax calculations, multiple fulfillment locations, and integration with a legacy ERP that predates REST APIs. That gap between demo and reality? That’s where your budget disappears.

I’ve watched B2B Commerce implementations where the “simple” checkout needed custom Apex for payment orchestration, middleware for inventory checks, and Flow overrides for approval routing. None of that was visible in the demo.

Don’t accept “80% fit” as an answer. That remaining 20% often represents your competitive differentiators. These are the processes that make your business unique. Forcing those into a standard mold either destroys the differentiator or creates workarounds that become maintenance nightmares.

What to do: Create a side-by-side comparison. Standard OOTB flow on the left, your required flow on the right. Every divergence is a potential customization. Get specific about what happens at each step. Process divergences found during discovery cost 10x less to address than those found during UAT.

2. What’s the total list of configurations and customizations needed just to go live?

Vendors love the word “configuration” because it sounds harmless. But if it requires code, it’s customization. If it requires a developer, it’s customization. If it requires understanding platform internals, it’s customization.

Push for a breakdown. How many hours of configuration vs. how many hours of development? The ratio tells you whether you’re buying a product or a starting point.

I’ve seen demos where presenters click through “native” connections between product configuration and commerce checkout. What they don’t show: complex pricing rules need custom Apex. Subscription products with usage-based billing need middleware. Multi-currency with real-time exchange rates? That’s an integration project.

The term “low-code” has blurred these boundaries further. Building complex Flows is still development work, even if no Apex is involved. You still need someone who understands the platform, can debug issues, and can maintain the solution over time.

What to do: Ask to see the implementation guide, not the admin guide. The implementation guide reveals what actually happens during deployment. Request the SI’s estimate, not just the vendor’s. SIs do the actual work and know what it really takes. Demand a breakdown between configuration hours and development hours. Question “accelerators” too. They often handle only 60% of standard scenarios.

3. Show me reference clients using this feature without heavy customization. Can we speak to them?

Vendor-provided references are curated. They’re the customers with smooth implementations and strong internal teams. You need to find the others.

Work your network. Attend user groups. Cold-outreach people on LinkedIn who’ve posted about their implementations. The real value comes from customers who faced challenges similar to yours and can speak honestly about what worked and what didn’t.

Questions to ask peer companies:

  • What surprised you most during implementation?
  • If you could go back, what would you do differently?
  • What’s the ongoing maintenance burden vs. what was promised?
  • How has upgrade compatibility been over time?
  • What integrations required more work than expected?

Red flags in reference calls:

  • Vague answers about timeline (“It took a while” = significantly over plan)
  • Heavy praise for the SI, silence about the product (the SI compensated for product gaps)
  • “We had to customize a lot, but it’s working” (technical debt accumulating)
  • “Our use case was probably unusual” (it probably wasn’t)
  • Hesitation when asked about renewals (value realization is questionable)

The best references are 18-24 months post-go-live. They’ve been through an upgrade cycle, dealt with staff turnover, and have a realistic view of total cost of ownership.

4. What happens when our process changes in 6 months? How does this feature adapt?

Every OOTB solution puts you on the vendor’s roadmap. When they deprecate a feature, you adapt or you’re stuck on an unsupported version. When they change pricing, you pay or you migrate. When they pivot architectures, your customizations may not survive.

This isn’t inherently bad. Vendor innovation brings value. But understand the tradeoffs before you commit.

Vendor roadmap alignment:

  • Does their three-year roadmap align with your direction?
  • Are they investing in the features that matter to your business?
  • What’s their track record on backward compatibility?

Customization durability:

  • How do major releases affect custom code?
  • Is there a published deprecation policy with reasonable timelines?
  • What’s typical effort for annual upgrades?

Exit costs:

  • What does your data look like outside this system?
  • How portable are your processes and integrations?
  • What’s the realistic switching cost if you need to leave?

The upgrade tax is real. Budget for it from day one, or it will budget itself by consuming resources you’d planned for other initiatives.

5. How does this feature integrate with our existing Salesforce stack?

“Native integration” can mean anything from “built on the same platform” to “we acquired a company and slapped our logo on it.”

Will it create data silos, or can it leverage your current architecture? This question matters more than vendors want to admit. Every new cloud or feature that doesn’t share your existing data model creates duplication, sync issues, and reporting headaches. You end up with customer data in three places, none of them fully accurate.

I learned this lesson on an Imperial Brands project at Publicis Sapient. We were implementing B2B Commerce as a headless solution, and the Salesforce team assured us the loyalty functionality would integrate seamlessly with checkout. The nuance they glossed over: that “seamless” integration was designed for B2C Commerce, not B2B. And it assumed a standard storefront, not headless. Two fundamental mismatches that turned a “native” feature into a custom development project.

Consumer Goods Cloud shows the same pattern. CGC was built partly through acquisition, and those namespaced packages still behave like external products. Integrating CGC with Sales Cloud should be straightforward since they’re both Salesforce. But the data models weren’t designed together. Sharing rules don’t align naturally. API behaviors have subtle differences that surface only during implementation.

Same pattern across the ecosystem. Marketing Cloud’s relationship with core Salesforce required Salesforce Connect and careful data architecture long before the current unification efforts. Commerce Cloud (B2C) and B2B Commerce have different object models, different APIs, different deployment patterns, despite both handling “commerce.”

What to do: Ask them to draw the architecture. If MuleSoft or middleware appears in that drawing, you’ve found your answer about how “native” this integration really is. Ask specifically about data model alignment. Will you need to sync records between objects, or do they share the same underlying data? The answer tells you whether you’re buying integration or building it.

What happens when you get OOTB due diligence right

You move from a shiny presentation to a practical discussion. You know which OOTB features fit your business and which need adjustment. You get a realistic view of the effort, the true ROI, and the long-term cost of ownership.

This is how you build a strategy that works in practice, not just on paper.

What happens when you skip OOTB due diligence

This is how projects fail. You end up with “shelfware,” a feature you paid for but can’t use. Or worse, you spend 12 months forcing a custom process into a rigid OOTB box, building technical debt and frustrating the business.

You’re not getting the benefit of your investment because you’ve ended up with a custom solution anyway. Just a poorly planned one.

Key takeaway

A proper assessment isn’t about saying “no” to OOTB features. It’s about making conscious decisions. It ensures that what you buy is what you can actually use, and that your investment delivers a measurable return.

These five questions won’t make vendors happy. They force uncomfortable conversations about gaps between marketing promises and implementation reality. But those conversations are far cheaper to have before you sign than after you’ve committed budget and timeline to a solution that doesn’t fit.

What’s your experience? What OOTB feature looked great in the demo but ended up as shelfware?

This post is part of a series on enterprise Salesforce implementation strategy:

Original post

This article expands on a LinkedIn post from my feed: