Salesforce

Salesforce Is Live.
But Who's Keeping It Under Control?

Abstract network of connected points on a dark blue background

Your Salesforce doesn't have to be broken to become a problem. In fact, that's what makes the problem easy to miss.

The system is live. Users can do their jobs, requests get handled, the occasional issue gets fixed. But behind the scenes, small changes keep adding complexity and routine Salesforce maintenance eats into your team's time. The Salesforce optimization that could make Salesforce more useful, such as the long-awaited automation or a proper investigation of recurring data issues, keeps getting pushed down the list.

When maintaining Salesforce takes most of the available time, improvement becomes something you'll get to later. And later has a habit of never arriving.

So the question isn't just who fixes Salesforce when something goes wrong. It's who makes sure the platform keeps evolving with your business.

Why Salesforce Gets Harder to Manage Over Time

Salesforce evolves alongside the business. Processes change, automations are added, integrations multiply, reporting becomes more demanding. The challenge isn't the complexity of any single change. It's understanding how that change affects everything already in place.

A new automation might interfere with an existing process. A permission change could stop a colleague from completing an important task. An integration error might leave data incomplete without any obvious warning. When changes are poorly documented and only a few people understand how the system works, even routine Salesforce platform management becomes risky. And when issues are handled only after someone reports them, preventive work slips down the priority list.

The problem isn't that Salesforce needs maintenance. It's that maintenance needs clear ownership, time and the right expertise.

Without them, technical debt accumulates and the business becomes dependent on whoever happens to know how the system works.

Does Your Salesforce Need More Support?

There's no user count that automatically means you need Salesforce Managed Services. Look at how Salesforce is maintained today:

  • Issues are addressed only after users complain.
  • Your administrator is too busy with routine requests to work on improvements.
  • Only one person understands key automations or integrations.
  • Changes are made directly in production, or without consistent documentation.
  • Salesforce releases create uncertainty about existing processes.
  • Access rights, errors and system limits aren't reviewed regularly.
  • You have little visibility into support activity, recurring issues or the improvement backlog.
  • When something breaks, it's unclear who owns it and what happens next.

One sign alone doesn't mean you need a managed service. If several sound familiar, it's worth looking at where the gaps are.

Who Benefits Most

Salesforce Managed Services fit best when Salesforce is important to daily operations but internal capacity hasn't kept pace. This usually happens in two situations.

Your Salesforce admin is overloaded.

Your admin knows the business and supports users and handles day-to-day Salesforce administration. But integrations, custom development, release management and complex technical decisions require additional expertise.

Hiring a full specialist team may not be practical. External Salesforce technical support services cover the gaps while your admin keeps ownership of the business context and user needs.

You rely on whoever is available when something breaks.

Support comes from a single developer, a previous implementation partner or whoever has time to look at the latest issue.

That informal Salesforce post-implementation support works for a while. But nobody is clearly responsible for the system's ongoing health, documentation and future improvements.

In both cases the business expects Salesforce to support increasingly important processes, while the time and expertise to maintain it haven't grown with it.

From Fixing Tickets to Managing Salesforce Properly

A support service resolves individual issues. A Salesforce Managed Services model, often called Salesforce AMS (Application Management Services), also covers the processes that stop those issues from becoming a recurring burden. ITG's approach has four connected blocks, each with a defined pool of service hours behind it.

Incident: you know what needs attention first.

When something stops working, you raise a request by email or through the portal. It's logged as a ticket with a status and an SLA clock. The team assesses the business impact, works towards a fix or workaround and keeps you informed. A system-wide outage isn't treated like a minor report adjustment.

Change: no surprises in production.

Changes of four hours or less are handled directly from the agreed hour pool, and you're notified of the work done and the hours used. Anything larger gets a written estimate for your approval before work begins, and the same applies if the pool is exhausted. Every change is tested in a sandbox before deployment and documented for future reference.

Prevent: risks reviewed before they become disruptions.

Health checks, access and security reviews, error and limit monitoring and Salesforce release preparation help catch what would otherwise go unnoticed. These Salesforce maintenance services run from once to four times a year for health checks and access and security reviews, depending on the package.

Govern: visibility into the work and the budget.

Monthly reports cover tickets, hours and response performance. Service reviews are the place to discuss priorities and upcoming improvements. A named service lead and deputy give you clear points of contact.

Larger initiatives, such as a new integration, a migration or a new Salesforce product, are scoped and billed separately, so you know what the work involves before committing. Optional modules are priced separately and added only on request.

One more principle: your knowledge stays with you. Documentation, deployment history and operating instructions belong to the client. If the relationship ends, the handover includes what's needed to transition the service. The aim is to make Salesforce easier to manage, not to make you dependent on a provider.

What Kind of Request Is It?

Each request is categorised on arrival, and the type decides how it's handled and where the hours come from.

