Salesforce separates Accounts from Opportunities and can be configured in many ways. The management problem is deciding which commercial changes need to become explicit, how they connect and what should remain visible after the deal closes.
An Account can hold the relationship context while an Opportunity represents a potential deal. That distinction is useful, but the business still has to decide which changes deserve an Opportunity, what happens inside an existing account, and how either connects to Delivery and operational systems.
Which changes belong to the ongoing customer relationship and which should become a distinct commercial object?
Are renewal, expansion, contraction, stakeholder change and new commitments explicit enough for management to act on?
Do custom fields and objects represent real management questions, or has the system accumulated structure without a shared meaning?
Can Delivery see the conditions, promises and uncertainty that matter after an Opportunity is won?
Can the same commercial relationship be connected reliably across Salesforce and the systems that hold work and money?
Do dashboards explain the commercial chain, or mainly report the objects already inside Salesforce?
If management is adding fields, automation or dashboards but still cannot explain why the business result moved, I work backwards from the decision that needs to be made. The question is what Salesforce needs to recognise - not how much more it can store.
Both products end with a written PDF deliverable.
Salesforce can accumulate years of objects, fields, flows, ownership rules and reports. Salesforce itself describes implementation decisions that once made sense but later prevent change as technical debt. In practice, a technically healthy org can still describe teams and processes the business no longer has.
That is not automatically a rebuild case. I separate useful complexity from inherited complexity, then ask which parts still support current management decisions.
A useful question: Which parts of the Salesforce model exist because the business needs them now - and which exist because they were built once?
The answer may be a clearer object/state model, process rule, handover, report, integration or no Salesforce change at all. Platform configuration or development is a later implementation decision.
Yes. I can diagnose and design around an existing Salesforce setup without assuming you need to migrate or rebuild it.
No. I start with the business problem and what management needs the commercial system to recognise.
No. The first conversation and Revenue Visibility Review can start from how the business works, how Salesforce is used and a small number of reports or screenshots where useful.
I research the company before the first call. No CRM export or admin access is needed to start.