decision digitalAIMSP Framework & MethodologyHere’s what each one means before you meet it in context. Every dollar figure in AIMSP traces back to the first one.
A reference table, not a metric. We build it from your own ConnectWise ticket history: for each ticket type your engineers have resolved, we calculate the median time it took, not the average, because a handful of long-running tickets would drag an average well above what a typical ticket really costs. That median becomes your baseline. Think of it as an internal price list for human resolution time. Every dollar figure that follows (HTE, MOS, TDS) is calculated from it. Nothing else in the framework works without it.
Where SHRT is the reference table, HTE is what you do with it. When automation closes a ticket that would have taken an engineer 45 minutes, HTE captures those 45 minutes, multiplied by your labor rate, as a dollar figure. The measurable value of automation, expressed in engineer hours avoided. Not an estimate. Not an industry average. Your tickets, your history, your number.
When your NOC or SOC resolves a ticket under a flat-rate agreement, or a vendor platform you pay for per device or per user fixes and closes its own ticket, that work has a real labor value that never shows up in your reports. MOS calculates what it would have cost if your own engineers had done it, using your SHRT table as the baseline. For most MSPs this number is significant, and it’s been invisible until now.
Every ticket that gets automatically profiled, classified and routed is a ticket a human dispatcher didn’t have to touch. TDS measures the time saved across all of those routing events, applied at dispatcher rate, because that’s the cost it replaces. Small per ticket. Significant at the volume most MSPs run.
The diagnostic output. ARI pulls HTE, MOS and TDS together into a single report built entirely from your ConnectWise data. It tells you where you stand, what your automation is actually worth in dollars, and where the highest-value gaps are. Your operation, measured correctly, for the first time.
The case against utilization, and the operating model that replaces it.
decision digitalAIMSP Framework & MethodologyAIMSP: Autonomously Intelligent MSP. An operating model. Not a tool. Not a certification. A way of running your MSP where automation and managed partners handle the majority of your ticket volume, and your engineers spend their time on work that actually requires human expertise.
An AIMSP has three defining characteristics:
The majority of ticket volume is resolved without your engineers touching it.
Everything automation and your managed partners do is measured and valued in dollars.
Traditional utilization has been replaced by metrics that reflect how the operation actually works.
The 75% utilization benchmark measures billable hours against available hours, for client-based work only. It was built for a world where humans performed every ticket action. That world no longer exists. When automation closes 25 to 40% of your tickets and a managed NOC resolves another 15 to 25%, those contributions are invisible to a utilization report. AIMSP replaces the single percentage with a set of metrics that credit automation, partners and engineers for the work each one actually does.
decision digitalAIMSP Framework & MethodologyAn AIMSP operates across three layers. Think of them as a building: the floor has to be solid before anything above it can hold weight. Each layer builds on the one before it.
Most MSPs already have Layer 1 in place. The work of an AIMSP engagement is building Layer 2 correctly, because that’s where the value gets measured, and using Layer 3 to show what that value is worth.
decision digitalAIMSP Framework & MethodologyThe word “engineer” has always meant more than “technician.” A technician executes established procedures. An engineer applies judgment, designs solutions and owns outcomes.
That distinction didn’t matter much when every ticket required a human to touch it. It matters now. When automation handles 25 to 40% of ticket volume, when a managed NOC absorbs another 15 to 25%, when intelligent triage profiles and routes work before a human sees it, your engineer’s role doesn’t shrink. It expands. The title stays the same. The meaning changes fundamentally.
In an AIMSP, your engineer resolves what automation cannot, oversees what automation handles, and builds what automation needs next. Every engineer works across all three dimensions at once, in proportions that shift as the operation matures.
Complex work that requires human judgment: security incidents, architecture decisions, escalations beyond any workflow or partner. As the operation matures, this becomes a larger share of what engineers touch, even as it becomes a smaller share of total ticket volume.
The judgment layer above the automation. Automation handles the first pass; your engineer reviews exceptions, interprets edge cases and makes the calls no script can. An engineer who supervised 200 automated resolutions this week contributed something real. Under utilization it was invisible. Under AIMSP it counts.
The architect of the systems beneath them: workflow design, scripting, alert-rule tuning, triage logic. Every hour here multiplies across future ticket volume. The work isn’t new. What’s new is that an AIMSP recognizes, measures and values it.
decision digitalAIMSP Framework & Methodology
decision digitalAIMSP Framework & MethodologyEvery MSP knows the 75% benchmark: bill 75% of available hours on client-based work. A 40-hour week means 30 hours on the board. Miss it consistently and the business model strains.
The problem isn’t the target. The problem is what gets counted. Traditional utilization only counts hours that generated a client invoice. The workflow your engineer tuned Tuesday morning: not counted. The NOC escalation they managed that afternoon: not counted. The alert rule they rebuilt Friday to keep 200 tickets out of next month’s queue: not counted. Invisible to the metric, and invisible to the business.
AIMSP replaces billable utilization with Deployed Time. It asks a different question: not “what percentage of available hours generated a client bill?” but “what percentage of available hours was deployed toward value-generating activity?” Three things count:
Traditional billable work. An engineer resolved a client issue, time was logged, and an invoice or managed service contract was fulfilled. Still the foundation, just not the whole story.
Supervising the agents and systems handling routine work, managing escalations, being the judgment layer above the automation. Your engineer didn’t resolve the ticket, but they were accountable for the system that did.
Workflow design, script development, tooling configuration. It counts, not as overhead, but as capacity creation.
HTE shows what an engineer’s automation delivered while they were doing something else. It’s reported next to Deployed Time as a leverage ratio, not added into it. An engineer’s hours are their hours; what their automation produces on top of those hours is the multiplier.
decision digitalAIMSP Framework & MethodologyThe 75% Deployed Time target looks familiar from the outside but means something fundamentally different on the inside. It tells every engineer: your oversight counts. Your builds count. And what your automation delivers shows up right beside it as leverage. You’re measured on your full contribution, not just the hours that hit a client invoice.
As the operation matures, the composition of that 75% changes. Early on, almost all of it is direct client-facing resolution. Over time a growing share comes from oversight and builds, while leverage climbs alongside it. The target stays constant. The mix evolves.
Before any metric can be calculated, every closed ticket has to land in exactly one of six buckets. The bucket decides which metric applies, and who or what gets credit for the work.
Some tickets were resolved entirely by automation. Some by your NOC. Some by a vendor platform fixing its own problem. Some by an engineer who glanced at it and closed it with no time logged. Some by an engineer who worked it start to finish. Each situation is different, so each gets measured differently. One bucket per ticket. No overlap. No gaps.
decision digitalAIMSP Framework & MethodologyAn agent or workflow did the work start to finish. A human may still have clicked it closed as a final check.
Your automation doing exactly what you built it to do.
Automation did the setup (profiling, routing, scheduling). Your engineer finished the resolution.
Automation didn’t close it, but it made your engineer faster.
Your NOC or SOC handled it under a flat-rate agreement. Real humans did the work, just not your engineers.
MOS converts that work into the internal labor cost it replaced.
A vendor platform you pay for per device or per user detected the issue, fixed it and closed its own ticket.
A paid platform doing work your engineers used to do. A managed offload, same as your NOC.
An engineer looked at it, decided it was a non-issue and closed it with zero time logged. No automation marker fired first.
Not automation, but your single biggest automation opportunity.
Your engineer owned it from open to close with time logged. No automation or partner involvement.
The comparison set every other bucket is measured against.
decision digitalAIMSP Framework & MethodologyEvery metric in AIMSP does one job: put a dollar value on the work your current reports don’t count. The math isn’t complicated once you see how the pieces connect.
The foundation. Your own history, the median time your engineers actually took, sets the cost of every ticket type in engineer time.
Automation did the work. Engineers didn’t have to. Here’s what it would have cost in human time.
Your NOC, SOC or a paid platform solved it. If your engineers had, this is what it would have cost.
Intelligent triage handled it early. Dispatcher time saved, value captured.
All of the value, together, in one report that shows where you stand and where the biggest gaps are.
Every service board in your ConnectWise instance maps to a metric type based on what work actually happens on it. Alerts boards get measured differently than Tier-2 boards. NOC boards get measured differently than consulting boards. The SHRT Buildout (Part III) is where your specific boards get mapped; your ARI report shows how the stack maps to your exact environment.
decision digitalAIMSP Framework & MethodologyHere’s the whole framework applied to a single ticket, start to finish. The rates are illustrative; your report uses your own.
SaaS Alerts flags a risky Microsoft 365 sign-in. A ticket lands on the Alerts board as Alerts / Cybersecurity / SaaS & M365.
CrushBank profiles and classifies the ticket before a dispatcher sees it. That’s one triage event.
An Asio workflow revokes the session, confirms the account is clean and closes the ticket. No engineer time logged.
A validated automation marker fired before close, so it’s Bucket 1, Agentic Automation, and it counts toward coverage.
Your engineers’ median for that ticket type is 0.95 hours, built from their own human-resolved history.
0.95 hours at your engineer rate is the engineer time the automation gave back.
One ticket, $101.30 in labor offset. ARI does this for every closed ticket in your PSA, then adds it up.
$101.30You now have the full picture. The operating model explains how an AIMSP runs. The six buckets classify every ticket. The metric stack puts a dollar value on every classification. And ARI brings it all together into a single diagnostic report, built entirely from your own PSA data. Parts II through IV follow that same arc, and so does every CATAPULT engagement.
Detection logic, field names and edge cases. The full technical reference.
This part is the implementer’s reference. If you’re evaluating AIMSP rather than building it, skip ahead to Part III.
decision digitalAIMSP Framework & Methodologyclosed_by: Workflow, CWPSA, CWPSA-Asio, CWRMM, ConnectWise RMM, or nullclosed_by doesn’t automatically rule out Bucket 1. If a validated automation marker fired before the ticket closed, credit follows the marker: the ticket is Bucket 1 even though a human clicked it shut as a final check. Only when there’s no qualifying marker does a human-closed, zero-time ticket become a Human Dismissal (Bucket 5).decision digitalAIMSP Framework & Methodologydecision digitalAIMSP Framework & Methodologyclosed_byThe math behind the metrics, in plain English. By the end of Part III, every dollar figure has a clear source.
decision digitalAIMSP Framework & MethodologyTraditional MSP metrics count hours, but only the hours your engineers logged.
When automation closes thousands of tickets, when your NOC resolves hundreds more, when intelligent triage routes work before anyone sees it, none of that shows up in your utilization report. It happened. It had value. But the report says zero.
HTE, MOS and TDS solve this by expressing automation and partner output in the same unit as human output: hours of labor. Once everything is in the same unit, you can put a dollar value on it.
SHRT values come from the Type and Subtype fields on your Tier-1 human-resolved tickets. For each Type/Subtype combination we take the median resolution time, not the average, so a handful of outlier tickets can’t inflate the baseline.
50 or more tickets with consistent Type/Subtype. The combination gets its own SHRT baseline, straight from its own median.
Estimated from related ticket types rather than measured directly, because the combination doesn’t have enough history of its own.
Every row in your SHRT table shows its confidence level, so you always know how much weight a number can carry.
Consistently populating the Subtype field on every ticket. More Subtypes with 50+ tickets means more High-confidence rows and sharper dollar figures. It’s a recommended first step in every CATAPULT engagement.
decision digitalAIMSP Framework & MethodologyBuilt during the SHRT Buildout, the first step of every CATAPULT engagement. Each row is a ticket type your engineers have historically resolved. Every HTE, MOS and TDS dollar figure in your ARI report traces back to a row in this table. The rows below are an example of what one looks like.
| Automation action | Board / Type / Subtype | SHRT | Tickets | Conf. |
|---|---|---|---|---|
| HTE · Human Time Equivalent | ||||
| Alert Triage & Auto-Close | Alerts / Cybersecurity / SaaS & M365 | 0.95 h | 13,251 | High |
| Alert Triage & Auto-Close | Alerts / Cybersecurity / General | 0.95 h | 987 | High |
| CW RMM Alert Auto-Close | Alerts / Cybersecurity / CW RMM | 0.95 h | 621 | High |
| Firewall Alert Response | Alerts / Network / WatchGuard | 1.26 h | 374 | High |
| Lenovo Alert Processing | Alerts / Cybersecurity / LenGuard | 0.95 h | 270 | High |
| Backup Alert Response | Alerts / Backup / Backup Radar | 0.67 h | 34 | High |
| EDR Alert (Huntress / SentinelOne) | Alerts / Cybersecurity / EDR | 0.95 h | 36 | High |
| MOS · Managed Offload Savings | ||||
| NOC General Remediation | NOC / General | 0.97 h | 8,416 | High |
| Patch Deployment | NOC / Patching | 0.75 h | 2,538 | High |
| Hyper-V Remediation | NOC / Hyper-V | 0.97 h | 1,081 | High |
| Network Management | NOC / Network Mgmt | 0.98 h | 349 | High |
| AD / DHCP / Server / Desktop | NOC / Various | 0.97 h | 526 | High |
| TDS · Triage Dispatch Savings | ||||
| Ticket Profiling / Classification | All boards, triage pass only | 0.17 h | ~28,000 | Medium |
SHRT The median time your engineers have taken to resolve that ticket type.
Tickets Human-resolved tickets used to calculate the SHRT.
Conf. High is 50+ tickets with consistent Type/Subtype. Medium is estimated from related types.
Group The metric each row powers in your ARI calculations.
decision digitalAIMSP Framework & MethodologyThe rates and per-event times in the examples below are illustrative. Your engineer and dispatcher rates are confirmed with you before the report runs, and every SHRT value comes from your own ConnectWise data.
Example: 1,000 tickets × 0.95 h × $95/h = $90,250 in recovered engineer capacity.
Bucket 2 tickets aren’t included here. Their value is measured directly in The Assist (section 05, next page).
SHRTT is what the same work would have cost internally, not how long the NOC or platform took. That’s the avoided labor cost. Bucket 4 ticket types with no human SHRT row earn no MOS.
Example: 5,000 triage events × 0.17 h × $65/h = $55,250 in dispatcher time saved.
The share of every closed ticket resolved without an internal engineer: your automation, your NOC and SOC, and your paid platforms. Bucket 5 is deliberately left out of the top line. Counting a person’s judgment call as automation is the fastest way to publish a number you can’t defend, and raw zero-hour counts overstate coverage by exactly the size of that bucket. It shows up instead as your automation opportunity list.
decision digitalAIMSP Framework & MethodologyFor each ticket type, The Assist compares the median logged hours on Bucket 2 tickets (automation helped, engineer finished) with Bucket 6 tickets of the same type (engineer alone). The difference is the time automation gave back on every assisted ticket.
Think of it like GPS. You still drove, but you got there faster. The Assist measures how much faster.
It’s the one number in the report that’s measured, not modeled, which is why it’s reported on its own as the credibility anchor rather than folded into the total.
Median logged time on a password reset worked start to finish by an engineer.
Median on the same ticket type when CrushBank profiled it first and the engineer finished it.
12 minutes back on each of 2,000 assisted tickets. Illustrative figures.
Total labor cost avoided, in hours and dollars, with every term shown in the report. Each figure traces back to a row in your SHRT table.
Know where you stand. Know what it’s worth. Know what comes next.
An MSP with 40%+ automation and partner coverage, with millions of dollars in labor offset over five years, can’t tell that story with a utilization percentage. The 75% rule was designed for a world where humans did everything. ARI is built for the world that replaced it. Every number comes from the client’s own PSA data. Their operation, measured correctly, for the first time.
decision digitalAIMSP Framework & MethodologyA single, self-contained HTML report covering the eleven sections below. The full report is built for operations and service delivery leadership. A separate Executive Brief covers the same findings at a C-level summary.
decision digitalCATAPULT · AdvisoryA fixed-scope CATAPULT engagement that runs ARI against your own ConnectWise data and hands you the report, the gaps and the roadmap. Four stages, delivered within three to six weeks.
Kickoff, a read-only API member and SMARTvault loading your ConnectWise history. SMARTvault is included in the engagement, and it’s yours to keep afterward.
Boards, members and system accounts mapped. Then a checkpoint: you confirm each account before anything is counted, because account names don’t always tell the truth.
Six buckets, the proof behind them, your SHRT table and the dollar valuation.
The full ARI report for operations leadership, the Executive Brief for ownership, and a prioritized roadmap, walked through together.
After the assessment, ARI findings drive the AIMSP Strategic Plan, delivered as its own engagement. ARI Pulse re-runs the measurement quarterly against your anchored baseline.