TypeWhat it isHow it's handled
DefectA functional deficiency in standard Salesforce, or in a custom build that doesn't meet its documented requirementsFree within the warranty period if caused by ITG's work; otherwise a Change Request
IncidentAn unplanned interruption or drop in quality; the goal is a quick fix that restores the serviceHour pool, with the package SLA
SupportInformation, advice, coaching or training, with no changes to the systemHour pool; analysis up to 2 hours, anything longer agreed in advance
Change RequestA request to add, change or remove functionality, such as picklist values or process flowsUp to 4 hours: from the hour pool. Over 4 hours: written estimate and approval first
ProjectBundled changes, a new integration, a migration or a new Salesforce productOutside the managed service: separate estimate and SOW

The type tells you upfront whether a request is covered by the hour pool, needs an estimate or is big enough to become a project of its own.

Response Time Isn't Resolution Time

When comparing Salesforce support SLA, check what the provider actually commits to. Salesforce response times is how quickly the team acknowledges a request and starts analysing it. Resolution time is how long it takes to fix the issue. They aren't interchangeable, and a response target doesn't guarantee a fix within a fixed period.

ITG uses three priority levels:

PriorityWhat it means
P1Most users cannot work and there is no practical workaround, for example login failures, SSO problems or an integration failure.
P2An important process or group of users is affected, but a workaround exists.
P3An individual user has a question or a minor issue that doesn't stop the business.

Targets are measured in service hours. The SLA clock pauses while the team waits for information, access, testing or approval from you, or for a third-party vendor. External disruptions, such as Salesforce platform outages, are excluded from SLA breach calculations. The resolution targets in the table below are targets, not guarantees: the actual time depends on the complexity of the issue.

Choosing the Right Level of Support

Not every environment needs the same level of Salesforce CRM support. An org built on standard configuration and Flows has different needs from one running custom Apex, Lightning Web Components, several integrations and AppExchange packages. Business impact matters too: an issue for one sales team differs from an outage across several departments.

Essential: orgs built mainly on standard configuration and Flow.

Advanced: adds custom code, integrations and AppExchange packages.

Premium: business-critical environments with demanding operations, frequent releases or complex architecture.

EssentialAdvancedPremium
Response (P1 / P2 / P3)4h / 8h / 16h2h / 4h / 8h1h / 2h / 4h
Resolution target (P1 / P2 / P3)8h / 16h / 32h4h / 8h / 16h2h / 4h / 8h
Scope of changesConfiguration and FlowEssential, plus Apex, LWC, integrations and AppExchange changesAdvanced, plus architecture reviews and a prioritised improvement backlog
Release managementRelease notes reviewed, relevant changes flaggedPlus sandbox regression testingPlus user briefings and rollout planning
Health checkOnce a yearTwice a yearQuarterly, with improvement priorities
MonitoringMonthly review of Salesforce limitsPlus Flow and Apex job errorsPlus automatic alerts for agreed error scenarios
Sandbox managementRefresh on requestPlanned refresh twice a year, with a checklistPlanned refreshes, plus test-data seeding/masking and developer support
Backup and deployment historyOptional add-on or separately estimatedOptional add-on or separately estimatedIncluded (scope to be confirmed)
Service reviewsQuarterly, 30 minMonthly, 45 min, plus quarterly reviewEvery two weeks, plus quarterly business review
ReportingMonthly activity reportMonthly activity reportMonthly report plus adoption KPIs

The differences go beyond support hours: response levels, preventive work, release testing and governance all change. The right package depends on technical complexity, how heavily the business relies on Salesforce and what downtime would cost.

Extending a Package with Modules

A package is the baseline. Some needs apply only to some clients, so ITG offers optional modules, each priced separately. You extend the service only where your environment requires it.

Safety Net is a good example. It covers backup of data and metadata, a quarterly restore test, deployment history, monitoring of metadata changes and source control. The restore test matters as much as the backup itself: a copy that has never been restored is an assumption, not a safeguard.

Optional modules allow clients to tailor their service to specific needs, from integration monitoring and usage analytics to extended support hours and 24/7 coverage for critical incidents. Additional options include faster response times, sandbox environment management, prepaid hours for extra changes, and dedicated teams for larger clients

Modules extend a package; they don't replace choosing the right one. ITG can help you decide which you need.

When Salesforce Managed Services Aren't Enough

Ongoing support doesn't replace every Salesforce project. A new implementation, a major enhancement, a new cloud, a large data migration or licences need their own scope, budget and delivery plan.

The same applies to environments with significant technical debt or undocumented changes. Before support begins, we may assess the current org to find existing issues and risks. Work needed to address significant problems is estimated separately rather than quietly absorbed into routine support. This gives you a realistic starting point and keeps a support arrangement from carrying work it was never designed to cover.

Salesforce Needs an Operating Model, Not Just a Support Contact

Salesforce isn't a finished project once it goes live. Processes change, integrations evolve, users need help and new requirements keep appearing. Keeping the platform useful takes clear ownership, controlled changes, preventive maintenance and enough visibility to decide what happens next.

That's what ITG Salesforce Managed Services is built to provide: Salesforce support services and managed support for today, and a structured way to improve it as your business changes.

Not sure where your Salesforce stands today?

Start with a 30-minute Managed Services assessment. We'll look at how your org is maintained now, where the gaps are and which package, if any, fits your environment. You'll leave with a clear picture of the risks and a realistic starting point, whether or not we work together.