Nobody advertises a failed Salesforce implementation. There’s no case study titled “How We Spent $120,000 and Ended Up Back in Spreadsheets.” But the failures happen regularly enough that experienced consultants know a consistent truth: a significant share of the work that comes through the door isn’t new builds. It’s fixing what someone else left broken, undocumented, or half-delivered.
A 2025 CRM study reported a 55% failure rate, defining failure as not achieving planned objectives rather than a Salesforce-specific platform failure. Poor data migration, inexperienced delivery teams, scope that expands without budget to match, and weak post-go-live support can contribute. Salesforce consulting is a market where certification badges and impressive client logos are easy to accumulate and hard to distinguish from the partners who consistently deliver versus those who consistently underdeliver.
This guide gives you a practical evaluation framework for the selection process, not what partners want you to ask, but what actually reveals delivery quality before you commit. The questions in each section are designed to separate genuine capability from polished sales presentations.
TL;DR
| What to evaluate | What a strong answer looks like | Red flag |
| Team composition | Named architect on the project with a written commitment to their hours | “We’ll assign the right resources” with no specifics |
| Discovery process | Stakeholder interviews, process mapping, and a written requirements doc before scope is set | Fixed-price quote after a 30-minute demo |
| Data migration approach | Documented methodology with test migrations, validation runs, and rollback plan | “We’ll handle the data” with no detail |
| Agentforce and AI readiness | Specific Data 360 and Agentforce project references with outcomes | Surface-level familiarity; no production deployments |
| Post-go-live support | Defined support tier, SLA, and escalation path documented in the contract | “We’ll be available” with nothing written |
| References | 3 or more clients in a similar scenario who you can call directly | Testimonials on the website; no direct reference contacts |
| Governance | Documented change management process and org governance plan delivered at project end | No mention of governance or change management |
Every item on this list corresponds to a documented failure mode in real Salesforce implementations. The tests below give you specific questions to evaluate each one.
Why Partner Selection Gets This Wrong
- Most businesses evaluate Salesforce consulting partners the same way they buy software: they compare certifications, ask for pricing, look at a few case studies, and choose the firm that seems most credible for the budget. That approach produces weak results because it measures the wrong things. The 3 most commonly used signals are the 3 weakest predictors of delivery quality:
- Partner tier in Salesforce’s FY27 Consulting Partner Program now uses Provisional status during onboarding, followed by Select and Summit levels instead of the old medal-style tiers. Program standing reflects competencies, projects, certifications, and customer outcomes. Use status as one signal, but test current product expertise and the assigned team’s experience.
- Certification counts tell you what consultants have studied, not how they perform under project pressure, how they handle a failed data migration at 11pm before go-live, or whether the person who passed the certification will even be on your project.
- Case studies are selected, edited, and approved by the partner before you see them. They tell you what the partner wants you to know. The client who had a 9-month project run to 18 months doesn’t become a case study.
The right Salesforce consulting partner evaluation starts with understanding your own project scenario first. Are you starting fresh, migrating from another CRM, fixing a broken existing org, adding a cloud, or deploying AI capabilities? Each scenario requires different expertise, and a partner who is excellent at greenfield Sales Cloud implementations may not be the right choice for a complex Data 360 and Agentforce rollout.
Test 1: How They Run Discovery
Discovery is where the entire project is either set up to succeed or quietly set up to fail. A partner who conducts a thorough discovery process produces a scope document that reflects your actual business processes, identifies the integration points that will cause problems later, and surfaces the data quality issues that will affect migration. A partner who skips genuine discovery produces a scope document that reflects what they planned to build anyway. The difference shows up in how they answer questions before the proposal stage.
Ask: “Walk me through your discovery process. What happens between our first meeting and when you deliver a project scope?”
A strong answer describes stakeholder interviews across multiple departments, process mapping workshops, a review of the existing technology stack and integration landscape, a data audit or at least a data assessment, and a written requirements document that both parties sign off on before scope is finalized. The discovery process should feel like work because it is work.
A weak answer describes a few calls with the project sponsor, a review of requirements you provide, and a proposal. This is a partner who is scoping based on assumptions and will discover the complications later, when they’re billable.
Ask: “What’s the most common thing you discover in a project that the client didn’t tell you about upfront?”
This question tests whether the partner actually runs deep discovery and what they’ve learned from it. Experienced partners have seen consistent patterns: underestimated data quality problems, undocumented integrations that turn out to be business-critical, manual processes that were supposed to be automated but aren’t documented anywhere, and resistance from specific teams that wasn’t surfaced during the sales process. Partners who can describe specific examples from experience have actually encountered these situations. Partners who give a generic answer about “scope creep” have not.
Test 2: Team Composition and Who Is Actually on Your Project
The team that sells the project is rarely the team that delivers it. This is the most consistent complaint in Salesforce implementation post-mortems: the senior architect who drove the sales process shows up for the kickoff and the final demo. Between those 2 moments, the project is staffed with junior consultants who are learning on your implementation budget.
Ask: “Who specifically will be on this project? What is their role, their certification level, and what percentage of their time is allocated to us?”
Get this in writing. A partner confident in their team composition will commit to it contractually. A partner who hedges by saying “we’ll assign the right resources based on project needs” or “we staff projects dynamically” is telling you they will put whoever is available on your project, not whoever is best suited.
Do not rely on an unsupported industry architect ratio as a proxy for delivery quality. Ask instead how much named senior architecture coverage your project receives, which decisions require architect review, who owns escalations, and who provides backup if a senior person becomes unavailable. The important test is whether experienced people are committed to the work when difficult design decisions arise, not a firm-wide staffing percentage.
Ask: “If a key person on our project leaves your firm mid-engagement, what is your process?”
This question reveals whether the partner has a staffing bench with genuine redundancy or whether key person risk is real. Strong partners describe a documented handover process, a named backup resource, and a knowledge management practice that keeps project documentation current enough that a replacement can ramp quickly. Weak partners have not thought about this question because it doesn’t come up in their sales process.
Test 3: Data Migration Methodology
Data migration is one of the most consistently underestimated risks in Salesforce implementations. Its budget and schedule impact varies widely with source-system complexity, data quality, record volume, and validation requirements. The 1-10-100 concept is better treated as an illustrative data-quality principle than a literal Salesforce cost formula: defects are generally cheaper to prevent at the source, more expensive to correct later, and costlier still when bad data spreads through reports, automations, integrations, and decisions.
Most clients underestimate data complexity because they haven’t been through a CRM migration before. Most partners underestimate it because properly scoping data migration doesn’t make proposals look lean and competitive.
Ask: “Walk me through your data migration methodology from data extraction through validation.”
A strong answer walks through 5 distinct phases in sequence. Any partner who skips or combines phases is describing a migration they haven’t fully scoped.
| Phase | What it covers | Red flag if missing |
| Data discovery and profiling | Understanding what’s actually in source systems, not what’s supposed to be there | Partner skips directly to mapping without auditing source data |
| Cleansing and transformation | Deduplication, standardization, and format normalization before anything touches Salesforce | “We’ll clean the data in Salesforce” after migration |
| Test migration | A full migration run against a sandbox with validation against defined success criteria | No test migration, or only a partial subset tested |
| Iterative refinement | Fixing failures from the test run and re-running before the final cutover | Single migration attempt with no iteration cycle |
| Final migration with rollback plan | Go-live cutover with a documented rollback procedure if validation fails | No rollback plan; “we’ll deal with issues as they come up” |
Ask specifically: “What happens if the go-live migration fails validation?”
Ask: “How do you handle legacy data that doesn’t map cleanly to Salesforce’s data model?”
This question separates consultants who have actually done complex migrations from those who have done simple ones. Messy data that predates the Salesforce implementation, fields that don’t have a clean Salesforce equivalent, relationship structures that don’t translate directly, and historical records that need to be archived rather than migrated all require judgment calls. A partner who describes this in specifics has been there. The CRM cleanup work that precedes data migration determines whether the migration itself goes smoothly, and strong partners audit source data quality before they scope migration costs.
Test 4: Agentforce and AI Readiness
This is the evaluation factor that partner selection guides published before 2025 entirely miss, and it’s now one of the most important criteria for any implementation starting in 2026. Salesforce has made three significant investments that are reshaping how modern orgs are designed: Agentforce for autonomous AI workflows, Data 360 for unified real-time customer profiles, and AI-powered Einstein features embedded across every cloud.
The partners who understand these capabilities as a connected architecture and the partners who have patched together surface-level AI features on top of traditional implementations are delivering very different results.
Ask: “Describe a production Agentforce deployment you’ve completed. What was the business problem, how did you scope it, and what did it actually deliver?”
Vague answers referencing Agentforce capabilities from the documentation, customer stories from Salesforce’s website, or pilot projects that never reached production are all insufficient. You want to hear about a real deployment: the use case (service case resolution, sales development follow-up, field service scheduling), the technical architecture (how Agentforce was connected to Data 360, what data sources fed the agents, how the agents were governed and monitored), and the measurable outcome.
The real-world Agentforce use cases that are producing results in 2026 share a consistent dependency: they’re built on a clean, unified data foundation. A partner who proposes Agentforce without a clear Data 360 strategy is proposing AI agents that will reason from incomplete or contradictory data.
Ask: “What Data 360 implementation does this Agentforce use case require?”
This is the single highest-signal question in an AI readiness evaluation. Partners with genuine Agentforce experience know that Data 360 must be provisioned and enabled, while the amount of ingestion, unification, grounding, and implementation depends on the use case. If a client’s data already lives cleanly in Salesforce and the agent does not need external sources, the Data 360 work may be limited. If customer data is scattered across an ERP, marketing platform, service system, and warehouse, broader Data 360 implementation may be needed to unify and ground the agent. A partner who recommends the same Data 360 scope for every use case is overselling. A partner who can separate required enablement from use-case-specific implementation is experienced.
For organisations planning Agentforce and Data 360 implementations, the setup sequence and the governance model matter as much as the technical configuration.
Test 5: Integration Architecture and Depth
Salesforce rarely lives in isolation. It connects to ERPs, marketing platforms, data warehouses, customer service systems, billing systems, and in some industries, operational technology like field service management or IoT platforms. How a partner handles integration reveals more about their technical depth than almost any other test.
Ask: “What integration middleware do you use, and what’s your decision framework for choosing between MuleSoft, custom Apex, and native Salesforce APIs?”
The answer reveals technical philosophy immediately. Over-engineering is a real pattern: partners who default to custom Apex for every requirement inflate billable hours and create a “technical dependency” where only they can maintain what they’ve built. A strong partner describes a decision framework: native Salesforce tools first (Flows, standard API connectors), middleware like MuleSoft or Boomi for complex multi-system orchestration, and custom Apex only when native options genuinely can’t meet the requirement.
Ask: “How do you handle integration failures in production?”
Every integration breaks at some point. A data feed from an ERP stops sending records. An API credential expires. A schema change in an upstream system breaks the payload. A partner who has operated integrations in production describes specific failure modes and their mitigation: monitoring and alerting, retry logic, error logging that produces actionable notifications, and a support escalation path with defined response times. A partner who describes integration architecture without mentioning failure handling is describing a system they haven’t operated.
Ask: “Walk me through the most complex integration you’ve built on Salesforce. What were the failure modes and how did you handle them?”
The specificity of the answer tells you everything. Genuine integration depth produces specific answers: “We built a bidirectional sync between Salesforce and SAP that handles 40,000 records per hour. The main failure mode was order status conflicts when both systems updated the same record within the same sync window. We solved that with a timestamp-based conflict resolution rule and a manual review queue for records that flagged conflicts more than 3 times in 24 hours.”
Test 6: Post-Go-Live Support Model
“Go-live” is the beginning of a Salesforce implementation’s working life, not the end of it. Most of what makes an implementation genuinely successful happens in the 90 days after launch. Partners who treat go-live as the project end put their clients in a difficult position at exactly the moment when support is most needed.
Adoption problems that weren’t visible during testing surface when real users try to do their real jobs in the system, often revealing that workflows were designed for how management described the process, not how it actually runs.
Data quality issues that sandbox testing never exposed emerge at production volume: record volumes that trigger governor limits, edge cases in the data that weren’t in the test set, and integration failures that only occur under real traffic patterns.
Business requirements shift as users interact with the live system, discovering what they actually need versus what they thought they needed during requirements workshops 3 months earlier.
Configuration decisions that looked correct in testing turn out to be wrong under real conditions, requiring fixes the partner should cover under support rather than bill as new scope.
Ask: “What does your post-go-live support model look like, and what’s included in the engagement versus what’s additional scope?”
Get the answer in writing and in the contract. Support is one of the most commonly disputed elements of Salesforce engagements, because the line between “that’s a bug we need to fix” and “that’s a change request that falls outside the original scope” is frequently unclear and frequently expensive. Strong partners define the support period explicitly (typically 30 to 90 days), specify what types of issues are covered (bugs versus enhancements versus new requirements), commit to response time SLAs by severity level, and name the person or team responsible for support.
Ask: “What’s the most common reason clients come back to you 60 days after go-live?”
This question reveals what the partner has actually seen in production, and it’s a useful window into whether they’re honest about what implementations typically look like post-launch. Common legitimate answers: adoption issues because training was lighter than it should have been, data quality problems that weren’t visible until production volume, report and dashboard gaps that emerged when users started doing their actual work. Partners who describe specific patterns from experience know what production implementations look like. Partners who say “most of our clients are very happy after go-live” are not describing reality.
Measuring whether the implementation is actually working requires defined KPIs agreed before go-live. The Salesforce ROI optimisation framework matters here: without measurement, you can’t distinguish a successful go-live from one that went technically smooth but delivered no business value.
Test 7: References and What to Ask Them
References are the most underused evaluation tool in partner selection. Most buyers request references, receive a list of 3 happy clients, make perfunctory calls, and move forward. The partner-selected reference is a biased data point. The way you ask the questions determines how much useful signal you get.
Don’t ask: “Was the project successful?”
Do ask: “Did the project finish on time and on budget? If not, what happened?”
Don’t ask: “Would you recommend them?”
Do ask: “If you were starting this project again, what would you do differently in selecting or working with this partner?”
Don’t ask: “Was the team responsive?”
Do ask: “Who was actually on the project day-to-day? Was the person who sold the project present during delivery? What happened to the team composition over the course of the engagement?”
The most revealing question is the last one. Team stability is one of the clearest predictors of implementation quality. High consultant turnover during a project means knowledge leaves when people do, requirements get re-explained multiple times, and the work produced by a fresh consultant who joined 4 months into a 6-month project is often significantly weaker than work by someone who understood the full context.
Ask specifically about:
- Whether key personnel on the project were the same from start to finish
- How communication was handled, and whether they felt informed about problems before problems became crises
- What the post-go-live support experience was like
- Whether they would use the same partner again for a different Salesforce project, and why or why not
Request at least 3 references, and specifically request a reference from a project that had problems. Every serious partner has had at least one project that ran into difficulty. How they handled it is far more informative than how they handled a smooth project.
Test 8: Governance, Documentation, and What You Own at the End
A Salesforce org that you can’t maintain without the implementing partner is not an asset. It’s a dependency. Partners who build undocumented, tightly coupled implementations create long-term revenue for themselves and long-term problems for their clients.
Ask: “What documentation do you deliver at project end, and what does it cover?”
At minimum, a professional Salesforce implementation should deliver the following documentation package. Ask to see an example from a past engagement before you sign:
- Org architecture document covering objects, fields, relationships, and the purpose of each customization
- Data dictionary documenting every custom field, its purpose, its data type, and any validation rules applied
- User guide for each primary user profile: what they can see, what they can do, and how to complete their core tasks
- Admin guide covering ongoing maintenance tasks, scheduled jobs, and how to make common configuration changes
- Integration documentation for every connection: authentication method, data flow direction, error handling, and escalation path if it fails
- Release notes for each deployment made during the project, describing what changed and why
Ask: “What’s your governance model for the org after go-live?”
Governance determines whether the org stays healthy over time. Without it, well-intentioned admins make changes that conflict with existing automation, redundant flows accumulate, fields get repurposed for different use cases than they were designed for, and the org slowly drifts into unmaintainability. Strong partners deliver a governance framework as part of the project: change management rules, deployment procedures, a review process for new automation, and naming conventions that make the org auditable. The Flow logging and governance practices that experienced partners establish during implementation are what keep the org maintainable after they leave.
Ask: “If we need to switch partners in 2 years, what would that look like?”
This question makes some partners uncomfortable, which is itself informative. A partner confident in the quality of their documentation and the clarity of their architecture should be able to describe a straightforward handover process. A partner who hedges or who emphasizes how complex the work is and how hard it would be to hand over is describing an org designed around partner dependency rather than client ownership.
Test 9: Change Management and User Adoption
A 2025 CRM study reported a 55% failure rate when failure meant not achieving planned objectives, rather than a Salesforce-specific result. User adoption remains a risk that should be evaluated separately. A Salesforce org can work technically while the sales team uses it minimally, entering enough data to satisfy management but not enough to make the system useful, regardless of how clean the configuration is.
Platform adoption is a change management problem, and change management is work that many Salesforce partners either don’t prioritize or treat as an afterthought compared to the technical configuration. Ask directly.
Ask: “How do you approach change management and user adoption? What’s your methodology, and when does it start in the project?”
The correct answer: change management starts during discovery, not after go-live. A partner with genuine change management methodology can describe a 4-step sequence:
1. Resistance mapping during discovery. Identifying which teams will resist the platform and why, before any configuration begins. Resistance that isn’t surfaced early becomes low adoption after go-live.
2. Champion identification. Naming the power users in each department who will drive adoption from within their teams. These people need to be involved in requirements, testing, and training before the rest of their department sees the system.
3. Workflow design around actual user behaviour. Building processes around how users actually work, not how management describes the work. This requires observation and user interviews, not just stakeholder workshops with managers.
4. Training matched to role, not to feature. A training program organized around “here’s how you do your job in Salesforce” rather than “here’s what the platform can do.” Improving adoption through workflow design and role-relevant features is downstream of building the org around what users actually need.
Ask: “What’s the adoption rate you typically see 90 days after go-live, and how do you measure it?”
Adoption is measurable. Login frequency, record creation rates, field completion rates, pipeline stage progression rates, and case resolution through the platform versus around it are all quantifiable. A partner who can describe specific adoption metrics from past projects, what they expected, what they saw, and what interventions they used when adoption was lower than expected, has actually paid attention to this dimension of delivery.
The Evaluation Scorecard
Use this partner scoring framework across every partner you evaluate. Score each test from 1 to 5: 5 means concrete, verifiable evidence; 1 means vague answers without supporting proof. Record the evidence before comparing totals. Use notes to capture unresolved risks, assumptions, and contract commitments for final comparison.
| Test | Score 1-5 | Evidence provided | Notes |
| Discovery | Stakeholder interviews, process map, signed requirements | ||
| Team | Named architect, committed hours, escalation and backup | ||
| Data migration | Profiling, test migration, validation, rollback plan | ||
| Agentforce / Data 360 | Production references, enablement scope, governance evidence | ||
| Integration | Architecture rationale, monitoring, retries, failure ownership | ||
| Post-go-live support | Written support window, SLAs, escalation ownership | ||
| References | Comparable clients, including one difficult project | ||
| Governance / documentation | Architecture, data dictionary, admin and integration docs | ||
| Change management | Adoption plan, role training, metrics, ownership |
FAQs
How much does a Salesforce consulting engagement typically cost?
Salesforce implementation pricing varies widely by scope, but market guides can provide planning ranges. A mid-market project covering Sales Cloud, a core integration, and data migration may fall around $25,000 to $150,000 for implementation, while multi-cloud, integration-heavy, or AI programs can run substantially higher. Treat any percentage of license cost or implementation multiple as a budgeting heuristic, not a universal benchmark. Cloud count, user volume, integration complexity, data condition, customization, change management, and support scope can move the total materially. Compare vendor estimates against the same assumptions so pricing differences reflect choices rather than different scope definitions.
How do Salesforce partner tiers work, and do they matter?
Salesforce’s FY27 Consulting Partner Program uses Provisional status during onboarding, with Select and Summit as the current partner levels. Program standing reflects competencies, completed projects, certifications, and customer outcomes. Status can be useful, but it is still a weak predictor of delivery quality for one specific project. A Select partner with deep Agentforce experience may fit an AI deployment better than a Summit partner with limited relevant experience. Evaluate product and industry competencies, the named delivery team, current references, and directly relevant experience rather than relying solely on program level alone.
What certifications should a Salesforce consulting team have?
The certifications relevant to your project depend on what you’re building. For core administration work, look for Platform Administrator and Platform App Builder credentials where appropriate. For Sales Cloud: Agentforce Sales Consultant. For Service Cloud: Agentforce Service Consultant. For Agentforce and data work: Agentforce Specialist and Data 360 Consultant. For complex integrations: relevant MuleSoft certifications. For governance and architecture: Certified Technical Architect (CTA) remains the most rigorous Salesforce credential. Ask for the certifications of the people who will actually be on your project, not an aggregate count across the whole firm.
Should we choose a large system integrator or a specialized boutique partner?
This depends on project scope and organizational context. Large system integrators can provide broader geographic coverage, larger staffing pools, and established methods for complex enterprise programs. Specialized boutiques may offer deeper focus in a particular cloud, industry, or use case, with more direct access to senior practitioners. Neither model guarantees lower cost or better outcomes. Compare the named delivery team, relevant certifications and competencies, similar project references, escalation coverage, delivery approach, and commercial model. The right choice is the firm whose actual team and operating model best match your specific scope, risk level, timeline, and internal capacity.
What should be in a Salesforce consulting contract?
At minimum: a detailed scope of work describing deliverables and exclusions; team composition with named individuals and their committed hours; project timeline with milestones and acceptance criteria; a change management process defining how out-of-scope requests are handled and priced; the data migration methodology and success criteria; testing approach and user acceptance testing process; post-go-live support terms including duration, what’s included, SLA response times, and escalation path; and documentation deliverables. Anything described verbally during the sales process that matters to you should be in the contract, because what’s not in writing doesn’t bind anyone.
How do we handle scope creep during a Salesforce implementation?
Scope creep is most commonly caused by incomplete discovery at the start of the project. Requirements that weren’t surfaced during discovery surface as “additions” during build, and the partner has legitimate grounds to treat them as new scope. The best protection is a thorough discovery process that surfaces complexity before the contract is signed, and a clear change management process in the contract that defines how new requirements are assessed, priced, and approved. Reasonable scope changes happen in every project. The question is whether the process for handling them is fair and transparent. Ask during evaluation: “Show me how a scope change was handled on a recent project, from when the client raised it to when it was implemented.”
What are the most common reasons Salesforce implementations fail?
Common failure factors include unclear requirements, poor planning, uncontrolled scope growth, weak change management, low user adoption, data quality problems, and choosing a partner without the required technical or industry experience. These risks often reinforce each other. Incomplete discovery can create scope disputes, weak data preparation can break automation and reporting, and limited user involvement can leave teams working around the system after launch. The useful question is not which cause owns a fixed percentage of failures, but whether the project has clear requirements, disciplined governance, reliable data, enough internal participation, and a delivery team with relevant experience for this specific Salesforce scope.
How long does a Salesforce implementation take?
A standard Sales Cloud implementation for a small to mid-sized team typically takes 8 to 16 weeks. Service Cloud implementations with significant process complexity run 12 to 24 weeks. Multi-cloud implementations with data migration, integrations, and AI capabilities run 6 to 12 months or longer. These timelines assume a capable partner, adequate internal resources for stakeholder participation and user acceptance testing, and a reasonably clean data environment. Data quality problems and organizational delays in decision-making are the 2 factors that most consistently extend timelines beyond original estimates.
What internal resources do we need to commit to a Salesforce implementation?
At minimum: an executive sponsor with authority to make decisions and resolve organizational blockers, a dedicated internal project lead who manages the project from your side and is the primary point of contact for the partner, subject matter experts from each affected department who can participate in requirements workshops and user acceptance testing, and IT resources for any infrastructure or security work required to support the implementation. The most common client-side failure in Salesforce implementations is insufficient internal bandwidth: the business is too busy with daily operations to participate meaningfully in discovery, testing, or training, and the partner ends up building a system that doesn’t reflect how the business actually works.
How do we evaluate a partner’s Agentforce and AI capability specifically?
Ask for recent production deployments, not pilots, environments, or certifications. Ask what the agent was designed to do, how it connects to Data 360 or other sources, what governance and monitoring is in place, and what it directly achieved in measurable terms. Ask how the partner separates required Data 360 provisioning and enablement from ingestion, unification, grounding, or activation work a use case needs. Listen for a clear scope decision instead of a reflexive full-platform recommendation. Ask to speak with a reference client who has Agentforce in production. The AI acceleration potential in Salesforce is real, but it depends on implementation quality, and implementation quality depends on partner experience with the specific capabilities, not just familiarity with the product.
Should we sign a fixed-price or time-and-materials contract?
Fixed-price contracts work best for clearly defined, bounded scope with stable requirements: a standard Sales Cloud rollout for a team of a defined size, with a known integration count and a reasonably clean data migration. Time-and-materials contracts work better for evolving scope, complex integrations, or AI capability work where requirements will clarify over the course of the project. Be cautious of any partner who offers a fixed price after a 30-minute discovery call. A reliable partner knows that complex ecosystems require deep investigation before scope can be defined. A fixed price quoted without that investigation is either an underestimate that will produce scope disputes, or a large contingency baked in that you’re paying for regardless of whether it’s needed.
