When External Consulting Pays Off, and When It's a Waste
A Salesforce consultant isn't needed to answer questions solvable with documentation or the expertise of an experienced admin. They become essential when decisions are costly to reverse, cross departmental boundaries, or when the organization lacks a neutral party to arbitrate.
Five triggers justify external consulting:
- Platform Decision — Is Salesforce even the right fit, and what are the alternatives?
- Architectural Decision That's Costly to Reverse — Core data model, single vs. multi-org, source of truth.
- Internal Departmental Disagreement with no natural arbitrator.
- Stalled Project requiring a politically un-involved party to diagnose the issue.
- Ahead of a Major Commercial Commitment — Before signing a multi-million-dollar proposal, an independent opinion is relatively inexpensive.
What doesn't justify consulting: adding fields, building reports, daily operational questions. These are an admin's responsibilities, and consulting that gets pulled into these tasks quickly becomes expensive staff augmentation.
Three Roles Often Confused
| Role | Question It Answers | Time Horizon | When Hired Incorrectly, You Get... |
|---|---|---|---|
| Consultant | What's the right thing to do, and in what order? | Months to years | Strategy instead of a solution to a problem |
| Architect | How to implement it without creating debt | The project and system | Detailed design for an undefined problem |
| Admin | How to operate and maintain day-to-day | Weeks | A point solution that solidifies a major decision |
The common pitfall is the third row: an architectural decision effectively made by an admin because it originated as a small request.
What You Must Get From a Consulting Process
A consulting process that ends with a summary presentation is one you can't act on. The deliverables worth demanding in writing, before signing, include:
- Decision Document — For each decision: the question, alternatives considered, recommendation, rationale, and implications if a different path is chosen.
- Assumptions and Dependencies — What the consultant assumed without verification, and what happens if the assumption is incorrect.
- Risk Map focused on your organization, not a generic list.
- Recommended Sequence of Actions with dependencies, not a wish list.
- What Not to Do — The negative recommendation is often the most valuable part, and it's almost always missing.
The last point is a good quality test: a consultant who can say "don't build that now" is selling a decision, not hours.
How to Vet a Consultant Before Engaging
The questions to ask aren't about certifications but about their thought process:
- Describe an architectural decision you recommended and later regretted. What did you learn?
- In what scenario would you advise against using Salesforce?
- How do you decide between configuration and development?
- What do you need from an organization for the consulting engagement to succeed, and what happens if you don't get it?
- Who in your organization continues to maintain the deliverable after you leave?
A broader set of questions for vetting vendors can be found in our Guide to Questions Before Choosing a Salesforce Integrator.
Conflicts of Interest — Not Always Bad, Always Needs Disclosure
A vendor who consults and then implements isn't necessarily problematic; sometimes, it's the most efficient approach because knowledge isn't lost in transfer. The problem begins when the recommendation influences the scope of work for that same party, and there's no balancing mechanism.
Three simple balancing mechanisms:
- Separate pricing for the consulting phase, not contingent on continuation.
- The organization's right to issue an RFP after the consulting phase, with deliverables owned by the organization.
- A requirement that every recommendation be presented with a cheaper alternative and the reason it was rejected.
The third is the most effective and generates the most productive discussions.
Illustrative Example: Publicly Owned Infrastructure Company
This scenario is hypothetical and for illustration. An infrastructure company considered a large CRM project to manage public inquiries and governmental agency requests. Two vendors proposed an architecture with separate Salesforce orgs for each of the two audiences, citing regulatory information separation.
The external consultant hired reviewed the regulatory requirement itself and found that it mandated access separation, not system separation. This conclusion completely changed the commercial picture: one org with a meticulous exposure model instead of two environments requiring synchronization and double maintenance.
The most valuable deliverable from the process wasn't a recommendation on what to build, but proof that the underlying assumption of both proposals had not been vetted.
How This Connects to Commercial Decisions
A good consulting opinion changes what you ask of vendors, so it should come before, not after, proposals. From there, the decision moves to two levels: choosing the appropriate pricing model for the remaining level of uncertainty, as detailed in our Salesforce Project Pricing Models Guide, and comparing the proposals received, as detailed in our Guide to Comparing Proposals.
The criteria for vetting the company that will perform the actual work are summarized in our Guide to Choosing a Salesforce Implementation Company.
Quick Test Before Engaging a Consultant
Answer three questions: What decision do you need to make, who in the organization will approve it, and what will happen if you make it incorrectly? If the answer to the third question is "we'll fix it cheaply later" — you likely don't need a consultant. If the answer is "we'll rebuild" — that's precisely where external consulting pays for itself.