Salesforce Readiness Assessment
A structured look at whether your organisation is ready for a new Salesforce or marketing technology initiative, across six areas from business goals to team capacity.
Before a Salesforce project starts, most teams know what they want to build. Fewer know whether the conditions for building it are in place: clean enough data, a decision maker with time, consent records you can rely on, integrations that are documented, and people who will run the platform after launch.
The GeekMidst Salesforce readiness assessment is a short, structured set of questions that looks at those conditions. It is not a sales qualification form and it does not produce a score to be proud or ashamed of. It produces a picture of where your initiative is likely to stall, so you can deal with that before it costs time and budget.
An interactive version of the assessment is available on the Assessment page of this site. This page explains what it covers and how to read the outcome.
Who it is for
- Marketing and CRM leaders preparing a business case for Marketing Cloud Engagement, Marketing Cloud Next, Account Engagement or Data Cloud (now branded Data 360).
- Platform owners planning a significant change to an existing Salesforce org.
- Programme managers who want a neutral checklist before writing an RFP or statement of work.
The six areas it covers
Goals and ownership
Is there a measurable business outcome, a named executive owner and a product owner with time to make decisions every week?
Data and identity
Do you know which systems hold customer data, which identifier links them and how good that data is today?
→Org and platform health
Is the current org documented, with understood automation, sensible security and room to extend it safely?
→Integrations
Are source and target systems, their owners, their APIs and their error handling known and accessible?
→Consent and compliance
Can you show where consent is captured, stored and honoured, and has someone with authority confirmed the rules?
→Team and measurement
Who will run the platform after launch, and how will you tell whether the initiative worked?
What each readiness level looks like
| Early | Developing | Ready | |
|---|---|---|---|
| Goals | Broad ambition, no metric | Metric agreed, owner unclear | Metric, baseline and owner agreed |
| Data | Sources unknown or disputed | Sources listed, quality unknown | Sources profiled, key identifier chosen |
| Org health | No documentation, many admins | Partial documentation | Documented, change process in place |
| Integrations | Point-to-point, undocumented | Main flows documented | Owners, contracts and error handling known |
| Consent | Held in several places, rules unclear | Rules written, storage inconsistent | Single source of truth, tested in sends |
| Team | No post-launch owner | Owner named, skills gaps known | Owner, backlog and support route in place |
How the questions work
Each area has a small number of plain-language questions. Most are answered with one of three or four statements that describe your current situation, rather than yes or no. Where you are unsure, choose the less mature option. An honest "early" is far more useful than an optimistic "ready" that collapses in the first workshop.
The questions avoid product jargon where possible, so a marketing lead, an IT manager and a finance sponsor can complete them together. Doing it as a group is often the most valuable part, because disagreements surface quickly: two people describing the same data source very differently is itself a finding.
Turning results into a plan
- 01
Read across, not down
Look for the one or two areas at "early". Those usually decide your timeline more than strengths elsewhere.
- 02
Separate blockers from risks
A blocker stops design starting, such as no access to a source system. A risk can be managed in parallel, such as patchy data quality on a secondary field.
- 03
Assign an owner to each blocker
Every blocker needs a named person and a date. Many can be cleared in weeks once someone is responsible.
- 04
Adjust the first phase
Shape the first release around what is ready. For example, start with one data source and one journey rather than all of them.
- 05
Repeat before design sign-off
Re-run the assessment when the discovery phase ends. Movement between levels is a good sign the programme is learning.
What the assessment cannot tell you
It does not inspect your org, measure your data or review contracts. It cannot tell you which licence or edition you need, and it is not a substitute for a technical discovery. Treat it as a structured conversation starter. If the results point to deeper questions, a discovery workshop, an org health check or the implementation planner are the usual next steps.
Questions we hear
Do we need to share any data to complete the assessment?
Should one person complete it or a group?
What if most areas come out as early?
Is this the same as a Salesforce health check?
Talk through your results
If you have completed the assessment, or want to work through it with someone outside the project, we can review it with you and suggest a sensible first phase.
