What to agree before a Salesforce build starts

When a Salesforce project disappoints, the build is often not the problem. The problem is that the system was built to an understanding nobody wrote down. The sales director pictured one thing, the operations lead another, and the build team made sensible guesses in between. Each guess was reasonable. Added together, they produce a system that works and passes its tests, but still does not match how the business sells.

The fix is not more meetings. It is a short list of things you agree in writing before any configuration starts, plus a few checkpoints where you see the work before it is finished. This is the sequence we follow, and what you should expect to have at each step, whoever you work with.

1. A statement of work that names the outcome

Scoping should involve people from every function the system will touch, not just the project sponsor. The output is a statement of work covering four things: the technical solution, the timeline, the team and the cost. If any of the four is missing, you are agreeing to an estimate, not a project.

Read it for what it leaves out. A statement of work that lists objects and features but never says what the business will be able to do afterwards is describing activity, not an outcome.

2. Requirements your stakeholders have argued over

Requirements should come from a workshop with management and the people who will use the system, not from a questionnaire. The workshop is where disagreements come out: what counts as a qualified lead, who owns an account, when an opportunity is really lost. It is far better to settle those in a room than to discover them during user acceptance testing.

The result is a detailed requirements document. Your stakeholders should recognise their own processes in it. If they can’t, it isn’t finished.

3. A design you can check field by field

Before the build, the field-level and technical detail should be written into a design document. We call ours a Configuration Blueprint. It sets out what the build will deliver, down to individual fields.

Most sponsors skim this document. Don’t. It is the cheapest point in the project to change your mind, and it becomes the record your administrator relies on after launch.

A useful test: take one real deal from last quarter and walk it through the design on paper, from first enquiry to close. Every point where the deal doesn’t fit is a question to answer now, not after go-live.

4. Show-and-tells while the system is built

Feedback is cheapest while the work is still in progress. Expect regular progress updates and show-and-tells during development, so your team sees the system taking shape and can say “that’s not how we do it” early.

This is where the sponsor’s time matters most. The point is not a polished demo. It is to put half-built screens in front of the people who will use them every day.

5. An end-to-end test before you sign off

Before anything goes into production, the whole process should be demonstrated end to end for your team to test. Feedback is reviewed and built in, and only then do you sign off. Sign-off is a decision you make, not a date on a plan.

The checkpoints at a glance

Step	What you should have	Question to ask
Project scoping	A statement of work: solution, timeline, team and cost	What will the business be able to do that it can’t today?
Requirements mapping	A detailed requirements document	Did the people who will use the system help write it?
System design	A Configuration Blueprint	Does a real deal fit the design from start to finish?
Prototype development	Regular updates and show-and-tells	Have users seen it, not just the sponsor?
Prototype testing	An end-to-end demo and your sign-off	What changed after testing, and is it recorded?
System launch	Team training and support on standby	Who do users call when something is unclear?

After launch: training, support and the next phase

A system nobody has been trained on is a system people work around. At launch, every relevant user should be trained, and the delivery team should stay on standby for user and technical questions while new habits form.

After that, keep talking. Once the first phase is live, the useful question is what the platform should do next to support the next business goal. Treat that as a planned step, not a support ticket.

What this looked like for Push Energy

Push Energy, a renewable energy developer, had prospect and client data stored in different places and no standard sales lifecycle. We worked with the team to define its sales stages and the data to collect at each one, then built that path into Sales Cloud. Its projects often involved parent and child accounts, partners and several sites, so the design used account hierarchies, plus partner and site records, to give each project a proper structure.

Amit Oza, CFO of Push Energy, described the process like this:

“The project was managed in great detail and we knew exactly what we needed to input into the process at each point and we also had frequent update calls to inform us how the project was progressing.”

Amit Oza, CFO of Push Energy

Read the full Push Energy Sales Cloud case study.

If the full sequence feels like too much

Not every project needs every step at full weight. If you need a working CRM quickly, a Quick Start package captures and configures your core requirements, so your team is using and reporting in Salesforce as soon as possible. If you are not sure where to begin, a one-day CRM process mapping workshop is a smaller first step. Either way, the principle holds: agree what you are building before you build it.

See how we approach Salesforce consulting and implementation.

Next step

If a Salesforce project is on your list, talk it through with one of our consultants. We will help you work out what to agree before anything is built.