There is a classic trap.
You call it a "monthly package"...
but you are still selling emergencies.
That is the problem: if the client pays every month, but you still work like a firefighter, you have not created recurring service. You only changed how you charge.
A good monthly IT support package has scope, limits, routine, evidence, and price. It does not need to be huge. It needs to be clear.
1) Define what problem the client is buying
The client is not buying "monitoring."
They are buying fewer surprises.
They are not buying "patching."
They are buying computers that do not sit unmaintained for weeks.
They are not buying a "monthly report."
They are buying evidence that someone is watching the operation.
Before listing tools, write the package promise in one sentence:
``text We help keep your workstations visible, maintained, and supported every month, with remote help and clear evidence of what was done. ``
That sentence forces you to separate value from random tasks.
The SBA recommends looking at market, costs, and sales approach when shaping an offer. Its guides for marketing and sales and market research point to a basic rule: do not just set a price; understand who you sell to, what they compare, and what value they recognize.
Practical tip: if your package is explained as "included hours," the client will measure you by hours. Explain it as continuity, maintenance, and support with clear limits.
2) Start with one base package, not three confusing plans
At first, you want to sell everything.
Unlimited support, onsite visits, antivirus, backups, monitoring, servers, cameras, printers, email, networks, Wi-Fi, users, consulting...
And then it catches up with you.
Start with a base package you can actually deliver without inventing process every week:
- initial endpoint inventory;
- basic availability and health monitoring;
- critical alerts with an owner;
- monthly patch review;
- remote support during business hours;
- one channel for requests;
- short monthly report;
- recommendations for next month.
That already feels managed, but it is still controllable.
Practical tip: do not sell "everything included" if you do not yet know what each client consumes. Sell a clear base and define extras.
3) Set limits before the client sets them for you
Limits are not bad service.
They are healthy operations.
Your package should define:
| Limit | What to define |
|---|---|
| Endpoints | how many computers, servers, or devices are included |
| Hours | when you respond and when something is an emergency |
| Channel | where requests are submitted |
| Scope | what is included and what is quoted separately |
| Response time | starting expectation by priority |
| Visits | whether onsite work is included, limited, or separate |
| Projects | migrations, cabling, new servers, and major changes are outside |
If you do not write it down, the client will assume it.
And they will usually assume more than you meant.
Practical tip: use a simple sentence: "This package covers recurring operations. Projects, purchases, physical installation, and major changes are quoted separately."
4) Price from costs, not fear
Fear says: "Charge less so they say yes."
The numbers say something else.
The SBA explains that calculating costs helps estimate profitability and break-even point. Its guide to startup costs and its break-even calculator are useful because they force you to look at fixed costs, variable costs, and the volume you need before selling below your operation.
For an IT support package, separate:
- expected technical time;
- tools per endpoint;
- administration and follow-up;
- non-billable support;
- desired margin;
- risk of urgent work;
- report and monthly review time.
You do not need a perfect finance model. You need to avoid a price that keeps you busy and leaves no margin.
Practical tip: before quoting, calculate how many real hours you can spend on the client without losing money. If the package cannot survive 2 or 3 normal incidents, it is poorly designed.
5) Use endpoints as the operational unit
For a new IT business, counting endpoints is gold.
It gives you something concrete:
- how many computers you monitor;
- how many can request support;
- how many need patching;
- how many generate alerts;
- how many appear in reports.
That does not mean everything must be billed only per endpoint. It does mean endpoints help you control scope and workload.
Simple example:
| Size | Reasonable starting package |
|---|---|
| 10 endpoints | monitoring, basic remote support, monthly review, and short report |
| 25 endpoints | the above + alert policy, patch window, and light weekly review |
| 50 endpoints | the above + more formal follow-up, priorities, and executive report |
The point is not to copy the numbers exactly. The point is that the package grows with the operation.
Practical tip: if a client does not know how many computers they have, the first deliverable is inventory. Without inventory, every price is a guess.
6) Include remote support, but give it rules
Remote support can save you hours.
It can also eat your whole month.
Define from the start:
- what hours it covers;
- which channel starts a request;
- which problems are included;
- when it escalates to onsite work;
- when it becomes a project;
- what evidence is left after closing.
This is where an RMM helps the technician avoid going in blind. Before connecting, they can review inventory, alerts, pending patches, and endpoint context.
Practical tip: do not say "unlimited support" if what you mean is "remote support for normal operational incidents during business hours." Those are very different things.
7) Make the monthly report part of the product
The report is not decoration.
It is proof of value.
Your monthly report should answer:
- how many endpoints are under support;
- which relevant alerts appeared;
- which patches stayed pending or failed;
- which support sessions or tickets were handled;
- which risks need a client decision;
- what you recommend for next month.
CISA's Cyber Guidance for Small Businesses organizes actions by role and responsibility. For your package, that turns into something concrete: the client should know what belongs to you, what belongs to them, and which decisions cannot stay vague.
Practical tip: close the report with 3 lines: "done," "pending," and "decision required." That avoids pretty reports nobody uses.
8) Example of a basic monthly package
You can start with something like this:
```text Base IT Support Package
Includes:
- Up to 25 validated endpoints
- Initial inventory and monthly review
- Basic availability and health monitoring
- Critical alerts with follow-up
- Monthly patch review
- Remote support during business hours
- One support request channel
- Executive monthly report
Does not include:
- Infrastructure projects
- Cabling or unscheduled onsite visits
- Hardware/software purchases
- Migrations
- After-hours support
- Unregistered users or endpoints
```
This does not replace a legal contract. But it gives you a clear commercial base.
Practical tip: add a "scope changes" line. Every new endpoint, user, location, or service should update the package.
FAQ: first monthly IT support package
Should I charge per endpoint or per client?
You can combine both. A base client fee covers coordination, reporting, and minimum operations; the endpoint count adjusts technical workload. The important thing is that scope is not open-ended.
How many hours should I include?
Include hours you can sustain with margin. But avoid selling only hours. Define recurring activities, support limits, and rules for additional work.
What if the client wants unlimited support?
Clarify what that means. You can offer unlimited requests within a defined scope, schedule, and incident type, but projects, onsite visits, major changes, and after-hours work should be separate.
What should the first monthly report include?
Monitored endpoints, relevant alerts, patches, tickets or sessions, risks, and next steps. It should be short, clear, and useful for decisions.
How does Lunixar RMM help with this package?
It helps connect inventory, monitoring, alerts, patch management, remote support, and reports so the package does not depend on scattered spreadsheets or memory.
Close the package before selling it
A monthly IT support package is not improvised after the sale.
It is designed before.
Clear promise. Clear scope. Clear limits. Monthly evidence. And an operation you can repeat without burning out.
Lunixar RMM fits that workflow because it connects inventory, device monitoring, alerts, patch management, and remote connection in one console. If you are building your first monthly package, you can try Lunixar RMM for 14 days, with no credit card, up to 5 devices, and full access.
You can also keep reading:
