One of the things that puts small businesses off starting a Salesforce project is not knowing what they are getting into. How long will it take? What will be expected of us? What actually happens between signing off on a project and going live?

Of course, the process varies depending on the scope and complexity of the engagement, but most Salesforce implementations follow a recognisable set of phases. Understanding what happens at each stage, and what is expected from you as a customer, makes the whole thing considerably less daunting and significantly increases the chance of a successful outcome.

Phase 1: Pre-Sales Discovery

Before any configuration begins, a good consultant will want to understand your business. This means getting clear on how you currently operate, what problems you are trying to solve, and what success looks like from your perspective.

Discovery typically involves a series of conversations, sometimes with the project sponsor, sometimes with the end users who will use the system day to day, and sometimes with both. The hope is to have a clear picture of your requirements, your processes, and the decisions that need to be made before build begins.

What is expected of you at this stage: time and honesty. The more openly you can talk about how your business actually works, the different scenarios and possible outcomes for processes, the better the end result will be. Discovery is not an exam. There are no wrong answers. It is the foundation the rest of the project is built on.

Phase 2: Scoping and Sign-off

Once requirements are understood, the consultant will produce a written scope of work. This sets out exactly what will be built, what is not included, how long it will take, and what it will cost.

This is an important document. It is worth reading carefully before signing off, and worth asking questions if anything is unclear. A clear scope protects both parties. It means you know what you are getting, and it means the consultant knows what they are delivering.

Things that commonly get missed at this stage: data migration requirements, integrations with other systems the consultant was not aware of, and the specific processes that are particular to your business. A good discovery process should surface these, but it is worth thinking about them proactively.

What is expected of you at this stage: review the scope carefully and flag anything that looks wrong or missing before work begins. Changes to scope mid-project are almost always more expensive and disruptive than getting it right upfront.

Phase 3: Design, Build and Configuration

This is where the work happens. The consultant begins by compiling their internal design documents. The design documents inform how they configure Salesforce based on the agreed scope, building out your objects, fields, page layouts, automation, reports, dashboards, and any other components included in the project.

For most small business implementations, this phase does not require much from you on a day to day basis. You will not need to attend daily standups or review work in progress every day. What you will need to do is remain available to answer questions when they arise, because they will arise regularly. Even with a thorough discovery, decisions come up during a build that need input from the customer.

What is expected of you at this stage: availability. Not a lot of it, but responsive availability. If a question sits unanswered for a week, it can delay the entire project. A target of responding to build queries within one to two working days is a reasonable expectation to agree upfront.

Phase 4: User Acceptance Testing (UAT)

Before go-live, you and your team will be given access to the configured system to test it. This is called User Acceptance Testing, or UAT. The purpose is to verify that what has been built matches what was agreed, and to catch any issues before the system goes live for real.

UAT is one of the most important phases of the project and one of the most commonly underestimated by customers. It requires the people who will actually use the system to work through it methodically, trying out the key workflows, entering test data, and checking that the system behaves as expected.

Feedback from UAT is typically raised as a list of issues or change requests. Some of these will be bugs to fix. Others may be new requirements that were not in the original scope, which will need to be scoped and priced separately before being addressed.

What is expected of you at this stage: genuine engagement. Not a quick click around followed by a thumbs up. The time to find problems is during UAT, not after go-live. A simple test script that walks your team through the key scenarios is worth producing before UAT begins, even if it is just a list of things to try.

Phase 5: Training

Before going live, the team will need to be trained on the system. Good training is done in context, using your own data and your own processes where possible.

Training should cover the day to day tasks each user needs to perform, not everything Salesforce can theoretically do. Keeping it focused on what the team actually needs to do on a typical day is far more effective than a comprehensive tour of every feature.

What is expected of you at this stage: get the right people in the room. Training is most effective when it includes the people who will actually use the system, not just managers or project sponsors. If your whole team is going live on day one, your whole team should be in the training session.

Phase 6: Go-live

Go-live is the point at which the new system becomes the live system. Depending on the project, this might involve migrating data from a previous CRM or spreadsheet, switching off old tools, and starting to use Salesforce as the day to day record of your business.

If discovery, build, UAT, and training have all gone well, go-live should feel relatively straightforward. The system is ready, the team knows how to use it, and the work begins.

What is expected of you at this stage: commitment. The hardest part of go-live is not technical. It is getting the team to actually use the new system rather than defaulting to old habits. Having clear expectations from day one about what gets logged, how the pipeline is managed, and how reports will be used makes a significant difference.

Phase 7: Post Go-live Support and Review

Most good implementations include a short period of post go-live support. This is typically a few weeks during which the consultant remains available to answer questions, fix any issues that surface in real use, and make minor adjustments as needed.

A check-in two to four weeks after go-live is also worth scheduling. This is a good opportunity to review how adoption is going, capture any requirements that have emerged now the team is working in the real system, and agree what, if anything, should be addressed in a follow-on phase.

How long does the whole process take?

For a standard Sales Cloud Quick Start, the typical timeline from kickoff to go-live is two to four weeks. Larger or more complex projects naturally take longer.

The biggest variables that affect timeline are the speed of decision making on the customer side, the complexity of data migration if required, and how smoothly UAT goes. Projects where the customer is responsive, engaged, and has done the work to get their data in reasonable shape before the project begins almost always run faster and smoother than those where these things are left until mid-build.

What makes a Salesforce project succeed?

In our experience, the projects that go well have a few things in common regardless of size or complexity:

The projects that struggle tend to have the opposite: unclear requirements, slow decision making, and a desire to include everything from day one that leads to scope creep, extended timelines, and reduced adoption.

Thinking about starting a Salesforce project?

Book a free 30-minute call and we will walk you through what it would involve for your business specifically, honestly and without obligation.

Book a free call
Back to all articles