How to prepare for Salesforce discovery: a client-side guide

To prepare for Salesforce discovery, name a sponsor who can make decisions and book time with the people who run each process. Then collect evidence before the first workshop. That means process notes, the reports people really open, field lists or exports, connected systems, your license list and user complaints. Well-prepared clients spend workshop time deciding, not hunting for information, and leave with a scope they can trust.

What is Salesforce discovery, and what should it leave you with?

Discovery is the opening phase of a Salesforce project. Your team and the partner document goals, current processes, pain points, data, integrations and constraints. The partner then turns them into requirements, a proposed design and a realistic scope.

Treat it as a phase with deliverables, not a series of friendly meetings. By the end you should hold written artifacts that someone outside the project could read and understand. A solid discovery produces the following:

• Requirements: numbered, prioritized statements of what each team needs, each traced back to a workshop or a named person.
• Process maps: current and future versions of each in-scope process, with handoffs and approvals marked.
• A data inventory: every source system, the objects and fields that matter, rough record volumes and known quality problems.
• An integration list: each connected system, what moves in which direction, how often, and who owns it.
• Scope and backlog: what goes into the first release, what waits for later, and what is explicitly out.
• A refined estimate: the statement of work or estimate adjusted to what was actually learned, with assumptions written out.

If any of these is missing at the end, ask why before you approve the next phase. Gaps here tend to resurface later as change requests.

Who from your organization should take part, and at what point?

You need five kinds of people, but not all of them in every session. Bring each group in when its knowledge is needed, and protect the time of the people who run the business.

Name one internal project lead as well. That person books rooms and calendars, chases open questions and keeps the decision list current. Without that role, follow-ups drift between workshops and the partner fills the gaps with assumptions.

Keep the sponsor's involvement short but real. A sponsor who appears only at kickoff cannot resolve a disagreement between sales and finance halfway through.

What should you collect before the first workshop?

Gather evidence of how work really happens, not how the policy manual says it should. Real reports, real exports and real complaints shorten discovery far more than polished slide decks.

• Current process documentation, even rough: flowcharts, onboarding guides, checklists or photos of whiteboards.
• Sample reports people actually use, including spreadsheets someone rebuilds by hand on a schedule. Note who reads each one and what decision it informs.
• Data exports or field lists from each system that holds customer records, with a note on which fields are reliable.
• An integration inventory: every system that sends or receives customer data, the direction of flow and the technical owner.
• Your current license list and installed packages, if you already run Salesforce or another CRM.
• A pain-point list collected from users, in their words, with a rough sense of how often each problem bites.

Ask users directly for pain points rather than relying on managers to summarize them. A short survey or a few ten-minute conversations usually surface problems leadership has never heard about.

How should each department get ready for its workshops?

Each function should arrive with its own examples, reports and open questions. The partner leads the session, but your team decides what it covers.

Preparation differs by department because each one has a different stake in the system. These are the points each group should think through before its sessions:

• Sales: how a lead becomes a customer, which stages exist in practice, how forecasts are built and who owns an account when territories overlap.
• Service: how requests arrive, how they are routed and escalated, what response commitments exist and where agents look for answers.
• Marketing: which campaigns and lists matter, where consent is recorded, and which handoff to sales most often breaks.
• Finance: how quotes become invoices, which system holds the authoritative revenue figures, and which figures must match between systems.
• Operations or delivery: what happens after the sale, which fields downstream teams depend on and where orders or projects stall.

Ask each team to pick two or three recent examples, including one that went badly. Walking through a real account or case keeps the conversation concrete and exposes exceptions early.

Which decisions must be settled before discovery closes?

Discovery should end with the choices that shape the design already made, not deferred to the build. Open decisions at this point become rework later.

• What is in the first release and what is deliberately postponed.
• Which system owns each shared record, such as accounts, products and pricing.
• How much historical data moves, and what is archived or left behind.
• Who can see what: the broad visibility model between teams, regions or business units.
• Which integrations are required at launch and which can wait.
• How success will be measured, and who will report on it after go-live.

Write each decision down with an owner and a date. If a question genuinely cannot be answered yet, record it as an open risk with a deadline rather than letting it sit quietly.

What are the red flags in a partner's discovery process?

Watch for a discovery that confirms a scope decided in advance rather than testing it. A partner who never looks at your data or talks to your users is guessing.

• No data review: nobody asks for exports, field lists or record counts before proposing a design.
• No user interviews: every session involves managers only, and front-line staff are never consulted.
• Scope fixed before discovery: the deliverables list matches the sales proposal word for word, with no adjustments.
• Generic outputs: requirements that could describe any company, with no reference to your processes or terminology.
• No written decisions: workshops end with good conversation but no notes, owners or open-question list.
• Integrations waved through: connected systems are listed but nobody asks about volumes, errors or ownership.

These signs do not always mean a bad partner, but each one deserves a direct question. Our guide to a Salesforce statement of work explains how to hold a partner to what discovery found.

What belongs on a discovery prep checklist?

Use the table below to track readiness. Each line has an owner on your side and a clear sign that it is done.

How long does discovery usually take, and what stretches it?

Discovery length scales with the size and messiness of the project, not with Salesforce itself. A focused project with one team moves quickly; a multi-department program with several integrations needs considerably more time.

Several factors lengthen or shorten it:

• The number of departments, business units and regions involved.
• How many systems must connect to Salesforce, and how well they are documented.
• The volume and condition of data being migrated.
• Whether an existing org must be assessed before new work is designed.
• How quickly attendees are available and how fast decisions get made.
• Regulatory or security reviews that must sign off on the design.

The last two are the ones clients control. A partner cannot run a workshop your process owners cannot attend, and a scope cannot close while a key decision waits on one executive's calendar. Ask your partner for the drivers behind their proposed schedule, not just a date.

What should you do once discovery wraps up?

Review the deliverables line by line, fix anything that misstates your business, then approve scope formally. Only after sign-off should design and build begin.

• Circulate the requirements and process maps to the people who described them, and ask for corrections.
• Compare the refined estimate against the original and ask the partner to explain every significant change.
• Confirm the backlog order with the sponsor, so later requests have a clear place to land.
• Update the statement of work or change order so it reflects the agreed scope and assumptions.
• Keep the same internal team engaged, since design reviews and testing need the people who attended discovery.

Make sure you own the outputs. Discovery documents are useful long after launch, for training new admins, planning later phases or briefing a different partner. For how discovery fits into the full sequence of phases, see our Salesforce implementation guide.