A Salesforce managed services agreement should define scope, request priorities, response versus resolution, covered hours and the named team. It should also settle unused hours, the release process, access controls, documentation, reporting, data ownership and exit. Pricing terms belong in writing too. This guide explains how to word each area, what to ask a provider, and which clauses should worry you.
Which document actually governs a managed services relationship?
Usually two: a master services agreement with the legal terms, and a schedule or order form describing the service itself. The service schedule is where the operational promises live, so read it as closely as the legal terms.
Liability caps, indemnities and governing law belong to your lawyers. This article covers the operational language. Scoping a one-off build is different, and our statement of work guide covers it.
How should scope be written so both sides agree on it?
Write scope as two explicit lists, covered and not covered, naming clouds, orgs and integrations. Anything on neither list should trigger a defined conversation rather than an argument.
A covered list might name the production org, specific sandboxes, Sales Cloud and Service Cloud configuration, named integrations and a set of installed packages. Typical work types include user administration, configuration changes, report building, flow fixes, release testing and small enhancements.
The not-covered list matters just as much. Common exclusions are large new builds, data migrations, third-party application support and work in systems outside Salesforce. Each exclusion should say how it would be handled instead, such as a separate quote or a change order.
- Name each org and sandbox by its purpose, not just its ID.
- List integrations by both endpoints, for example Salesforce to the ERP.
- State whether the provider supports managed packages or only escalates to the vendor.
- Define a size threshold that turns a request into a project.
How should request categories and priorities be defined?
Define priorities by business impact, not by how urgent the requester feels. Then ask each provider what it commits to for each level, in writing.
Separate request categories first. Incidents are things that worked and now do not. Service requests are routine asks such as a new user or a field change. Enhancements change how the system behaves. Advisory work covers roadmap and design questions. Each category can carry different handling rules.
Priority then applies mostly to incidents. A four-level scheme is common, and the wording below describes impact only. Fill in the targets with each provider, rather than accepting a template.
| Priority | Impact description | What to ask the provider |
|---|---|---|
| P1 (critical) | Salesforce is unavailable or a core process has stopped for most users, with no workaround. | What acknowledgement and update cadence do you commit to, and during which hours? |
| P2 (high) | A key process is badly degraded for a team, or a workaround exists but is costly. | Who triages it, and when does it escalate to a senior engineer? |
| P3 (medium) | A single user or minor function is affected and work can continue. | How is it queued against planned work, and how long may it wait? |
| P4 (low) | Cosmetic issues, questions and nice-to-have changes. | Is it handled within the hour plan or held for a backlog review? |
Also agree who may assign a priority and who may change it. Without that rule, every ticket drifts toward P1, and the scheme stops meaning anything.
What is the difference between response and resolution?
Response means a qualified person has acknowledged the request and started work. Resolution means the issue is fixed or a workable fallback is in place. Contracts should measure them separately.
Many agreements promise only response targets, because resolution depends on causes outside the provider's control. That is reasonable, but ask for something in between. A commitment to regular status updates on open P1 and P2 issues keeps you informed while a fix is underway.
An automated ticket receipt should not count as a response.
Which support hours and coverage windows should you define?
Decide whether business-hours coverage is enough or whether extended coverage is needed for certain priorities. Then name the time zone, the days and the holiday calendar.
Extended coverage is a choice with a cost, not a default. Some service operations need it for P1 incidents; many teams are fine with business hours and an escalation path.
- Name the time zone the clock runs in, especially across regions.
- List the holidays the provider observes, and whether yours differ.
- State whether the response clock pauses outside covered hours.
- Define how an urgent issue is raised after hours, if at all.
- Say who on your side may invoke out-of-hours escalation.
How do you protect continuity of the named team?
List the named roles, and ideally the people, in the agreement. Add a clause requiring notice and a handover when someone rotates off.
Continuity is often the thing clients value most and contracts protect least. Ask for a named primary contact plus a backup who already knows your org. If a named person leaves, require a written handover and an overlap period, at the provider's cost.
What should happen to unused hours?
The agreement should say exactly what happens to hours you do not use: they roll over, expire, or convert. Silence on this point always favors the provider.
Common approaches include a limited rollover window, a cap on carried-over hours, or conversion into planned improvement work. Each can be fair. Make sure the rule also covers overages: how they are approved, billed and reported before they happen.
Check what happens to banked hours at termination. Ask whether they are refunded, forfeited or must be used during the notice period.
How should the change and release process be described?
Describe the path every change takes: request, approval, build in a sandbox, test, deploy and document. Name who approves at each step on both sides.
- Who on your side can approve a change to production.
- Which sandbox types are used, and how often they are refreshed.
- Whether source control and a deployment tool are required.
- What testing evidence is shared before a release.
- Blackout periods, such as quarter-end or peak season.
- How emergency fixes are made and documented afterwards.
- Who reviews Salesforce's seasonal release notes for impact.
Salesforce releases three major updates a year. State whether the provider tests your critical processes in a preview sandbox before each one.
What access and security terms belong in the agreement?
Require least-privilege access, multi-factor authentication for every provider login, and named user accounts. Also require a defined offboarding procedure when people leave.
Provider staff should never share a login or a generic admin account. Grant each person only what their work needs, through permission sets you can review.
Offboarding deserves its own clause. When a provider team member leaves the account, their access should be removed within an agreed time. Any credentials, connected app secrets or integration users they set up should be rotated. Ask for a quarterly access review that lists every provider account and its permissions.
Regulated data adds obligations such as breach notification. Your security team should own this section.
What documentation and knowledge transfer should be required?
Require the provider to maintain current documentation in a location you own. Spell out what is documented and how quickly after each change.
At a minimum, that covers the data model, automation, integrations, security model and a change log. Documentation should sit in your repository or wiki, not the provider's ticketing tool. Ask for periodic walkthroughs with your admin so knowledge does not live in one person's head.
How should reporting and reviews be set up?
Agree on a recurring written report and a periodic review meeting with named attendees. The report should cover whatever the contract measures.
If the agreement sets targets by priority, the report should show performance against them. Add hours used, open items with their age, deployed changes and recommendations. A quarterly review with a sponsor from each side gives you a moment to adjust scope, priorities or the team before small issues compound.
Decide in advance what happens when targets are missed repeatedly, such as a remediation plan, service credits or a right to terminate.
What should the data ownership and exit clause say?
It should confirm that your org, data, metadata, code and documentation belong to you. It should also oblige the provider to support an orderly transition when the agreement ends.
- A notice period, and the service level that applies during it.
- A list of handover items: credentials, integration details, documentation and open tickets.
- Removal of all provider access by an agreed date.
- Transition assistance hours, and how they are billed.
- Confirmation that no proprietary tool or package is left holding your logic hostage.
Write this clause while the relationship is good. Our guide to switching Salesforce partners covers the practical handover itself.
Which pricing model terms need to be explicit?
Whatever the model, the contract should state what the fee buys, how usage is measured and how the fee can change. Ambiguity here becomes a dispute later.
For hour-based plans, define billing increments and what time counts, such as meetings and ticket triage. For fixed-scope plans, define the boundary of included work. In every model, state the term, renewal mechanics, notice for price changes and how out-of-scope work is quoted.
What are the red flags in a provider's contract?
Watch for vague scope, priorities the provider alone controls, and exit terms that make leaving expensive. Any of these shifts risk from the provider to you.
- Response targets with no stated hours, time zone or definition of response.
- A promise of continuous coverage with no named on-call process behind it.
- No named team, or a right to reassign people without notice.
- Unused hours that expire silently, with no reporting before they do.
- Shared or generic admin logins for provider staff.
- Documentation held in the provider's own systems only.
- Long auto-renewal terms with a narrow cancellation window.
- Exit assistance excluded, or priced only at the provider's discretion.
What does a contract review checklist look like?
Mark each area below as present, unclear or missing in a draft. Anything unclear goes back to the provider as a question.
| Area | What the agreement should state |
|---|---|
| Scope | Covered orgs, clouds, integrations and work types, plus named exclusions |
| Request categories | Incident, service request, enhancement and advisory definitions |
| Priorities | P1 to P4 defined by impact, with who assigns them |
| Response and resolution | Separate definitions, plus update cadence for open urgent issues |
| Coverage hours | Time zone, days, holidays and any extended coverage chosen |
| Named team | Primary and backup contacts, rotation notice and handover |
| Unused hours | Rollover, expiry, overage approval and treatment at exit |
| Change process | Approvals, sandboxes, testing evidence and emergency fixes |
| Access and security | Named accounts, least privilege, MFA, offboarding and access reviews |
| Documentation | What is documented, where it lives, and who owns it |
| Reporting | Report contents, review cadence and missed-target remedies |
| Exit | Ownership, notice, handover list and transition assistance |
| Pricing terms | Usage measurement, renewal, price-change notice and out-of-scope quoting |
Want a second opinion on a draft agreement? Our managed services team can walk through it with you.
