A business owner had just signed a Salesforce consulting contract. She had imagined something like hiring a contractor to renovate her office: explain what you need, hand over the keys, and come back to a finished result. She would keep running the business. The consultants would build the platform.
Six weeks into the project, she was buried in workshop invites, requirements review sessions, UAT feedback requests, configuration decision approvals, and data mapping sign-off forms. Her sales director was spending four hours every Thursday in Salesforce process workshops. Her operations manager had been pulled into two separate data migration reviews.
She called her consulting lead: "I thought I hired you to take this off my plate."
The consulting lead's answer was honest: "We're building your business processes into a platform. We can't do that without you."
This is the gap that exists between what most business leaders expect from a Salesforce consulting engagement and what one actually requires. The confusion is not about competence - it is about transparency. This guide closes that gap by walking through what a Salesforce consultant does at each stage of a project, what they need from you, and what the entire engagement looks like from the inside.
A Salesforce consultant is not a developer who builds a system in isolation and hands it over finished. They are also not a project manager who coordinates a team you will never see. A Salesforce consultant is the person who translates your business - your sales process, your service workflows, your reporting requirements, your integration landscape - into a Salesforce configuration that works for your people and your operations.
That translation work requires your knowledge as much as it requires theirs. You understand your business. They understand Salesforce. The consulting engagement is the structured process of combining both. As SalesforceBen's guide on the consultant role notes, consultants carry out work that ranges from technical configuration through to the kind of listening and questioning that surfaces requirements a client did not know they needed to articulate. Both matter.
What distinguishes a partner-model consulting firm like Minuscule's Salesforce Consulting practice from a staff-augmentation arrangement is accountability for outcomes - not just effort. A consultant is responsible for the platform working after go-live, not just for completing the tasks in the project plan.
The first two weeks are almost entirely about listening and asking questions. A consultant runs structured discovery workshops with your team — typically two to four sessions covering sales process, service workflows, reporting needs, current data state, and integration requirements. They map your current state: how leads enter your system today, how deals are tracked, how cases are managed, what data lives where. They identify gaps between your current process and what Salesforce can support natively, and they flag where configuration will not be enough and custom development or integration work will be needed.
Behind the scenes, the consultant is also auditing any existing Salesforce environment (if you are not starting from scratch), reviewing your data in the source system, and beginning to draft the solution design document that will govern the entire build.
Access to the people who know your processes best - sales team leads, service managers, operations owners. Not just IT. The most important discovery input comes from the people who run the workflows daily, because they know the exceptions, the edge cases, and the workarounds that any system design must account for.
Discovery findings become a solution design document. This is the blueprint for everything that will be built - which objects will be used, how fields will be configured, what automations will be created, how the data model will handle relationships between accounts, contacts, and your industry-specific records. For complex environments involving ERP integration with SAP or PeopleSoft, the solution design includes the integration architecture: which system is authoritative for which data, how the sync will work, and what transformation rules apply.
The consultant presents this document in a design review session, walks through each decision and the reasoning behind it, and collects feedback. Changes made at this stage cost almost nothing. Changes made during or after build cost significantly more — in time, in rework, and in go-live delays. This is why design sign-off is one of the most important milestones in the project, and why consultants are deliberate about getting it right before any build begins. Minuscule's Salesforce Implementation process treats design sign-off as a hard gate — build does not start without it.
A clear review of the solution design from the people who will use the system. If the design shows a Lead-to-Opportunity process that does not match how your sales team actually qualifies leads, this is the moment to say so. After sign-off, changes to the data model or process logic trigger change requests.
This is where most of the technical work happens. In sprint cycles - typically one to two weeks each - the consultant builds the configuration against the signed-off design: custom objects, fields, page layouts, validation rules, automations (Flows, approval processes), reports, dashboards, and user profiles. For projects involving custom development, the Apex code and Lightning Web Components are being built in parallel. For integration projects, the API connections and data sync logic are being developed and tested in a sandbox environment.
The consultant runs demo sessions at the end of each sprint - showing completed functionality against the original requirements, collecting feedback, and incorporating changes before the next sprint begins. This iterative approach catches misalignments early, before they compound. A consultant who builds for eight weeks in silence and demos everything at the end is a warning sign: problems discovered late in a build are expensive to fix.
Attendance at sprint demos and timely feedback. The most common cause of project delays at this stage is slow feedback cycles — a consultant finishes Sprint 2 and waits three weeks for a review because the business stakeholders are unavailable. The project sits. The timeline slips. Stay engaged during build, even if it is only two hours per sprint for a review.
User Acceptance Testing (UAT) is the phase where your team tests the system against real business scenarios before go-live. The consultant writes UAT test scripts — step-by-step scenarios that walk users through key workflows - and supports the testing sessions. They log every defect found, triage them by severity, and fix critical defects before go-live while scheduling lower-priority items for a post-launch iteration.
Training runs alongside or immediately after UAT. This is not a generic Salesforce walkthrough — it is training specific to your configuration, your process, your data. A consultant who delivers generic Salesforce training rather than process-specific training is giving you a manual for a car that is not the one you drive. Minuscule's Salesforce Administration team ensures handover documentation and training materials reflect the actual org, not a default Salesforce instance.
User time for testing. UAT requires the people who will use the system daily to actually work through the test scripts, not rubber-stamp them. The bugs found during proper UAT are the bugs that do not surface in production in front of customers.
Go-live is a coordinated event, not a switch flip. The consultant manages the production deployment — migrating configuration from sandbox to production, running the final data migration, enabling user access, and monitoring the environment through the first days of live use. Hypercare is the two-week period immediately post go-live where the consulting team is on elevated support - responding to issues quickly, catching edge cases that UAT did not surface, and tuning configurations that behave differently at full production volume.
A clear internal communication plan so your team knows the system is live, what has changed, and who to contact with questions. The biggest go-live friction comes from users who were not adequately prepared and discover changes by accident.
Many businesses are surprised to discover that the consulting relationship they found most valuable did not end at go-live — it evolved. Post-implementation, a consultant's role shifts toward optimization: fixing what the first sprint of live use revealed, building the features that were descoped to hit the go-live date, responding to Salesforce's three annual platform releases, and expanding the platform as the business grows. This ongoing relationship is what Minuscule's Managed Services and Integration teams deliver — the same certified team that built the platform stays connected to it.
A consultant who does not run structured discovery before presenting a solution design has designed something for a generic business, not yours. A consultant who does not demo work at the end of each sprint is building without checking. A consultant who cannot explain why they made a specific design decision should not have made it. A consultant who treats go-live as the finish line and disappears during hypercare has handed you an untested system at its most vulnerable moment.
Good Salesforce consulting is transparent at every stage - about what is being built, why it is being built that way, what the risks are, and what you need to do to keep the project on track.
It depends on scope. A focused Sales Cloud implementation for a single business unit typically runs eight to twelve weeks from discovery to go-live. A multi-cloud implementation involving Sales Cloud, Service Cloud, and ERP integration typically runs four to six months. Projects involving data migration from a legacy system, complex custom development, or multiple integrated platforms run longer. A well-scoped project plan produced during the design phase will give you an accurate timeline before build begins.
More involved than most clients expect. Clients are responsible for providing access to the business stakeholders who know the processes being built into the system; reviewing and signing off on the solution design before build begins; attending sprint demos and providing feedback promptly; participating in UAT to validate that the system meets business requirements; and communicating the go-live to end users. A consulting team that does not ask for this involvement is building something that may not fit your actual business.
A Salesforce consultant designs solutions and configures the platform using declarative tools — page layouts, Flows, automations, reports, and dashboards. A Salesforce developer builds custom functionality using Apex code, Lightning Web Components, and Salesforce APIs when the business requirement exceeds what configuration can deliver. In practice, most professional consulting engagements involve both - a consultant designing the solution and developers building the parts that require code. The distinction matters because billing rates differ and scoping responsibilities are different.
Ask how they run discovery and whether you can see an example of a solution design document. Ask how they handle change requests during build. Ask what their post-go-live support looks like and who on the team will be available during hypercare. Ask for references from clients in your industry or with similar integration complexity. A consultant who cannot answer these questions clearly has likely not done the work often enough to have a consistent process.
This is handled through a change request process. A consultant documents the new or changed requirement, assesses its impact on the timeline and scope, and presents a change request for approval before any work begins on it. Change requests are normal - business requirements evolve. The professional response is to surface the impact honestly and get client approval, not to absorb undocumented scope and then deliver late with no explanation.
A Salesforce consultant does not take the work off your plate. They take the platform expertise off your plate - and replace it with a structured process that turns your business knowledge into a working Salesforce environment. The clients who get the most from consulting engagements are not the ones who hand over the project and disappear. They are the ones who show up to discovery sessions with honest information, review design documents before sign-off, attend sprint demos with real feedback, and treat UAT as a genuine test rather than a formality.
With 160+ certified Salesforce experts and 75+ enterprise projects delivered, Minuscule Technologies brings the full consulting lifecycle - discovery, design, build, UAT, go-live, and ongoing optimization - to manufacturing, automotive, BFSI, and field services clients. For environments that require SAP, PeopleSoft, and Denodo integration alongside Salesforce configuration, our team manages both sides of the connection as a single engagement. If you are planning a Salesforce project and want to know what to expect, talk to us before you sign anything.
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
