A marketing agency finishes a campaign, invoices it, and moves on. An MSP rarely gets that clean a boundary. The same client paying a flat monthly retainer for help-desk support might also be three weeks into a scoped infrastructure migration, billed under a completely different arrangement, delivered by some of the same engineers. That overlap is normal in IT services, and it's exactly what breaks tools built only for one-off project delivery.
In this guide
Why IT services delivery doesn't fit the standard agency model Tracking tickets and projects without two systems SLA visibility leadership and clients both need Billing a retainer with overage, correctly Capacity planning for a split team Frequently asked questions
Why IT Services Delivery Doesn't Fit the Standard Agency Model
Most professional services tools are built around a single assumption: a client relationship equals a project, with a start date, an end date, and a scope in between. IT services and MSPs break that assumption constantly. A single client account might carry an ongoing support contract that never technically closes, alongside a rotating set of discrete projects, a network upgrade this quarter, a security audit next quarter, that do have defined boundaries.
The two workstreams aren't separate businesses, they're one relationship viewed two ways. The same account manager owns both. Often the same technicians deliver both. And the client sees one vendor, not two, regardless of how the back office splits the work internally. When the software forces a hard separation between "support" and "projects," the business ends up maintaining that separation manually, in spreadsheets, side conversations, and end-of-month reconciliation that nobody enjoys.
Tracking Tickets and Projects Without Two Systems
The practical problem shows up first in time tracking. An engineer's day rarely sorts itself neatly into "support hours" and "project hours." They might close four tickets before lunch, spend the afternoon on a scoped migration task, and pick up an urgent break-fix call before logging off. If tickets live in a help-desk tool and projects live in a separate PSA or spreadsheet, that engineer is now logging time twice, or more likely, logging it inconsistently in one system and not at all in the other.
The fix isn't picking one tool and forcing everything into it, it's using a platform where a support ticket and a project task are both just work items that consume the same person's time against the same client record. Autovella treats ticket-based support work and scoped project work as first-class citizens in the same time-tracking and reporting layer, so a technician logs time once, against whichever piece of work they're actually doing, and it rolls up correctly whether that hour needs to be measured against a retainer allotment or a project budget.
That single view matters beyond convenience. It's the only way to answer a question every IT services owner eventually asks: is this client, taken as a whole across support and projects, actually profitable, or is the project margin quietly subsidizing an under-priced support contract?
SLA Visibility Leadership and Clients Both Need
Support contracts almost always come with service-level commitments, response time and resolution time, usually tiered by ticket priority. A critical outage might promise a 30-minute response and a 4-hour resolution; a low-priority request might promise same-day acknowledgment. Those numbers aren't just internal targets, they're often written directly into the contract, which means missing them has both an operational cost and a contractual one.
The catch is that SLA performance needs two different audiences to see it in two different ways. Leadership needs an aggregate view: response and resolution times trending across the whole support desk, broken down by technician or by client, so a slipping average shows up as a capacity problem before it becomes a churn problem. Clients, meanwhile, often want a much narrower view: how their tickets specifically have performed against the commitments in their contract, ideally without having to ask for it.
An SLA that only leadership can see is a metric. An SLA the client can see too is proof. Firms that expose response and resolution performance directly to clients, through a portal rather than a monthly PDF, tend to spend far less time defending their service quality in renewal conversations.
This is where a client portal tied to the same ticket and time data earns its keep, the client sees the same numbers leadership sees, updated as work happens rather than reconstructed for a quarterly business review.
Billing a Retainer With Overage, Correctly
Most MSP support contracts follow the same basic shape: a flat monthly fee that includes a set number of hours, with additional hours billed at an hourly overage rate once that allotment runs out. It's a simple idea that gets surprisingly easy to bill wrong. Getting it right requires the billing system to know, in real time, exactly how many included hours a client has consumed this cycle, so overage only starts accruing at the right threshold rather than from hour one or, worse, never at all because nobody was tracking the cutoff.
Layer a project on top of that same client and the billing logic has to hold two models at once without letting them bleed into each other: the retainer's included-hours math running on its own cycle, and the project's fixed-fee or milestone billing running on its own schedule, both invoicing the same account without double-counting a technician's time or missing it entirely.
- Track included support hours against the retainer in real time, not at month-end
- Trigger overage billing automatically once the allotment is used, at the agreed rate
- Keep project invoicing on its own milestone or fixed-fee schedule, separate from the retainer
- Attribute every logged hour to exactly one bucket, retainer or project, never both
- Give account managers a running view of hours remaining, so overage isn't a surprise on the invoice
When retainer and project billing run through the same platform against the same underlying time records, this stops being a manual reconciliation exercise every billing cycle and becomes something the numbers simply reflect on their own.
Capacity Planning for a Team Split Between Support and Projects
The hardest scheduling problem in IT services isn't planning a project, it's planning a project on a team that also has to absorb whatever support tickets show up that day. Reactive work is, by definition, not fully predictable. An engineer might be booked for six focused hours on a migration and lose two of them to a client emergency, and that's not a scheduling failure, it's the nature of the business.
Capacity planning that ignores this reality sets project timelines that look reasonable on paper and slip constantly in practice, because the plan assumed 100% of an engineer's time was available for planned work. A more honest approach reserves a realistic buffer, based on historical ticket volume, for reactive support before committing the remainder of the team's capacity to project delivery. That buffer should be visible in the same scheduling view as project assignments, not tracked separately, since it's competing for the same hours from the same people.
Over time, tracking how much of the team's actual capacity went to support versus projects, and comparing it against what was planned, turns capacity planning from a guess into a forecast grounded in the firm's own delivery history.
Run support and projects on one connected platform
See how Autovella ties tickets, SLAs, retainer billing, and project delivery to the same client record.
Frequently asked
Most MSPs bill a flat monthly retainer that includes a set number of support hours, then charge hourly for anything beyond that allotment. Project work sold to the same client is usually quoted and billed separately, so both models have to run side by side without becoming two disconnected billing processes.
Yes, because the same engineers usually split their day between both, and a client relationship often includes an active retainer and an active project at the same time. Tracking them separately makes it nearly impossible to see true utilization or true profitability per client.
Response time and resolution time, broken down by ticket priority, are the two metrics that matter most to both leadership and clients. Leadership uses them to spot capacity problems before they cause churn, and clients often have them written into the contract as commitments.