What is typically included
At its core, the service covers routine administration and a route for users to ask for help. Beyond that, scope varies, so ask for a written list of activities instead of accepting a general description.
- User and access management. Creating and deactivating users, assigning permissions, and reviewing access.
- Support requests. Triage and resolution of questions and issues, with response targets.
- Small enhancements. New fields, page layouts, reports, flows, and validation rules delivered from a backlog.
- Release management. Reviewing seasonal releases, testing key processes, and preparing users.
- Health monitoring. Watching limits, errors, and integration failures.
Engagement models
Common arrangements include a monthly retainer of hours, a block of hours drawn down as needed, and tiered plans with defined service levels. Retainers provide predictability but may leave unused hours, blocks give flexibility without a fixed rhythm, and tiered plans offer clarity but can be rigid about scope. Compare what each includes and how requests are prioritized, not only the price.
In-house administrator, partner, or both
An internal administrator knows your people and priorities and is available daily. A partner offers a team with specialized skills, coverage during absences, and experience from many orgs. A common and effective pattern pairs an internal product owner who sets priorities with a partner that supplies capacity and expertise. This keeps context close and avoids dependence on a single individual.
Change management and adoption →Governance: how requests become changes
Without governance, an org fills with fields, flows, and permissions that nobody can explain. Set up a simple intake: requests are logged, reviewed against business value, and scheduled. Changes are built in a sandbox, tested, and released with documentation. Keep an inventory of automation and customizations with owners and review dates, and retire what is no longer needed.
Measuring whether it is working
Ask for regular reports covering response and resolution times, request volume and type, backlog age, repeat issues, and delivered enhancements. The trend should show fewer repeat problems and more time spent on improvements. Review the arrangement each quarter with the provider: are priorities aligned with the business, is the backlog moving, and are users satisfied?
Our Salesforce practice →Decisions to settle before you sign
- Scope boundaries. Define support, small changes, and projects and how each is handled and priced.
- Access and security. Agree how the provider accesses your org and how access is reviewed.
- Documentation. Require that documentation of configuration belongs to you and stays current.
- Exit terms. Understand notice periods and how knowledge transfers if you leave.
A realistic first 90 days
- Days 1 to 30. The provider reviews the org, documents customizations, and sets up intake and reporting.
- Days 31 to 60. Clear the backlog of known issues, tidy permissions and layouts, and test the release process.
- Days 61 to 90. Agree an enhancement roadmap, review the first full report set, and adjust scope or hours as needed.
Pitfalls to avoid
- No internal owner. A provider cannot set your priorities. Name a product owner.
- Unlimited requests with no prioritization. Everything urgent means nothing is. Use a ranked backlog.
- Undocumented changes. If nobody can explain what a flow does, every change is risky. Insist on documentation.
- Treating it as a cost to minimize. A well-run service prevents expensive problems. Judge it by outcomes.
