Every support quote rests on assumptions. When a provider is not given real numbers, it substitutes cautious ones: more users, more devices, higher demand, and a margin for the uncertainty. Much of the difference between a reasonable quote and an alarming one comes from those assumptions rather than the rate.
Estimating your own needs before you go to market changes the negotiation. You arrive with a description of the environment, a realistic view of demand, and a clear statement of which services matter most. That makes IT support contract pricing a conversation about coverage rather than a guess about your business.
The method below can be completed in an afternoon with information you already hold.
Count People and Devices First
This sounds trivial and is consistently underestimated. Support demand follows the environment, so that environment has to be described accurately before anything else is discussed.
People, including the ones who are easy to forget
Count full-time staff, part-time staff, contractors and anyone who uses a company account. Note how many work mainly on a shared terminal, since their support profile differs from someone with a laptop, a phone and remote access.
Devices and infrastructure
List workstations, laptops, tablets, phones, printers, servers, network equipment and any specialised hardware. Distinguish network-managed equipment from equipment that merely exists in the building. Include devices you inherited and never inventoried; unmanaged equipment often causes the most expensive surprises.
Locations and working patterns
Each site has its own network, physical access requirements and travel implications. Remote and hybrid patterns matter too, because supporting someone at home involves different tools and response expectations than a desk in a managed office.
Estimate Ticket Volume
Volume drives cost more than any other single factor. There are two ways to establish it.
Use your own history if it exists
Pull the last twelve months of requests from your helpdesk, email inbox, or the informal messages sent to whoever usually fixes things. Group them by category and by month. The monthly pattern matters as much as the total, because seasonal peaks change how much capacity you need.
Reconstruct it if it does not
Many smaller organisations have no ticket history, because requests arrive by phone or in a corridor. In that case, run a short exercise: for two to four weeks, ask staff to record every occasion they needed technical help, however small. The total is usually higher than expected.
What drives the number up or down
Staff turnover, onboarding volume, mobility, application changes and equipment age all push demand in predictable directions. A stable team on current hardware generates fewer requests than a growing team on four-year-old machines, even at identical headcount.
Classify the Work, Not Just the Count
Two hundred password resets are not the same as two hundred investigations, even though both are requests. Sorting work into categories prevents the mismatch where a simple environment is priced as if it were complex.
- Routine requests. Access changes, new accounts, software installations and simple how-to questions.
- Incidents. Something has stopped working: connectivity, hardware failures, application errors, security alerts.
- Preventative work. Patching, backup verification, capacity checks, review of alerts that nobody noticed.
- Projects. Migrations, rollouts, office moves and system replacements, which should be scoped and quoted separately.
- Advisory work. Planning, budgeting and policy questions that consume senior time rather than helpdesk capacity.
Presenting this breakdown gives the provider a basis for quoting rather than an invitation to guess.
Decide What Priority You Actually Need
Faster response costs more, so it makes sense only where the business genuinely feels the delay. Define a few urgency tiers and attach examples to each.
Consider what an hour of lost work costs across the teams affected. A finance team unable to invoice is a different problem from one user with a slow laptop. Being honest here prevents paying premium rates across the whole organisation when only a handful of systems justify them.
Plan for Growth and Change
Support arrangements are usually signed for a year or more, and the business will not stand still. Estimate headcount and device count twelve months ahead, note planned site changes, and mention anything on the horizon such as a move to cloud applications or an acquisition.
Sharing that outlook lets the provider propose a structure that grows sensibly rather than needing quarterly renegotiation, and it reveals whether they think about your business beyond the current invoice.
Set Response Expectations You Can Defend
Response targets should reflect your operations, not your preferences. A business running one shift has different needs from one trading around the clock. Write down your actual operating hours, what happens outside them, and which failures would justify waking someone.
Then compare what you wrote with what providers offer. A provider asking informed questions about your priorities is more likely to meet them than one agreeing to everything on the first call.
Turn the Estimate Into a Brief
- Write one page describing users, devices, locations and critical systems.
- Attach your ticket volume, or the results of a short counting exercise.
- Group the work into routine, incident, preventative, project and advisory.
- State the urgency tiers you care about and the hours you operate.
- Describe the next twelve months of expected change.
- Ask each provider to respond to that brief in the same structure.
Frequently Asked Questions
How accurate does the estimate need to be?
It needs to be defensible rather than perfect. A documented approximation prevents the worst pricing errors and gives both sides something concrete to revisit after the first quarter.
What if we genuinely do not know our ticket volume?
Run the counting exercise for a few weeks. It takes little administrative effort and usually changes the conversation, because internal teams routinely undercount the help they request informally.
Should we include devices that staff own personally?
Decide deliberately. If personal devices access company data or email, they belong in the scope discussion even if they are not company property, because their configuration affects risk and support effort.
Does a larger estimate mean a worse price?
Not necessarily. Accurate numbers usually produce a more competitive rate than inflated assumptions, because the provider can price against a known workload instead of building in protection against the unknown.
The Point of the Exercise
Estimating your needs is not administration for its own sake. It converts a vague request for support into a defined problem, and defined problems attract better proposals, clearer contracts and fewer arguments later.
This article provides general information about planning technology support and is not professional, financial or legal advice. Every organisation differs, so consult qualified advisers before making commitments.