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 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 150 Salesforce certifications, 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.
