Nobody can tell you the right number of Salesforce support hours without looking at your own demand. Size the allocation from evidence instead. List the kinds of requests your org generates and count a few recent months of them. Sort each by effort, then add release cycles, planned projects and some headroom. Agree on what happens to unused time, and resize every quarter once real usage replaces the estimate.
Why is there no standard answer to how many hours you need?
Because support demand depends on your org, your users and your plans, not on license count alone. Two companies with identical editions can generate very different workloads.
A small team with one cloud, few integrations and stable processes may raise only occasional requests. A growing sales organization adding territories, products and reports every quarter will keep a support queue busy. Org condition matters too. Years of layered automation make each change slower to test and deploy safely.
Any provider quoting a figure before seeing your request history is guessing. A better first conversation is about the evidence you can gather. Most of it already sits in inboxes, chat threads and ticket queues.
Which kinds of requests should go into the inventory?
Every category of work that touches Salesforce, including work your team does informally today. Missing categories are the most common reason an allocation runs short.
Start with the routine items most people remember: adding and deactivating users, resetting access, building reports and dashboards, and adjusting fields, layouts or picklist values. Then list the less visible work. That includes enhancements such as new flows or record types, seasonal release reviews, integration error monitoring, duplicate cleanup and import jobs.
Finally, note any known projects on the calendar. A new business unit, a product launch or a finance system integration will consume time. The steady queue does not predict any of it. Keep projects on a separate line so they never hide inside the monthly average.
How do you measure what you use today?
Pull three to six recent months of requests from wherever they actually arrive, then count them by type. Tickets alone rarely tell the full story.
Requests reach a Salesforce admin through many doors. Some come through a ticketing tool or a Salesforce case queue. Many more arrive as emails, direct messages, Slack threads or a quick question in a hallway. Ask whoever handles the work today to forward or export everything from the sample period, including the informal asks.
If a previous admin has left, the trail may be thin. Check their sent mail, shared channels and the Setup Audit Trail, which records configuration changes made in Setup. Deployment history and change set records add more. Treat what you find as a floor, since undocumented favors never show up in any log.
Choose your sample months with care. A window that includes year-end, a reorganization or a major launch will skew the result. If you cannot avoid an unusual period, label it and keep it apart from the baseline months.
How should each request be classified by effort?
Sort requests into three or four effort tiers rather than estimating every item to the minute. Tiers are faster to apply and easier for a provider to check against its own experience.
A practical scheme uses quick fixes, standard changes, enhancements and projects. Quick fixes are things like a password reset or a new list view. Standard changes include a new report, field or validation rule. Enhancements involve design, testing and deployment, such as a new flow or an approval process. Projects need their own plan and should be scoped separately.
Then ask who could do each item. Some work needs only an administrator, while some needs a developer, an architect or an integration specialist. The skill mix matters as much as the count, because it changes who the provider must assign.
| Request type | How to count it | What pushes effort up |
|---|---|---|
| User administration | Joiners, leavers and access changes from HR lists and admin inboxes | Complex sharing, many permission sets, frequent reorganizations |
| Reports and dashboards | New or changed reports in the request trail, plus folder sprawl | Cross-object reporting, custom report types, executive rework cycles |
| Small configuration changes | Field, layout, picklist and validation requests per month | Fields used by integrations or automation that need impact checks |
| Enhancements | Requests that needed design or testing before release | Overlapping flows, legacy automation, missing sandboxes |
| Seasonal releases | Three per year; record the time spent on the last one | Custom code, managed packages, features Salesforce enforces automatically |
| Integration monitoring | Error alerts, failed syncs and vendor tickets over the sample | Number of connected systems, undocumented middleware, API limits |
| Data hygiene | Imports, merges, cleanup jobs and data-quality complaints | Weak matching rules, many entry points, external list loads |
| Known projects | Listed separately from the calendar and budget plans | Unclear requirements, dependencies on other teams or vendors |
How do releases and planned projects change the total?
They add predictable peaks on top of the steady queue. Plan for them by name rather than hoping the monthly average absorbs them.
Each year brings three seasonal Salesforce releases. Every one calls for reading release notes, testing in a preview sandbox and chasing anything that behaves differently. Orgs with custom code or several managed packages carry more release work. Look at how much time the last release took, then budget that effort into the months around each one.
Known projects deserve the same treatment. Write down what is planned for the next two or three quarters, with a rough effort tier for each. Some will fit inside a flexible allocation. Others are large enough that a separately scoped engagement is cleaner, so your routine support does not stall while the project runs.
How much headroom should you add on top?
Enough to cover the work your sample could not see. The right buffer depends on how confident you are in the data, not on a fixed rule.
A long, clean sample from a stable org needs less margin than a short, patchy one. Raise the buffer if a previous admin left with little documentation, or if a health check has flagged risks that will turn into tickets. Growth plans, new teams and pending integrations also justify more room.
Remember that the first months with any new provider include discovery. Someone has to learn your org, document what exists and fix small issues that were tolerated before. That ramp-up time is real work, so account for it rather than treating it as a surprise.
What should happen to hours you do not use?
Decide before you sign, because unused-time rules change the real value of any allocation. The main options are rollover, a capped rollover, or use-it-or-lose-it.
Rollover protects you in quiet months but can build a balance nobody plans to spend. A cap with an expiry date keeps both sides honest. If time does expire, agree on standing work that can absorb it: documentation, technical debt reduction, report cleanup or the next roadmap item. A short list of fallback tasks turns slack months into progress.
Overages need the same clarity. Agree in advance whether extra work pauses, moves to the next period or is billed separately, and who must approve it. The pricing models guide linked below covers how these terms differ by contract type.
What are the signs you are under-buying or over-buying?
Under-buying shows up as a growing backlog and frustrated users. Over-buying shows up as a provider waiting for work while improvements go unplanned.
- Under-buying: requests sit untouched for weeks, and users stop asking because nothing changes.
- Under-buying: releases arrive without testing, and new features are switched on by default with nobody reviewing them.
- Under-buying: integration errors are noticed by customers or finance before anyone on the support side sees them.
- Under-buying: every month ends at the limit, and enhancement work never starts.
- Over-buying: a large share of the allocation goes unused or is spent on low-value requests to fill time.
- Over-buying: monthly reports show the same small tasks repeated, with no roadmap progress recorded.
- Over-buying: you rarely raise requests because nobody internally owns the backlog.
The last over-buying sign is often an ownership problem rather than a sizing one. An allocation only delivers value when someone on your side collects requests, sets priorities and confirms the work is done.
How do hours relate to retainer, fixed-scope and dedicated-team models?
Your demand estimate is the same input for every model; only the way it is packaged changes. Bring the worksheet to every provider conversation.
In a retainer, the estimate becomes a monthly bank, and the rollover decision matters most. In a fixed-scope agreement, it becomes a list of covered services, so the classification by request type matters most. For a dedicated team, it shows whether you have a steady build backlog or mostly reactive support. Our guide to managed services pricing models explains the trade-offs of each in detail.
Sharing your inventory with providers also makes proposals comparable. Each one is answering the same question with the same evidence, rather than sizing against its own assumptions.
How often should the allocation be reviewed?
Quarterly is a sensible rhythm. That is long enough to smooth out a single busy month and short enough to catch a sizing mistake early.
At each review, compare actual usage by request type against the original estimate. Check how the backlog has moved, what the last release cost and which projects are coming next. Note where repeated requests could be removed by fixing the cause, such as a confusing page layout or a report that users rebuild each month. A good provider will propose those fixes, because lowering avoidable demand frees time for work that moves the business forward.
Adjust in either direction. Shrinking an allocation after a period of cleanup is a healthy outcome, not a failure. Growing it ahead of a planned expansion beats running short in the middle of one.
Abstrakt Solutions, a Salesforce Select partner since 2017, supports orgs across every department. If you want help turning your request history into a sizing estimate, our managed services team can review it with you.
