Salesforce is a powerful CRM platform that can revolutionize how you manage customer relationships, drive sales, and streamline operations. However, to truly harness its full potential, you need a strategic approach and expert guidance.
Oblytech does Salesforce consulting that goes beyond basic implementation. We start by learning your business goals and the problems you need solved, then design an approach that gets more value from your Salesforce investment.
Salesforce consulting is the work of deciding what the platform should do before anyone changes it. It produces direction, priorities, and a view of which investments will return value and which will add maintenance without helping the business. A buyer needs consulting when the org exists but the leadership team cannot agree on what it is for, when several build requests compete for the same administrators, or when a previous project delivered features that nobody uses. In those cases a build commissioned now would encode the same disagreement, only in configuration.
Consulting is the wrong first step when the direction is already clear and the work is a defined change to a known process. A buyer who only needs a new field on a page layout does not need a strategy exercise, and a provider who proposes one for that purpose is adding cost without adding insight. The skill for the buyer is to tell the two situations apart before the request is written.
Salesforce consulting is not a single question. It covers several distinct ones, and each produces a different kind of output. The table sets out the main questions a buyer usually brings, the decision each one informs, and where to read further on that question.
| Question on the table | Decision it informs | Where to look next |
|---|---|---|
| Which Salesforce investments should we fund over the coming period? | Priority and sequencing across initiatives | Salesforce strategy and roadmap development |
| Where does revenue leak between lead, opportunity and order? | Which sales steps to redesign or automate | Sales process optimization and automation |
| Is our existing org healthy enough to extend? | Whether to fix, extend or rebuild | A review of configuration, reports and a sample of records before anything is extended |
| Which systems should Salesforce exchange data with, and who owns each flow? | Integration boundaries and ownership | Salesforce integration architecture |
A buyer does not need to answer all four questions at once. The sensible order is usually the one that opens up the others. Direction comes first when priorities are contested. Process analysis comes first when the business does not agree how a stage works. A health review comes first when nobody trusts the org enough to decide on anything built inside it.
A consulting output is only useful if a decision-maker can act on it without a second meeting to interpret it. The most useful outputs are short and specific. They include a current-state summary that names the processes in use and the objects that support them, an options appraisal that compares the candidate changes against the same criteria, a set of priorities with the reasons for their order, and a list of the decisions that the client must take, each with an owner and a date by which the decision is needed.
The options appraisal deserves particular attention. Each candidate change should be judged on the value it returns, the effort it demands from internal staff, the data it depends on, the other changes it blocks or enables, and the risk it introduces to live users. A change that scores well on value but depends on data that does not yet exist should be scheduled after the data work, not before it. Presenting options side by side in this way prevents the common pattern in which the loudest request becomes the first project by default.
Consulting does not normally include the build. A buyer who expects a provider to proceed directly from the appraisal to configuration should agree that transition in writing, including who approves the build scope and what evidence will show that the build met the direction set in the consulting output.
The handover from consulting to build is where many programs lose momentum. A strategy document that is praised in a steering meeting and then filed does not change the org. The handover works better when each priority in the consulting output carries a defined acceptance condition, a named business owner and a description of the first build increment. Build work that cannot be traced back to a priority should be questioned, because it is the usual route by which scope grows unnoticed.
Consulting should also end with a short review of the assumptions it relied on. Typical assumptions concern the volume of records, the number of active users, the way sales territories are assigned and the systems that must remain in use during the transition. If an assumption later proves false, the buyer should know which priorities it affects. A consulting output that records its own assumptions is more trustworthy than one that presents every conclusion as settled.
Consulting depends on access to people who make and live with the decisions. Sales leaders, service leaders, finance representatives and the administrators who run the org each see different parts of the process, and their views will not always match. A good engagement asks each group what it needs from the platform, what it currently works around, and what it would stop doing if the system were more reliable. The differences between those answers are often the most valuable findings, because they show where a single priority will not satisfy everyone.
The client should choose one accountable executive for the consulting work. This person does not need to know the platform in detail, but must be able to resolve disputes between functions and must commit time to the review meetings. Without that role, consulting produces a list of options that each function interprets to its own advantage. Where the business also runs ServiceNow, the Salesforce direction should be read next to the strategic IT roadmap work for ServiceNow, since shared processes and shared budgets can make the two roadmaps depend on each other. Buyers who move from direction into detailed scoping can read about needs assessment and discovery as the stage that follows.
No. The scale of the question matters more than the size of the company. A smaller business with one contested sales process and a tangled set of automations may need a clearer direction more than a large business with a stable, well-documented org.
A useful current-state view usually requires read access to configuration, reports and a sample of records. Consulting that avoids the org entirely tends to describe the process as the leadership team imagines it, which is often different from how the system is used.
Disagreement is a finding, not a failure. The consulting work should show where the disagreement lies, what each position depends on, and which decision the executive sponsor must make to move forward. Pushing a contested priority into the build will not resolve it.
Before you request consulting, write down the decision that is currently stuck, the people who disagree about it, and the evidence each side relies on. That short note will show whether you need direction, process analysis or a health review first, and what output would let you act on the answer.
A Salesforce optimization consultant reviews how an existing org is really used, finds the configuration, data and process problems that cost users time, and ranks the fixes by value and effort. Judge one by what they ask to see first: live automations, reports and a sample of records, not a product demonstration.
The first request tells you most. A consultant who asks for the list of active flows, validation rules, duplicate rules and scheduled reports, plus read-only access to a sample of records, is going to work from evidence. One who starts with a slide deck of best practices will describe a generic org that does not exist in your business.
Process improvement work follows a similar test. The useful version maps a single stage, such as lead qualification or quote approval, with the people who perform it, then compares that map with what the automations actually do. The gaps between the two are the findings. Where the consultant never speaks to the users, the review ends up describing the configuration rather than the work.
The output should also say what to stop doing. Retiring an unused flow or merging two overlapping record types often saves more administrator time than any new build, and it makes the later sales process optimization and automation work easier to scope. Once the priorities are agreed, ongoing upkeep belongs with Salesforce support and maintenance so the cleanup does not drift back.
It looks at automations, page layouts, validation and duplicate rules, reports, permission sets, integrations and data quality, then compares them with how users actually work. The result is a ranked list of fixes with an owner for each, not a list of features.
An admin builds a flow to meet a request. A flow consultant first asks whether the request is still needed, which existing flows overlap with it, and what the new one does to run order and error handling. The consulting value is in the audit and design, not the click work.
Typically no. A review that edits the org while it is still diagnosing makes its own findings unreliable. Changes should follow an approved priority list, and each should be built through the normal Salesforce automation and workflow process with a named approver.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.