- Agentforce
A company calls a firm and asks for “Salesforce consulting,” expecting the team to configure the platform and go live in 6 weeks. Another buys an implementation and assumes the same people will keep fixing things a year later. A third signs up for managed support while what it actually needs first is someone to redesign the data model.
None of these are edge cases. They’re the default outcome when a buyer picks a service category by instinct instead of by what the work requires.
The category you choose determines what the provider owns, what gets delivered, how long the engagement runs, and how you’ll be billed. Get the category wrong and you’ll pay for the right people doing the wrong job.
Consulting decides direction. Implementation builds the thing. Managed services keeps it running and improving after launch.
They sound sequential.
In practice, they overlap more than most comparison pages admit. At VALiNTRY360, we see this confusion on nearly every first call, and this piece shows you where those lines fall.
Salesforce Consulting vs Implementation vs Managed Services: Quick Comparison
|
Factor |
Salesforce consulting |
Salesforce implementation |
Salesforce managed services |
|---|---|---|---|
|
Primary purpose |
Decide direction and requirements |
Build and deploy |
Run, support, and improve |
|
Typical starting point |
A business problem or unclear requirements |
Approved scope |
A live Salesforce org |
|
Main work |
Discovery, architecture, roadmap |
Configuration, development, migration |
Administration, fixes, releases, backlog |
|
Main deliverable |
Decisions and design |
A working Salesforce solution |
Recurring service outcomes |
|
Duration |
Short project or ongoing retainer |
A finite project |
Ongoing |
|
Who’s involved internally |
Business and technical stakeholders |
Subject-matter experts, a product owner, UAT testers |
The platform owner and business requestors |
|
Commercial shape |
Advisory project or retainer |
Project-based, usually a statement of work |
Recurring: retainer, tiered, or SLA-based |
|
How success gets measured |
Decision quality and readiness to build |
Delivery against the agreed scope |
Service health and consistent delivery over time |
That table holds for most engagements, but the boundaries blur in practice. A consultant often stays involved through implementation.
A managed services team often builds new functionality too, well past fixing bugs. We’ll get into exactly where those lines cross later on.
For now, treat Salesforce consulting vs implementation vs managed services as a question of primary responsibility at a given point in time, not 3 sealed boxes.
Say a mid-size distributor is 3 years into Salesforce, has a working Sales Cloud org, and just got a new VP who wants Agentforce piloted by Q2. That single request touches all 3 categories: consulting to define the use case and governance, implementation to build it, and managed services to run it once it’s live. Naming the category up front is what keeps the scope honest.
What Salesforce Consulting Services Cover
Consulting exists to answer questions before anyone touches configuration.
Business and process assessment
A consultant runs a current-state assessment, reviews your processes, gathers requirements from stakeholders, and evaluates where your CRM maturity actually sits versus where you think it sits.
Salesforce strategy and architecture
This covers cloud selection, data model design, an integration plan, and security requirements, all defined before a single field gets built.
Roadmap and requirements
Good consulting produces a roadmap: priorities ranked, a business case that justifies the spend, delivery phases sequenced, and governance rules set before anyone starts building.
Existing-org consulting
If adoption is low, technical debt has piled up, or reporting doesn’t answer the questions leadership asks, a consultant diagnoses that before recommending a fix. This is also where duplicated processes and unclear data ownership tend to surface.
We see this most often in orgs that grew by acquisition or by bolting on new business units without ever revisiting the original data model. No one planned it that way; it just accumulated, one exception at a time, until the org needed a real diagnosis instead of another quick fix.
The outputs you should expect from a consulting engagement: a roadmap, an architecture recommendation, a process map, documented requirements, a prioritized backlog, and a governance plan. These are decisions on paper, ready to hand to a build team.
Salesforce’s own Professional Services offering is organized the same way, spanning everything from getting started through enterprise-wide transformation rather than treating a Salesforce program as a single build event.
A good way to tell whether you actually got consulting, versus a sales pitch dressed up as one, is to check whether the recommendations are specific enough to hand straight to a build team: a defined data model, named report types, and a prioritized backlog, rather than a vague line like “you should improve your reporting.”
We cover this in more depth on our Salesforce Consulting Services page, including how our discovery process runs.
What Salesforce Implementation Services Cover
Implementation is where the decisions from consulting turn into a working system. Think of it as 4 stages.
Confirm requirements and design
Requirements get finalized into user stories, the architecture gets locked, acceptance criteria get written, and the backlog gets built out.
Configure and build
This is configuration: Flow automation, custom development where declarative tools fall short, roles and permission sets, reports and dashboards that match what the business asked for. Heavier customization and app-level build-out are covered separately on our Salesforce Customization Service and Salesforce Development Services pages.
Connect systems and move data
Migration from legacy systems, field mapping, deduplication, API connections, and integration with whatever else the business runs on.
Test, train, and deploy
QA, user acceptance testing, the actual deployment, end-user training, cutover planning, and hypercare in the days right after go-live.
One detail that gets skipped in most comparison articles: implementation has a contractual end date, and it isn’t always the same date as go-live. “Support handoff” and “go-live” can sit weeks apart. Get that written into the statement of work before you sign, not after you’re asking who owns a bug 3 months in.
Implementation timelines also swing harder than most quotes suggest. A single-cloud rollout with clean data can close in 8 to 10 weeks. A multi-cloud program with legacy data, several integrations, and a global rollout can run 6 months or longer.
The gap between those 2 numbers is almost always driven by data quality and integration count, not by the platform itself. Ask early how much of your existing data is actually usable as-is.
We walk through this process in more detail on our Salesforce Implementation Services page, with data work and integrations covered separately on our Salesforce Data Migration Services and Salesforce Integration Services pages.
What Salesforce Managed Services Cover After Launch
Managed services keeps a live org running, and it’s the category most comparison pages shortchange.
Salesforce administration
Users, permissions, objects, reports, dashboards. The unglamorous daily work that keeps the org usable, usually handled by someone holding a Salesforce Certified Administrator credential or working toward one.
Incident and defect work
Defects, user-reported problems, integration failures, and the troubleshooting that goes with all 3.
Enhancement backlog
New fields, Flow changes, new reports, small development work, and the steady stream of requests that show up once real users start living in the system.
Platform stewardship
Release readiness, technical-debt tracking, security reviews, data quality, and governance that doesn’t stop just because the project ended.
Salesforce’s own Well-Architected Framework treats application lifecycle management, incident response, and release management as continuing responsibilities rather than one-time setup tasks. That lines up with how a managed services team should operate.
Specialist capacity
Development, architecture, integrations, and increasingly, Data 360 and Agentforce support, where contracted, as those capabilities spread through more orgs.
3 things get lumped together that shouldn’t be. Basic ticket support resolves what’s broken and stops there. Virtual admin support adds a dedicated person handling day-to-day configuration, usually part-time or fractional.
Managed services goes further still: it owns the platform’s direction, its backlog, and its governance, not just its uptime or its inbox. If your provider only closes tickets, you don’t have managed services. You have a help desk with a Salesforce badge on it.
Ask a prospective managed services provider one question to test this: how do they run a quarterly roadmap review? A real managed services relationship has an answer, usually a recurring session where the backlog gets reprioritized against what the business needs next.
A ticket-only provider won’t have one, because no one on their side owns the roadmap in the first place.
We break this down further on our Salesforce Managed Services page, with pricing models covered separately in Salesforce Managed Services Pricing: Retainer vs Hourly vs Tiered.
Salesforce Consulting vs Implementation vs Managed Services Across 10 Decision Factors
|
Decision factor |
Consulting |
Implementation |
Managed services |
|---|---|---|---|
|
Business question answered |
What should we do? |
How do we build it? |
How do we keep it running and improving? |
|
Starting condition |
No clear direction yet |
Scope locked and funded |
Already live, in daily use |
|
Scope definition |
Diagnostic and advisory |
Fixed delivery scope |
Recurring service scope |
|
Typical work |
Diagnose, then design the fix |
Turn the design into a build |
Keep the build healthy and current |
|
Main deliverable |
Answers you can act on |
A system your team runs |
A platform that keeps working |
|
Engagement duration |
Days to weeks, or retained |
Weeks to months |
Monthly or annual |
|
Provider accountability |
Direction and recommendations |
Delivery against agreed scope |
Operational Salesforce ownership |
|
Internal responsibility you carry |
Provide access and answers |
Approve UAT, own change control |
Prioritize the backlog, flag issues |
|
Success measure |
Whether the decisions hold up |
Whether delivery matched scope |
Whether the platform stays healthy |
|
Commercial structure |
Project fee or retainer |
Statement of work |
Retainer, tiered package, or SLA |
This is really the heart of Salesforce consulting vs implementation vs managed services: each category is a different business question before it’s a different technical task.
The quick comparison table above and this one answer different questions. That one shows what each category looks like on its own. This one shows what changes for you, as the buyer, moving from one to the next, which is why “internal responsibility you carry” and “commercial structure” get their own rows here.
Both are where buyers get burned most often: a stalled UAT cycle because no one had time to test is a scheduling problem the provider can’t fix from their side. A fixed-fee implementation with a vague scope can end up costing more in change orders than a time-and-materials engagement with a tight, documented backlog.
Where Consulting, Implementation, and Managed Services Overlap
Most comparison pages draw hard lines between these three. Real Salesforce programs don’t respect those lines, and pretending otherwise sets buyers up to be surprised.
|
Activity |
Consulting |
Implementation |
Managed services |
|---|---|---|---|
|
Discovery |
Primary |
Contributes |
Rarely involved |
|
Architecture |
Primary |
Primary |
Ongoing governance |
|
Configuration |
Limited |
Primary |
Small changes |
|
Development |
Advisory or specialist |
Primary |
Backlog work |
|
Data migration |
Planning |
Primary |
Limited, recurring |
|
Testing |
Advisory |
Primary |
Regression and release testing |
|
Go-live readiness |
Advisory, change support |
Primary |
Transition support begins |
|
Hypercare |
Sometimes involved |
Primary |
Often begins here |
|
Releases |
Governance |
Project-specific |
Recurring |
|
Roadmap review |
Primary |
Occasional input |
Recurring input |
2 rows deserve a closer look. Architecture is genuinely shared, since a good decision needs both the strategic view consulting brings and the delivery reality implementation understands, and getting that wrong usually shows up months later as a redesign rather than an immediate failure.
Hypercare is the clearest overlap point on the whole page: the implementation team is usually still on-site while the managed services team is already picking up tickets, and a poorly defined hypercare window is where a lot of “who owns this” disputes start.
What actually determines the label for a given piece of work, at a given time, is primary responsibility and commercial commitment, not which task happens to show up in a contract that week. A managed services provider building a new feature is still managed services. A consultant reviewing architecture 6 months post-launch is still consulting.
If your managed services partner starts recommending a full platform rebuild, that’s a legitimate finding, but it’s a consulting and implementation conversation, priced and scoped separately, not something that should quietly absorb your monthly retainer.
How the 3 Services Fit Across the Salesforce Lifecycle
The model below maps consulting, implementation, and managed services across a real Salesforce program.
Stage 1: Diagnose. Primary owner: consulting. Output: a defined problem, an honest assessment, and ranked priorities.
Stage 2: Design. Primary owner: consulting, with implementation architects involved. Output: solution design, backlog, and an implementation plan.
Stage 3: Build. Primary owner: implementation. Output: a configured Salesforce environment, integrations, and migrated data.
Stage 4: Validate and deploy. Primary owner: implementation. Output: testing, UAT, the release itself, and training.
Stage 5: Stabilize. Ownership shifts here, from implementation to managed services. Output: defects get closed, usage gets monitored, and support responsibility formally transfers. This is also the stage where the handoff checklist covered later in this article actually gets used, not just written down.
Stage 6: Run and improve. Primary owner: managed services. Output: ongoing support, backlog delivery, release management, and administration.
Stage 7: Reassess. Consulting comes back for the decisions that require it: a new cloud, an acquisition, a major architecture change, or adopting Agentforce or Data 360. Nothing about stages 1 through 6 has to repeat in full. Usually it’s a scoped-down version of Diagnose and Design focused on just the new piece.
Picture it as a straight line: diagnose, design, build, deploy, stabilize, run, reassess. Ownership shifts along that line, but the line itself keeps advancing rather than resetting to stage one.
Most companies walk it repeatedly, at a smaller scale, every time something new gets added: a cloud, an acquired company’s Salesforce org that needs merging in, or a capability like Agentforce that didn’t exist when the original implementation happened. Stage 7 is usually stage 1 of the next pass through the same line.
Which Salesforce Service Do You Need? 8 Real Buying Situations
Match your situation to the service that fits it, then check the reasoning against your own case.
You’re evaluating Salesforce for the first time. Reason: you need direction before you need code. Fit: consulting, followed by implementation. Next stage: build, then transition to managed services.
You have approved requirements and Salesforce just needs to get built. Reason: the decisions are made, so execution is what’s left. Fit: implementation. Next stage: hypercare, then managed services.
Your org is live, but users don’t trust it. Reason: something structural is wrong, and building more on top of it won’t fix it. Fit: a consulting assessment, followed by remediation. Next stage: managed services, once the org is stable.
Your administrator is overloaded. Reason: the platform is fine, the capacity to run it isn’t. Fit: managed services or virtual admin support. Next stage: ongoing, unless a bigger architecture problem surfaces.
You’re migrating off another CRM. Reason: migration decisions and technical build both matter here, and the data work is usually the part people underestimate. Fit: consulting, then implementation with data migration scoped in early. Next stage: hypercare, then managed services.
You’re adding another Salesforce cloud. Reason: you already run Salesforce, but this cloud is new territory. Fit: focused discovery, then implementation. Next stage: fold back into existing managed services.
You just finished go-live. Reason: the build is done, but the org still needs steady hands for a while. Fit: hypercare, then managed services. Next stage: ongoing managed services.
You’re introducing Agentforce or Data 360. Reason: this is new enough that skipping the advisory step is how governance gaps happen later. Fit: architecture and governance advice, then technical delivery, then recurring monitoring. Next stage: managed services with AI governance folded in.
A company can move between these 8 over time, circling back more than once. One that starts in “administrator overloaded” territory can land back in “your org is live, but users don’t trust it” territory 18 months later, once the org has grown past what a single admin can reasonably own.
Headcount changes, an acquisition, or a jump in Salesforce usage are the usual triggers to check which situation fits now.
How Pricing and Contracts Differ Across the 3 Services
Pricing follows the shape of the work, and lumping all 3 into one number hides more than it explains.
Salesforce consulting pricing
Usually shows up as a fixed-fee assessment, hourly or time-and-materials advisory work, a retained consultant relationship, or a standalone architecture engagement.
Salesforce implementation pricing
Tends to run fixed-scope, time and materials, milestone-based, phased, or some hybrid of those.
Salesforce managed services pricing
Almost always recurring: a monthly retainer, a tiered package, allocated capacity you draw down, or an SLA-based agreement.
|
Cost question |
Consulting |
Implementation |
Managed services |
|---|---|---|---|
|
Main pricing unit |
Expertise or project |
Delivery scope and effort |
Recurring service capacity |
|
Budget horizon |
Short, or periodic |
Project-length |
Monthly or annual |
|
How scope changes get handled |
Advisory expansion |
Formal change requests |
Backlog reprioritization |
|
Typical commitment |
Project or retainer |
Statement of work |
Service agreement |
|
Where buyers get burned |
Vague, undocumented outputs |
Scope creep no one flagged |
Poorly defined service boundaries |
Worth knowing before you compare quotes: Salesforce’s own Success Plans sit alongside all of this, and buyers often assume they cover what a managed services partner covers. Standard is included with your licenses, Premier runs 30% of net license fees, and Signature is custom-priced, but all 3 are Salesforce’s own support tiers, focused on platform reliability and access to Salesforce resources.
A managed services partner owns your backlog, your configuration changes, and your platform roadmap. Salesforce’s plans don’t do that work for you, and budgeting for a Success Plan instead of a managed services partner is one of the more common ways companies end up with an org no one is actively improving.
Ask each provider, in plain language, what happens to the price if the scope grows mid-engagement, before you sign anything. Consulting usually handles growth as advisory expansion. Implementation handles it through a formal change request with a price and timeline impact attached.
Managed services handles it by reprioritizing the backlog rather than expanding the retainer automatically. A quote that doesn’t spell out which of these 3 applies to it is a quote worth pushing back on.
Team Roles, Deliverables, and Accountability by Service Model
Who’s in the room changes with the service category, and so does who owns what decision.
A consulting team typically includes a business consultant, a business analyst, a solution architect, sometimes an enterprise architect, and an industry specialist where the vertical matters.
An implementation team typically includes a project manager, a solution architect, a functional consultant, a Salesforce admin, one or more developers, an integration specialist, a data specialist, QA, and a trainer.
A managed-services team typically includes a service manager, a Salesforce administrator, a developer, an architect for larger changes, QA, and a release specialist.
Team size scales with org complexity, not with headcount at your company. A 50-person sales team on a single Sales Cloud org might need one fractional admin. A 500-person org running Sales, Service, and a handful of integrations usually needs the fuller roster above, even if the business itself hasn’t grown that much.
|
Service |
Typical outputs |
|---|---|
|
Consulting |
Assessment, architecture, roadmap, documented requirements |
|
Implementation |
Configured org, code, integrations, migrated data, test results, documentation |
|
Managed services |
Resolved tickets, shipped releases, backlog items delivered, health reports, ongoing governance |
Here’s what most comparison pages leave out entirely: who owns priorities, who owns approvals, who owns technical decisions, who signs off on testing, who approves deployments, and who owns production support once something breaks at 6pm on a Friday. Get that written down before the engagement starts, not during the first incident.
A simple test for whether this is actually defined: ask your provider to name the person on your side who can approve a production deployment, and the person on their side who owns the outcome if that deployment fails.
If either answer is “it depends” or takes more than a few seconds, the accountability model isn’t finished yet, regardless of what the statement of work says on paper.
What Goes Wrong When the Engagement Model Doesn't Match the Work
These are the patterns we see most often at VALiNTRY360, and every one of them is avoidable.
Implementation starts with unclear requirements. The result: redesign mid-project, scope changes no one budgeted for, and delays that ripple through everything downstream. It’s the pattern we see most often, and it’s almost always traceable to skipping or rushing the consulting phase.
Consulting produces a roadmap with no delivery owner. The result: decisions sit on a shelf, assumptions go stale, and whoever finally implements it ends up redoing the discovery work from scratch. Past the 6-month mark, treat the original roadmap as a starting draft, not a finished plan.
Managed services gets purchased for a major rebuild. Recurring support capacity isn’t built for a large, finite transformation. You’ll either blow through the retainer inside the first month or stall the rebuild waiting for capacity that was never sized for it.
We’ve watched this happen when a company tries to fund a platform overhaul out of its existing support budget instead of scoping it as its own project. The rebuild stalls, the support queue backs up behind it, and both suffer.
Implementation ends without a real handoff. The result: undocumented fixes no one remembers making, unclear ownership, a backlog that stalls, and recurring incidents that keep tracing back to decisions no one wrote down. Of the 5 patterns here, this one is the most preventable and the most expensive to fix after the fact.
Basic support gets mistaken for managed platform ownership. Tickets get closed. Governance, architecture, releases, and backlog planning sit unowned, and no one notices until the org’s technical debt becomes impossible to ignore.
Salesforce’s own guidance on incident response treats identifying, addressing, and preventing issues as a standing discipline, not a one-off cleanup, which is exactly what basic ticket support usually skips. By the time the gap is visible, it usually takes a dedicated remediation project to unwind.
If your org already shows signs of the third or fourth pattern, our Salesforce Remediation Services page covers what a recovery engagement involves.
Checklist for Choosing the Right Salesforce Service and Partner
Work through this before you sign anything.
Step 1: identify your current condition. Are you planning, building, recovering, running, or expanding?
Step 2: define the output you need. A recommendation, a roadmap, a working capability, recurring platform ownership, or specialist capacity you don’t have in-house.
Step 3: define your time horizon. A short assessment, a defined project, or a recurring relationship.
Step 4: check your internal capability. Do you already have a Salesforce owner, an admin, an architect, a developer, QA, or a business analyst? Whatever you’re missing is what you’re really buying.
Step 5: define provider accountability up front. Who owns delivery, the backlog, production issues, releases, documentation, and knowledge transfer if the relationship ends?
Step 6: verify the partner, not just the pitch. Check their current Salesforce tier, their competencies, relevant certifications, completed projects, and customer reviews.
This is where Salesforce’s FY27 Consulting Partner Program changes actually matter to you as a buyer: the old Base, Ridge, Crest, and Summit tiers are gone, replaced by Summit and Select, and roughly 170 legacy competency distinctions were consolidated down to 28 outcome-based ones, measured against certifications, completed projects, and customer satisfaction, with 2 recognition levels, Accredited and Expert. AppExchange lets you check a consultant’s expertise, industry, location, certifications, and Verified Project Reviews directly, so use it before you take a sales pitch at face value.
Step 7: plan the exit before you need it. Require documentation, source ownership, credential transfer, an outstanding backlog list, known defects, architecture records, and a support transition plan as contract terms, not as an afterthought.
7 steps, maybe an afternoon of work. Skip them and you find out what was missing at the worst possible time: mid-project, mid-incident, or mid-transition to a new provider.
Our guide on how to choose a Salesforce consulting partner goes deeper into step 6 if you want the full evaluation framework.
Related Case Studies
Everything above is the framework. If you want to check out our case studies to see what it looks like in practice, here are 5 from VALiNTRY360’s own client work, each sitting in a different part of the consulting, implementation, and managed-services picture:
- How a Salesforce Quick Start Implementation Drove 16% Quarterly Growth for All American Solar: a straightforward Sales Cloud implementation from a defined scope to go-live.
- How a Salesforce Sales Cloud and Service Cloud Implementation Cut BIC Graphic’s Average Handle Time by 7 Minutes: a larger, multi-cloud implementation with ERP integration, closer to the “adding another cloud” situation covered above.
- How a SugarCRM to Salesforce Migration Cut Real California Milk’s Manual Data Work From 500 Hours a Year to 4: a consulting-led migration and data-architecture rework, the “migrating off another CRM” path.
- How Salesforce Marketing Cloud Optimization Helped Ravago Record $500K in New Revenue in Three Months: an optimization engagement on an existing org, closer to the ongoing, advisory side of managed services than a greenfield build.
- How a Salesforce Implementation for Higher Education Gave AdventHealth University a 360 View of Every Alumnus: an implementation in a different vertical, consolidating legacy records into one Salesforce org.
Frequently Asked Questions
1. What is the difference between Salesforce consulting, implementation, and managed services?
Consulting decides what should happen and why. Implementation builds and deploys the solution. Managed services keeps a live org running, supported, and improving after launch.
They can come from one provider or three, but the responsibilities are distinct even when the same team handles all of them.
2. What does a Salesforce consultant actually do?
A consultant runs discovery, gathers requirements, designs the architecture and data model, and builds a roadmap with priorities and a governance plan. The output is a set of decisions and a plan, not a configured org.
3. What does a Salesforce implementation partner do?
An implementation partner takes approved requirements and turns them into a working Salesforce environment: configuration, custom development, data migration, integrations, testing, training, and the actual deployment.
4. What do Salesforce managed services include?
Ongoing administration, incident resolution, enhancement backlog delivery, release management, technical-debt tracking, security reviews, and governance for a live org. It’s broader than ticket support, and it should stay that way.
5. Do I need Salesforce consulting before implementation?
If your requirements, architecture, and priorities are already solid, you can move straight to implementation. If they’re not, skipping consulting usually means the implementation team ends up doing discovery mid-project, which costs more time than doing it up front.
6. Can the same Salesforce partner provide consulting and implementation?
Yes, and it often makes the handoff smoother because the same people carry context from decisions into delivery. It’s not a requirement though. Plenty of successful programs use a consultant for direction and a separate implementation partner for the build.
7. When should Salesforce managed services begin?
Usually right after hypercare, once the implementation team has closed out the initial defect list and formally transferred documentation, credentials, and backlog ownership. Some companies bring managed services in earlier, running it alongside the tail end of implementation.
8. What is the difference between Salesforce support and managed services?
Support resolves tickets. Managed services owns the platform: the backlog, the release calendar, technical debt, governance, and the direction the org takes over time, not just whatever broke today.
9. What is the difference between Salesforce Success Plans and managed services?
Success Plans are Salesforce’s own tiers (Standard, Premier, Signature) focused on platform reliability, technical support access, and product guidance. Managed services is a partner relationship that owns your configuration, your backlog, and your day-to-day platform decisions. They’re not interchangeable, and most buyers assume more overlap than actually exists.
10. Can managed services include Salesforce development?
Yes, most managed services agreements include development capacity for the enhancement backlog. Larger builds usually get scoped and priced separately, closer to a small implementation project, even when the same provider delivers it.
11. How are Salesforce consulting, implementation, and managed services priced?
Consulting runs fixed-fee, hourly, or retained. Implementation runs fixed-scope, time and materials, or milestone-based. Managed services runs recurring: retainer, tiered, or SLA-based.
Ask for the pricing model up front, because the model shapes how disputes over scope get resolved later.
12. What happens after a Salesforce implementation is complete?
Hypercare first, then a formal handoff covering documentation, backlog, credentials, and known issues, then a transition into administration and ongoing support, usually through managed services.
13. Which Salesforce service fits an existing org with low adoption?
Start with a consulting assessment to find out why adoption is low before spending on remediation. Once the fix is scoped, that work often runs through implementation or managed services depending on its size, followed by training and ongoing managed services to keep adoption from slipping again.
14. Which service should I choose for Agentforce or Data 360?
Start with advisory work on use cases and governance, move into technical delivery once the plan is set, then fold ongoing monitoring and governance into your existing managed services relationship. Skipping the advisory step is the most common way AI governance gaps show up later.
15. How do I choose a Salesforce consulting partner for all 3 service areas?
Check their competencies under Salesforce’s current Summit and Select tiers, their certifications, their completed project history, and their customer reviews on AppExchange, including Verified Project Reviews. Then confirm they have a documented handoff process between phases, since that’s where most Salesforce programs actually lose momentum.