9 min read · Shelorve practice note · For CTOs, CIOs, and enterprise technology leaders
Shelorve has been called in to rescue more Salesforce implementations than it has started from scratch. In almost every case, the failure pattern is identical: the consulting team began configuring Salesforce on week two, based on a sales process documented in a workshop that did not reflect how the business actually sells.
Salesforce consulting firms face commercial pressure to show visible progress quickly. Configuration is visible. Opportunity stages appear in the system. Workflows are built. Leadership sees the sandbox and feels confident the project is moving. The problem surfaces at user acceptance testing, when the sales team encounters a system that does not reflect their actual sales motion — and rebuilding at that point is expensive in both money and credibility.
The configuration work done in weeks two through eight is not wasted in the sense that it was careless. It is wasted in the sense that it was built on the wrong foundation. The opportunity stages reflected a playbook. The data model reflected assumptions. The automation reflected a process that exists in a slide deck.
Design, in the context of Salesforce, means understanding the business process with enough precision that the configuration is unambiguous before a single field is created. This requires time with the people who actually do the work — not the people who manage them, not the people who describe what the process should be. Shelorve spends three to four weeks in design before any Salesforce configuration begins.
The design phase produces a process map covering every stage of the sales motion — with entry criteria, exit criteria, required activities, and the data that needs to be captured at each stage. It defines the data model, the integration points with ERP and other systems, and the automation logic. Only when the design document has been reviewed and approved by the business process owners — not just IT — does configuration begin.
This is not a waterfall methodology. The design phase is timeboxed and produces a specific deliverable. It is the difference between building on a surveyed foundation and building on ground you have not tested.
"Low Salesforce adoption is almost always attributed to insufficient training. In our experience, it is almost always a design problem — the system does not reflect how people actually work, so they do not use it."
The design failure is compounded by the integration failure. In most failed Salesforce implementations, the ERP integration — the connection to SAP, Oracle, or whatever system of record holds the authoritative business data — is designed in month five of a six-month project. By then, the data model is locked. The object structure is built. The automation is written. The ERP integration has to conform to the Salesforce design rather than informing it.
When the ERP data does not fit the data model cleanly — and it almost never does without adjustment — the integration becomes a translation layer that is both expensive to build and fragile to maintain. Shelorve defines integration architecture in week one. The data model is built around what the integrations will actually deliver.
A Salesforce system that reflects how people actually work does not require extensive change management. Sales reps adopt it because it makes their job easier — they enter data in one system instead of three, they get accurate pipeline visibility, and the AI scoring reflects the deals they actually win. The correlation between design quality and adoption rate is the most consistent finding in the Shelorve Salesforce practice. A well-designed Salesforce system sells itself.
Tell us about your Salesforce challenge. We will tell you what design before configuration looks like for your engagement.