Most Salesforce programmes go wrong before configuration starts. Here is the pre-build checklist we use to remove scope ambiguity early.
Start with the decisions, not the objects
Every Salesforce build is a series of decisions about how your business sells and serves. If those decisions are not written down before configuration starts, they get made silently inside flows and validation rules where nobody can review them.
We open every engagement by listing the decisions that must be settled: what counts as a qualified opportunity, who owns an account after handover, when a record becomes read-only, and which numbers the leadership team will act on each week.
Agree the reporting output first
Design the dashboard you want on day 90, then work backwards to the fields and stages that make it possible. This one step removes most of the 'we need another custom field' requests that appear mid-project.
It also gives you a ruthless test for scope: if a field or automation does not serve an agreed report or an agreed user action, it waits for phase two.
Map the data you actually have
Legacy data quality is the single most common cause of a delayed go-live. Profile your existing records early, duplicates, blank owners, inconsistent country values, closed deals with no amount, and decide what gets cleaned, what gets migrated as-is, and what stays in the old system as an archive.
Write the migration rules down and have someone from the business sign them off. It is far cheaper than discovering the problem during user acceptance testing.
Plan adoption as part of the build
A technically perfect org that nobody uses is a failed project. Identify the people who will champion the system in each team, involve them in design reviews, and build the training material from the real configuration rather than generic slides.
We aim for the first week after go-live to feel boring. That only happens when adoption work started in week one, not week ten.