September 8, 2023
An advisory engagement is a paid piece of thinking that you buy before you buy any building. Salesforce advisory services produce a decision, a scope, and a plan rather than a working org. That distinction matters because the two things are sold together, priced differently, and judged by completely different standards.
Here is how it usually goes wrong. A company signs a six-week discovery with a partner. Weeks pass. Workshops happen. A slide deck arrives. The deck says the company should modernize its data model and improve adoption. Nobody disagrees. Nobody can act on it either. No object was named. No integration was mapped. No number was attached. Six weeks of budget bought a summary of what everyone already knew.
This guide treats advisory as a purchase. You will see what separates it from delivery work. You will see which items to write into the statement of work. You will also see what good output looks like. You will also see when to skip advisory entirely and start building.
Salesforce advisory services sell judgment. A partner reviews your org, your process, and your goals, then tells you what to do next and in what order. The output is a set of decisions someone can hand to a delivery team.
Good advice answers the questions your team cannot settle alone. Should this live in Sales Cloud or a custom object? Do we fix the data model before adding AI, or after? Is the current org worth keeping? Those questions cost a lot to get wrong and little to ask well.
Buy advice when a wrong decision would cost more than the advice. Rebuilding a quoting model in year two costs far more than designing it well in year one.
Most partners sell both, and most proposals blur the line. Keeping them apart on paper protects you. Each one is judged by a different test. Delivery is judged by whether the thing works. Advice is judged by whether the plan holds up when a builder reads it.
| Dimension | Advisory engagement | Delivery engagement |
|---|---|---|
| What you get | Decisions, scope, and a plan | Working configuration and code |
| Main output | Documents your team owns | A deployed org |
| Typical length | Two to eight weeks | Three months and up |
| Who does the work | Architect and business analyst | Developers, admins, QA |
| Your time needed | Several hours a week from two owners | Testing, training, sign-off |
| How to judge it | Can a builder pick it up and start? | Does it work in production? |
| Fails when | Findings stay at theme level | Scope creeps and testing is skipped |
| Right first step when | The path is genuinely unclear | The scope is already agreed |
Ask which one you are buying before you ask the price. A single blended fee makes it hard to tell whether either part was any good.
This is where most engagements fail, and it is easy to prevent. Name the artifacts in the contract. A partner who will not commit to named documents is selling workshops.
Everything below should be usable by someone who was not in the room. That is the test. If a developer joining next month cannot pick it up and start, it is not finished.
| Deliverable | What good looks like | What a weak version looks like |
|---|---|---|
| Current-state review | Named objects, flows, integrations, and where each one breaks | “The org has accumulated technical debt” |
| Target design | Object model, ownership, and sharing decisions written down | A future-state diagram with cloud logos |
| Gap list | Each gap tied to a business consequence and a rough size | A themed list of improvement areas |
| Sequenced backlog | Ordered items with effort ranges and dependencies | A three-phase timeline with no items |
| Integration map | Every system, direction, volume, and failure mode | A box-and-arrow picture |
| Risk register | Named risks with owners and a mitigation each | A slide titled “Key Risks” |
| Decision log | What was decided, by whom, and what was rejected | Nothing written down |
Notice what is missing from that list. There is no strategy deck, no maturity score, and no vision statement. Those get made, and they are fine. They are not what you paid for.
Scope the work by the decisions it must settle. Do not scope it by the weeks it runs. Write down the three or four questions you need answered, and let the partner size the work against those.
Two to four weeks is enough for a single-cloud org with one clear question. A multi-cloud org with integrations and a migration call takes longer. A partner who promises that in ten days is guessing.
Watch for scope that drifts into build work. Once the team configures anything beyond a throwaway prototype, you are paying advice rates for build work. Practitioner discussion on Forcetalks shows how often that line gets crossed quietly.
Read the statement of work as if you will have to enforce it. Most bad outcomes trace back to a document that promised effort, not output.
Get the artifact list written in by name. Add a rough page or item count where that helps. Get a clause that says what counts as complete. Get a named lead architect with a stated share of their time. Senior people are often sold and then swapped.
Ask who owns the output. You want full rights to reuse every document, even with a different partner. A firm that fights that clause is protecting its next contract, not your project. Community threads on Salesforce Ben cover the partner-side view of these terms.
Ask whether the fee is credited against the build if you stay with the same partner. Many firms will do it, and almost nobody asks.
The answer tells you something either way. A partner who credits the fee is confident the plan will earn the next contract. A partner who refuses may just price the two lines apart. That is fine. You now know the advice has to stand on its own.
Advisory is not always the right first spend. A firm that says otherwise every time is selling a product.
Skip it when the scope is small and already agreed. Adding a field or one report does not need a roadmap. Skip it when your team already holds the answer and only needs hands to execute.
Skip it too when the real blocker is political, not technical. If two teams cannot agree who owns the account record, no document will settle it. Settle that question in-house first. Then bring in a partner to design around your answer.
You can usually tell within two weeks. The warning signs are consistent across projects.
The workshops keep covering ground you already covered. Nobody has asked to see your metadata, your integration list, or your last release notes. The team asks what you want instead of telling you what they found. Findings arrive as themes, not as named objects, fields, and flows.
The clearest sign is a draft you cannot argue with. A real review contains things you disagree with. It makes specific calls. A document everyone nods along to has decided nothing. Tutorials on SFDC Fanboy give a sense of the technical detail a proper review should reach.
We have worked in the Salesforce ecosystem since 2014. Our advisory work starts in the org, not in a workshop. We pull metadata, read the automation, and list the integrations. We check the release history before we book a session with your team.
Every engagement commits to named artifacts in the statement of work. You get a current-state review tied to named objects and flows. You get a target design, a sequenced backlog with effort ranges, and a risk register. You own all of it outright.
We also say when advisory is the wrong spend. Is your question small or already settled? We will tell you to skip the review and go straight to build through our Salesforce consulting services. Technical reference material on Salesforce Tutorial is useful background while you review any partner's findings.
One client is a global logistics real estate firm. They calculated key metrics across roughly two dozen linked spreadsheets. The process was slow and error-prone, and it stalled management decisions. The leadership team had held off on automating it.
Our engineers moved the calculation into Salesforce. Every metric and formula was rebuilt on the platform. The client checked the output against the original spreadsheets before switching over. They now use the Salesforce version only. They reported saving around 24 hours per cycle.
It can be. That is why the artifact list matters. An engagement that hands you documents you own and can give to any builder is advice. One that produces a proposal is a sales process.
Expect several hours a week from a business owner and a technical owner. A partner who needs no time from you is not looking hard enough.
Yes. It is a fair way to keep the advice honest. Make sure the output-ownership clause allows it before you sign.
Ask for the evidence and the alternative. A rebuild call should carry the cost of not rebuilding. It should also offer a phased option.
Advisory earns its fee when it turns an open question into a plan you can build from. The value sits in the artifacts, not the workshops. Name them in the contract and judge the work against them. If the output cannot be handed to a developer who was never in the room, it was not finished.
Minuscule Technologies works on this from the engineering side. We read your org before we read your slides. Every finding ties to named objects, flows, and integrations. You get a sequenced backlog your team owns outright. We also tell buyers plainly when an assessment is not worth their money.
If you are weighing an advisory proposal right now, bring it to Minuscule Technologies for a second read. We will tell you what the statement of work is missing and what the output should hold. Want to compare this route against a full build engagement? Our guide to Salesforce consulting services sets out the wider picture.
You've seen what's possible. Now, let's make it happen for your business. Whether you need an end-to-end Salesforce solution, a complex integration, or ongoing managed services, our team is ready to deliver.
Schedule a Free Strategic Call
