The Problem Starts With the Order, Not the Execution
When an organization approaches a Salesforce vendor, the first request is almost always "a quote for implementation." In many cases, this isn't the right request. Some organizations already have a system and what they need is a diagnosis; some don't yet know the process they want; and some have a system that works reasonably well but lack ongoing ownership.
Ordering the wrong type of service creates a project that ends with an irrelevant outcome, and this often emerges only months later. This guide maps out four types of services based on the symptom that leads an organization to seek help.
Quick Mapping by Symptom
| What You Say | What's Likely Needed | Core Deliverable |
|---|---|---|
| "We use Excel and want order" | Discovery then phased implementation | Process map, data model, initial go-live |
| "We have Salesforce but no one uses it" | Health Check and adoption plan | Prioritized findings report and fix order |
| "The system is slow and broken after years" | Technical diagnosis and technical debt plan | Debt mapping, refactor or rebuild recommendation |
| "Our project has been stuck for six months" | Project rescue | Status assessment, go/no-go decision, stabilization plan |
| "We need someone for ongoing maintenance" | Managed Services or support | SLA, release cadence, intake for requests |
| "Our CEO wants to know if Salesforce is a fit" | Brief consultation, not a project | Opinion and suitability recommendation |
This table covers most cases. The rest of the article details exactly what to ask for in each service.
Service 1: Consulting and Discovery
When to order: When the process, the source of truth, and project scope are unclear; or when there's internal disagreement between departments.
What must be in the deliverable: A decision-level process map, core data model, permissions model, system landscape map, acceptance criteria, and baseline metrics. A deliverable that doesn't include the first five is not a discovery; it's a meeting summary.
Typical scope: Between two and eight weeks, depending on the number of cross-departmental processes. What exactly you should receive and how to identify a good consultant is detailed in the Salesforce Consulting Guide.
Service 2: Implementation
When to order: When the discovery is complete, process owners are known, and what goes into the first phase has been decided.
What must be in the agreement: Phased definitions, acceptance criteria for each phase, data migration responsibility, change request mechanism, warranty period, and knowledge transfer plan. The absence of the latter two is the common cause for long-term vendor dependency.
Warning sign: A proposal that details development hours but doesn't specify what "completed" means.
Service 3: Health Check and Diagnosis
When to order: When the system is live but something isn't working — low adoption, unreliable data, performance issues, or inability to make changes without breaking things.
What must be in the deliverable: A list of findings with severity, business impact, effort to fix, and recommended order. A report listing fifty findings without prioritization is not useful; a report that says "fix these three first and don't touch the rest yet" is a product.
Important distinction: A Health Check is not a remediation project. It's designed to enable a decision on what to fix and in what order.
Service 4: Support & Managed Services
When to order: When the system is in production and there's no internal team for ongoing ownership.
What must be defined: What's included and what's not. The critical distinction is between fixing a bug, a small configuration change, and developing a new feature. A contract that lumps all three into "a bank of hours" tends to explode within a quarter, because new feature development consumes hours intended for support.
Additionally: Response times by severity, a consistent release cadence, and ownership of documentation.
Proper Combination of Services
Most organizations don't consume a single service but a sequence. The healthy sequence looks like this:
- Brief suitability consultation — days, not weeks.
- Focused discovery for the first phase.
- Phased implementation.
- A defined stabilization period after go-live.
- Ongoing support.
- Periodic Health Check, preferably not by the original builder.
The sixth point is the most commonly skipped, and it's the cheapest.
Illustrative Example: Boutique Hotel Chain
This scenario is hypothetical and illustrative. A chain with four hotels approached three vendors requesting a quote for Salesforce implementation to manage events and guest requests. The first two proposals were for full implementation over many months.
The third vendor asked one question: Who defines "event" — the event manager at each hotel or headquarters? The answer was that there was no common definition. In such a situation, full implementation would have created four different systems under one name. The chain instead ordered a brief discovery, received one agreed-upon definition and data model, and only then proceeded to implementation — with a smaller scope than originally proposed.
Warning Signs When Ordering Service
- The proposal prices hours but doesn't define the deliverable.
- The same proposal includes discovery and implementation in a single amount without a milestone allowing a stop.
- There is no defined warranty period after delivery.
- There's no clause for knowledge transfer and documentation owned by the organization.
- The vendor refuses to provide architectural feedback before signing.
Tools to vet the vendor itself — not just the service — are consolidated in the Salesforce Implementation Company Selection Guide.
From Order to Document
Once the required service is determined, the next step is to phrase it so that the received proposals are comparable. The structure of the inquiry document and a list of questions to include are detailed in the Salesforce RFP Guide, and the clauses that should be included in the agreement itself are detailed in the SOW and Contract Clauses Guide.
Next Step
Before you request a quote, write down the symptom in one sentence — not the solution. "We lack a unified customer view between sales and service" leads to a different order than "we want Salesforce." This sentence is worth more than any requirements document written after it.