There's a conversation that plays out in almost every company two or three years into Salesforce. Someone on the business side asks for a new report and the answer comes back: "that has to go through IT, and they're swamped." Or worse: "that report already exists, but nobody trusts it."
That isn't a support problem. When something breaks, someone fixes it. The problem is everything else: all the things that never quite break but stop answering what the business actually needs.
The queue that never moves
A Salesforce org without maintenance doesn't fail all at once. It degrades.
It almost always starts with something small. A new field on the intake form. An alert when an opportunity has sat untouched for thirty days. Nothing complicated — and still nobody picks it up, because the technical team is busy with what's urgent and this isn't.
That's how a queue forms. Ten, twenty requests that were never a priority and never got done. And while the queue grows, the business doesn't wait: someone builds the spreadsheet that does what they need. Someone else copies the data into their own tool. Without anyone deciding it, Salesforce stops being where the work happens.
That queue is the problem. Not the incidents.
On top of that, the platform moves on its own. Salesforce ships three releases a year, and each one brings capabilities that could replace something your team still does by hand. If nobody reviews them, nothing breaks — you just pay for features you don't use.
Meanwhile, the day-to-day leaves its residue. A field created for a project that got cancelled. Three reports measuring the same thing by different criteria, and nobody knows which one is right. A flow that got duplicated because copying it was faster than understanding the original. Users who left the company months ago and still hold an active licence.
Taken separately, almost none of this ever generates a ticket. Taken together, it explains why eighteen months later the sales team is back on a spreadsheet.
The warning sign isn't Salesforce failing. It's people starting to work around it.
Why the reactive model falls short
The usual arrangement — a vendor you call when there's an incident — isn't bad. It's incomplete, for a structural reason: it only kicks in once there's already damage.
Nobody opens a ticket asking for help deciding whether an initiative is worth doing. Nobody calls their vendor to ask whether what was built two years ago still makes sense, or whether it should be rebuilt before anything else gets stacked on top. Those tasks have no one to request them, so they don't happen.
The result is paying to correct what could have been avoided. And there's a cost that shows up on no invoice: everything the platform could be doing and isn't, because nobody has been given the job of looking ahead.
Three ways out, and what each one costs you
There are three ways to solve this, and none of them is best for everyone.
Hiring an in-house administrator
This works when your operation is large and stable enough to justify a full-time person, and you need someone who knows the business from the inside and sits in the meetings.
The honest downside: it's a fixed cost, and it's one person with one profile. A good administrator isn't necessarily a good Apex developer, or an integrations architect, or a Field Service specialist. When something outside their remit comes up, you're looking for help anyway. And you have to plan around absences: holidays, sick leave, training.
Then there's concentration risk. When that knowledge sits with one person — why a flow is configured the way it is, what was tried and didn't work, what depends on what — their departure can become a serious operational risk. Replacing them isn't just recruiting: it's months before someone new is productive.
Freelance, on demand
This works when your needs are occasional and spread out, and you have someone internal who can direct the work.
The honest downside: availability depends on that person's schedule, and they're working for several clients at once. When your incident lands during a peak on another project, the response can take a while. And because each piece of work is contracted separately, the natural focus is closing the task in front of them rather than looking after how the whole thing holds together — unless there's a continuous relationship, which is exactly what this model doesn't guarantee.
Managed service
This works when you need several skill sets but none of them full-time, and you want someone accountable for the state of the platform, not just for the tasks you hand over.
The honest downside: there's a ramp-up. Formal onboarding takes weeks, but fully understanding an operation — its exceptions, its unwritten agreements, why something was done a certain way — takes longer than that. It also isn't a model where you can step away entirely: someone on your side has to prioritise the queue and sign off on decisions. And you pay for monthly capacity whether you use all of it or not — which is why it matters to understand exactly what happens to the hours you don't consume.
One clarification, because it's a common misreading: a small, stable operation isn't a case where this model is overkill. It may be the one where the decline goes most unnoticed. When nothing is urgent, nobody reviews; and two years on, the "we'll improve that someday" list is longer than the original backlog. That's what the entry tier is for: reduced capacity, enough to keep the platform moving forward.
What to demand from a managed service
If you go this route, five things separate a real service from a support contract wearing a different name. They work for assessing any provider, including us.
1. That it covers all four fronts, not just the first. Support for the operation, platform administration, continuous evolution, and prevention. If the proposal only talks about resolving incidents, it's support. Evolution — the platform gaining capabilities regularly and predictably, on an agreed cadence — is the part that empties the queue.
2. That there's a governance mechanism, not just a bucket of hours. A visible backlog, a cadence for prioritising it, and criteria for deciding what gets done, what waits, and what shouldn't be built at all. Hours indicate capacity; they don't guarantee direction. Ask who turns business objectives into a plan and how progress is measured: without that, the queue stays stuck no matter how many hours you're paying for.
3. That someone assesses your initiatives, not just executes them. When you ask for something, the useful answer isn't "that's eight hours": it's whether it makes sense to do it that way, whether it fits what already exists, and whether there's a standard way to get there without custom development. A provider that only does what you ask builds technical debt on your budget. This is also where release reviews belong: which new capability is useful to you, and which change affects you, before it arrives.
4. That the SLA is contractual and measurable. "We respond quickly" isn't a commitment. A first-response time for a critical incident, in writing and differentiated by severity, is.
And there's a question that matters as much as the number: what happens after that first response. How often they update you while the case stays open, who escalates and when, and what happens if the cause sits with a third party or with Salesforce itself. Be wary of anyone promising a fixed resolution time for any incident: resolution depends on factors no provider fully controls, and committing to it without qualification is more a sales technique than a real commitment. What you can legitimately demand is a clear process and consistent communication.
5. That knowledge is transferable and the exit is orderly. Documentation is necessary but not sufficient. Confirm that your company retains control of access and ownership of configurations and code, that decisions are justified in writing, and that there's a handover procedure if you ever change providers. That's the underlying protection against lock-in.
How we approach it
With those five criteria on the table, here's how we work.
A team, not a person. A managed service brings in whoever the month calls for: administration, functional consulting, development, architecture. You don't hire one profile and hope it covers everything.
Field Service specialisation. It's where we go deepest: implementations for more than 9,000 users in field operations, with integrations to legacy systems and the problems that turn critical at that scale. If your Salesforce includes field operations, that specialisation shows in the kind of questions we ask.
Agentforce in production, not in a slide deck. The assistant you see on this site — Maia, the chat in the corner — is ours, built with the same technology we implement for clients. It doesn't replace a case study or a technical assessment, but it's public proof that we don't talk about Agentforce from a presentation only. You can try it right now.
Evolution with judgement, not just execution. Every initiative gets assessed before it gets estimated: whether it solves something worth solving, whether it fits what already exists, and whether there's a standard route that avoids custom development. On top of that come health checks, architecture reviews and a review of each release. The goal is twofold: that most problems never become problems, and that the improvement queue moves forward without creating a new queue of technical debt.
Unused capacity has explicit rules. Depending on the plan, up to a quarter — or all of it, at the highest tier — of unused hours can roll into the following month, and you can also draw down a defined percentage of future capacity when a peak hits. The percentages are set per plan at the start of the contract, not negotiated case by case. It's a clause worth always asking about, with us or with any other provider: what exactly happens to the hours you don't use, and whether it's in writing.
A written SLA, differentiated by severity, with first-response times for critical incidents ranging from 12 hours at the entry tier to 1 hour at the highest, within the contracted coverage window. And for what comes after that first response, a defined process for follow-up and escalation.
Where to start
Before choosing a plan, the useful question isn't "how many hours do I need?" Nobody can answer that cold.
There are three that do have an answer today, and they tell you more than any estimate made in the abstract:
- How many improvement requests are outstanding? Not the ones in progress: the ones someone asked for that are still waiting. If you have to go digging through email or someone's memory to find them, that's already your answer.
- How long does it take to start work on a new initiative? Not to finish it — to start it. When the business asks for something and six weeks pass before anyone touches it, the bottleneck isn't technical capacity. It's that nobody has been given the job.
- How long has it been since anyone checked whether what was built two years ago still makes sense?
If those answers make you uncomfortable, the problem isn't support. It's a queue nobody is moving.
In the next article we break down the four managed service tiers and which operating profile fits each one.
Would you rather start from your specific situation? Request a free assessment and we'll review the state of your platform before proposing anything.
