On this page (6)
Evaluate a Salesforce managed services provider on seven things: a written scope that says what is and is not covered, response expectations defined by severity and business hours, the named people who will actually do the work, how changes are tested and released, what documentation you own, how progress is reported, and how easily you can leave. Price matters, but two proposals with the same monthly fee can buy very different amounts of real help.
Start with a scope you could hand to a stranger
Managed services proposals often describe the work in broad terms such as ongoing support and optimization. That wording is fine for a brochure and unhelpful in a contract. Ask for a scope written so plainly that a new admin at your company could read it and know whether a given request is covered.
- Which clouds, products and packages are covered, and whether that includes installed apps from AgentExchange (formerly AppExchange).
- Whether integrations are supported end to end or only on the Salesforce side.
- Which kinds of work are included: user administration, configuration, Flow, Apex, reports, data fixes, training.
- How new projects are handled: inside the monthly hours, as separate statements of work, or both.
- What happens to unused hours at month end, and what happens when a busy month runs over.
- Who on your side may submit requests, and who approves work that consumes a large share of the hours.
Watch for scopes that exclude the thing you most need. A provider that supports only configuration will not help much if your pain is a brittle integration with your ERP or a pile of undocumented Apex.
Response expectations, in plain terms
Every provider will say it responds quickly. What you want instead is a definition. Good agreements separate severity levels, state the hours during which each level is handled, and distinguish acknowledging a request from resolving it. A login problem affecting your whole sales team and a request to rename a report field should not share one target.
Be wary of anyone who promises round-the-clock coverage without explaining who is on call, how they are reached and what they are allowed to change in production at 2 a.m. For most organizations, clearly defined business-hours support with an agreed escalation path for true outages is more valuable than a broad promise nobody has tested. Ask how the provider handles a critical issue that arrives late on a Friday, and listen for a process rather than reassurance.
| Topic | A strong answer | A warning sign |
|---|---|---|
| Severity levels | Written definitions with examples from your org | Every request treated the same |
| Coverage hours | Stated hours and time zone, with how urgent outages are escalated | Vague claims of always being available |
| Acknowledge vs. resolve | Separate targets, with resolution tied to severity | Only a response time, which can mean an automatic reply |
| Request intake | One ticketing channel you can see, with status and history | Requests handled over personal email or text |
| Backlog visibility | A shared, prioritized list you can reorder | You learn what was done only from the invoice |
Find out who does the work
The people on the sales call are not always the people in your org. Ask to meet the admin, developer or consultant who will handle day-to-day requests, and ask how much of their week is assigned to your account. A named primary contact who knows your org is worth a great deal, because every handoff to someone new costs time spent relearning your data model and your history.
Ask as well how specialist work is covered. A good managed services arrangement gives you access to architects, developers and integration specialists when a task calls for them, without making you hire each one. Check certifications against the work you expect, ask where the team is based and which hours they keep, and ask whether any of the work is subcontracted. For comparison, our own U.S.-based team carries 138 certifications across Salesforce, Claude and Gong, and Abstrakt has held Salesforce Consulting Partner status since 2017.
Release management and documentation
How a provider changes your org tells you more than any case study. Ask them to walk through a recent change from request to production: where it was built, who tested it, how it was deployed, and how it could have been reversed. If the honest answer is that changes are made directly in production, expect surprises. You should also hear how they handle the three seasonal Salesforce releases each year, including reviewing release notes and testing in a preview sandbox.
Documentation is where many arrangements fail quietly. Ask what the provider writes down, where it lives, and whether it belongs to you. At a minimum you want a current description of your automation, integrations, custom code and security model, kept in a location you control rather than inside the provider's own tools. If your metadata is kept in source control, confirm the repository is in your account.
Reporting and exit terms
A useful monthly report covers hours used against the plan, requests opened and closed by severity, anything still waiting and why, changes deployed, risks spotted in the org, and recommendations for the next period. It should read like advice from someone paying attention, not a timesheet export. Ask whether a regular review meeting is included and who from the provider attends it.
Then read the exit terms before you need them. Look for the notice period, whether unused prepaid hours are refunded or lost, and what the provider commits to hand over on departure: credentials and integration users, documentation, open tickets and any code or repositories. Confirm that admin access and integration accounts are created under your company, not under a provider employee who might leave. A provider confident in its work rarely resists fair exit terms.
A shortlist of evaluation questions
- Who will be our day-to-day contact, and how many other accounts do they support?
- How do you define severity, and what are your coverage hours and escalation path for an outage?
- Walk us through the last change you deployed for a client, from request to production.
- How do you prepare an org for each seasonal Salesforce release?
- Which system records will you keep up to date, and in whose account do they live?
- What does your monthly report contain? May we see a redacted example?
- How do you start with a new org: a health check, a discovery period, or straight into tickets?
- What happens to unused hours, and what does a busy month cost?
- What do we receive if we end the agreement, and how much notice is required?
Score each provider's answers side by side, weighting the areas that matter most to your organization. A provider that starts with an assessment of your org, rather than simply opening a ticket queue, is usually the one that will still be improving the system a year from now.
Questions people also ask
How do I evaluate a Salesforce managed services provider?
Evaluate a Salesforce managed services provider on seven things: a written scope, response expectations by severity and business hours, the named people who will do the work, how changes are tested and released, what documentation you own, how progress is reported, and how easily you can leave. Price matters, but two proposals with the same monthly fee can buy very different amounts of real help. Ask for redacted samples of a monthly report and system documentation.
How do we avoid getting locked into one Salesforce support provider?
Make sure admin access, integration accounts, documentation and code repositories all live under your company, not the provider. Read the exit terms before you sign: the notice period, whether unused prepaid hours are refunded, and what the provider hands over when you leave, including credentials, integration users, documentation, open tickets and code. Keep your system documentation in a location you control rather than inside the provider's own tools. A provider confident in its work rarely resists fair exit terms.
Do we need Salesforce's paid support plan, or is a partner enough?
Every Salesforce license already includes the Standard Success Plan, so the real question is whether you also need Premier or Signature. Salesforce's plans provide case and incident support, and the paid tiers add 24/7 support for business-stopping issues, faster response times and expert guidance. A managed services partner covers different ground: administration, configuration, Flow, Apex, integrations and release reviews on your own org. Compare that scope against the plan features before paying for an upgrade.
Does Salesforce managed services include development work and integrations?
It depends on the contract, so check it line by line. Many plans cover admin work, user support and small changes, then treat custom code, new integrations and larger projects as extra. Ask which roles are in the plan, whether unused hours roll over, who monitors existing integrations, and how a request moves from support into a scoped project.
What should a company with about 100 Salesforce users look for in a managed services provider?
At about 100 users you usually need steady admin support plus occasional architecture, development and integration help, more than one hire can cover. Look for a named team that learns your org, clear response times, a backlog you can see, release testing and documentation you own. Ask how the plan flexes in a busy month, and what happens to your org knowledge if you leave.
How quickly can a managed services partner start supporting our org?
Support can start once access and handover are done, and how long that takes depends on your org. A partner needs logins and permissions, documentation or a guided review of the org, a list of open issues, and agreement on how requests are logged. An undocumented org takes longer, because the partner has to learn it first. If your admin is leaving, start before their last day so they can hand over directly.

