What Needs to Be on the Table the Day After Discovery
CRM discovery is measured by actionable deliverables, not by the number of meetings. If, at the end of this phase, the project manager still can't build a work plan, the developer doesn't know which object holds the process, and the data manager doesn't know where the customer originates—the discovery isn't complete, even if the presentation was approved.
This guide defines seven deliverables. Each has a readiness criterion: a single question answerable with a yes or no. Anyone who answers "maybe" to more than two of these is entering the build phase with an identifiable, quantifiable risk. An overview of the post-discovery stages is available in the Salesforce Implementation Guide.
Deliverable 1: Decision-Level Process Map
This isn't a flowchart of every click, but a map of decision points: who decides, based on what information, what happens in each branch, and what occurs when no decision is made. Most failures in CRM projects aren't in the main path but in the branches—a frozen deal, a customer returning after two years, or an inquiry opened by the wrong customer.
Readiness Criterion: You can take a real deal from the last month and trace it end-to-end on the map without encountering a gap.
Deliverable 2: Business Glossary
This is the most underestimated deliverable, and its absence is the most costly. "Customer" means one thing in finance and another in sales. "Active Project" means one thing in operations and another in management. As long as definitions aren't written down, every report sparks an argument.
For each term, the glossary should include: a one-sentence definition, the Salesforce entity representing it, the field that determines its status, and the department that owns the definition.
Deliverable 3: Decided Core Data Model
During the discovery phase, you don't build a full ERD, but you do decide on four questions that are expensive to change retroactively:
- Whether business activity resides on an Opportunity, a custom object, or a combination, and their relationship.
- Whether an Account represents a legal entity, a physical site, or a buying group—and how hierarchy is managed.
- What is the unique key identifying a customer between Salesforce and core systems.
- Which historical data enters the system and which remains at the source.
Readiness Criterion: You can draw the five main objects and their relationships on a whiteboard without opening a file.
Deliverable 4: Permissions and Visibility Model
The permissions model is derived from the question of who should not see what, not from who needs to see what. These two questions seem identical but lead to opposite architectures. A good discovery defines the organizational default for each major object, the extension mechanism, and cases requiring exceptional visibility.
| Question | What to Check in Discovery | Why It's Expensive to Change Later |
|---|---|---|
| Object Default | Private, Public Read, or Read/Write | Affects the entire sharing mechanism built upon it |
| Hierarchy Structure | Does the role hierarchy reflect management or geography | Changing requires recalculating access for all records |
| Cross-Unit Visibility | Shared teams, manual sharing, or criteria | Determines if dedicated logic is needed |
| Sensitive Data | Which fields are restricted and for whom | Retroactive changes expose information that has already been viewed |
Deliverable 5: System Map and Single Sources of Truth
Every central entity must have a single, declared source of truth and a clear synchronization direction. Discovery that leaves two systems "updating each other" creates conflicts that will only emerge in production. The map should also include frequency and tolerance for delay: a sales process can live with a five-minute sync, but credit control usually cannot.
Deliverable 6: Acceptance Criteria for Core Processes
This connects discovery to testing. Each core process requires three to five acceptance criteria phrased as an observable outcome: "After closing a deal, an order is created in the core system within five minutes, with the same customer ID." Such a phrasing is a requirement, a test script, and a definition of completion. Without it, the UAT phase devolves into a cycle of design comments.
Deliverable 7: Baseline Metrics Before Change
You can't prove improvement without baseline measurements. During discovery, select three to five metrics and measure them in the current state, even if manually and roughly. The selection of metrics and how to connect them to business value is detailed in the ROI and Success Metrics Guide.
Illustrative Example: Private Clinic Network
The following scenario is hypothetical and for illustrative purposes only. A network of eight clinics undertook a CRM project to centralize patient inquiries. During discovery, it was found that two clinics defined "returning inquiry" differently: one counted every call, the other only new topics. This difference seemed semantic but determined whether the system needed one Case object with hierarchy or two separate objects, and it defined all management workload reports.
The team didn't resolve the disagreement in the document. They noted an open decision, assigned ownership at the VP of Operations level, and set a deadline before construction began. The decision was made within two weeks, and the model was built once. Had the decision been postponed, it would have been discovered during UAT—after screens and reports had already been built based on a faulty assumption.
Warning Signs of Shallow Discovery
- The document describes screens and fields but doesn't describe what happens when a process fails.
- There are no documented decisions for which alternatives were considered.
- All requirements are high priority.
- There is no person's name next to any process, only a department name.
- The number of fields requested on one screen exceeds twenty-five without anyone checking who populates them.
The connection between shallow discovery and subsequent project failure patterns is detailed in the Common Mistakes Guide, and its impact on timelines is explained in the Salesforce Project Timeline Guide.
When Replacing an Existing System
When the project replaces a legacy CRM, discovery gains an additional task: deciding what not to migrate. A legacy system accumulates fields, automations, and reports that no one uses anymore, and blindly copying them imports old technical debt onto a new platform. The recommended sequence of actions for such a transition is detailed in the Replacing CRM with Salesforce Guide.
How to Know When You Can Start Building
Review the seven deliverables and ask the readiness question for each. If six out of seven answer yes, you can start with a first wave while managing the seventh gap as a documented risk. If three or more answer "maybe," it's better to extend discovery by two weeks than to discover the gap after three months of work have been built upon it.
The natural next step is to translate these deliverables into a wave plan, with an explicit decision on what goes into the first wave and what is consciously deferred.