Picture the Monday service meeting. The dashboard says utilization was 71% last week, first contact resolution went up, and the backlog is flat. Then the dispatcher mentions that the phones were brutal on Thursday, two techs spent the afternoon on a client's email outage, and half that work is still sitting in someone's head instead of in the PSA. Which week actually happened?<\/p>\n
Both did. The dashboard is reporting on the records your team created, and the KPIs are only as true as those records. That is the problem with most lists of MSP KPIs: they give you twenty or thirty metrics, a formula for each, and nothing about where the numbers come from or how they go wrong.<\/p>\n
This post takes a narrower position. A service manager needs a short set of KPIs reviewed every week, each paired with a check on the data underneath it. The financial KPIs (EBITDA, agreement margin, revenue per user) still matter, but they belong in a monthly review, and they inherit every error in the weekly data.<\/p>\n
MSP KPIs (key performance indicators) are the handful of measurements an MSP uses to judge whether its service desk, its agreements and the business as a whole are healthy. Most of them are calculated from records in the PSA (ConnectWise PSA, Autotask, HaloPSA or Syncro): tickets, time entries, statuses, agreements and invoices. A few come from somewhere else, like client surveys or the phone system.<\/p>\n
The usual lists group them into three families:<\/p>\n
ConnectWise's own list<\/a> covers 20 of them across these families. That is a fine reference. It is not a scorecard anyone can act on every week.<\/p>\n A KPI earns a spot on the weekly scorecard if two things are true: it can change in a week, and someone can do something about it next week. Backlog, response time and missing time entries pass that test. EBITDA doesn't. You can't fix a quarter's margin on Tuesday, and staring at it weekly mostly produces anxiety.<\/p>\n NinjaOne's guide to service delivery KPIs<\/a> makes a useful distinction here: treat the PSA as a data source, not a performance framework, and review KPIs on a fixed cadence with stable definitions. It suggests monthly or quarterly reviews. For the business-level numbers, that's right. For the service desk, a month is too long to find out that tickets from one client have been aging since the first week.<\/p>\n So split it:<\/p>\n Here are seven KPIs worth reviewing every week, what each one measures, and how each one misleads you when the underlying data is off.<\/p>\n What it is:<\/strong> the number of tickets opened and closed in the week, and the open backlog at the end of it.<\/p>\n Why weekly:<\/strong> a backlog that grows three weeks in a row is a staffing or process problem you can still fix before clients feel it.<\/p>\n How it lies:<\/strong> RMM alert tickets. If your RMM opens a ticket for every disk space warning and an automation closes half of them, your "closed" count is padded by tickets no human touched. Report human-worked tickets separately from alert tickets, usually by board, queue or source. If you're still deciding which alerts deserve a ticket at all, see should RMM alerts create tickets<\/a>.<\/p>\n What it is:<\/strong> the time from a ticket's creation to the first human response to the client, ideally measured against your SLA by priority.<\/p>\n How it lies:<\/strong> an automated acknowledgment email counts as a response in some setups, which makes the number look great and means nothing. And phone tickets often show a near-zero response time because the tech created the ticket while talking to the client. That's real, but it drags the average down and hides slow email and portal responses. Break first response time out by source (ConnectWise and Autotask both have a ticket source field), or you'll be averaging two different queues into one meaningless number.<\/p>\n What it is:<\/strong> the share of issues resolved on the first contact. ConnectWise defines it as issues resolved on first contact divided by total issues received.<\/p>\n How it lies:<\/strong> this is the KPI most distorted by the phone. The issues most likely to be resolved on first contact (a password reset, a printer remap, "how do I share this calendar") are also the ones most likely to be handled on a call with no ticket ever created. Every one of those that goes unrecorded is a first contact resolution you didn't count. The better your techs are at quick phone fixes, the worse your FCR can look. If FCR seems low, check how many calls last week have no matching ticket before you blame the techs.<\/p>\n What it is:<\/strong> the number of open tickets older than a threshold you pick, say five business days, grouped by client and by technician.<\/p>\n Why it beats average resolution time:<\/strong> an average hides the tail. Ten tickets closed in an hour and one that's been open for a month average out to something that looks fine. The aging list shows you the month-old ticket by name.<\/p>\n How it lies:<\/strong> tickets parked in a "waiting on client" status. Decide whether those count. If they don't, also track how long tickets sit in that status, because "waiting on client" is where tickets go to be forgotten.<\/p>\n What it is:<\/strong> the share of closed tickets that get reopened, or that get a new ticket from the same contact about the same issue within a set window.<\/p>\n Why it matters:<\/strong> it is the honest counterweight to resolution time. A team pushed to close fast will close early, and the reopen rate is where that shows up.<\/p>\n How it lies:<\/strong> duplicate tickets. If a user emails and then calls about the same problem, you may have two tickets, one closed as a duplicate, and neither counts as a reopen. Most PSAs can report reopens from status history, though it often takes a custom report rather than a stock dashboard.<\/p>\n What it is:<\/strong> two numbers. The share of closed tickets that have at least one time entry, and the average lag between when work happened and when its time entry was created.<\/p>\n Why it's on the list:<\/strong> most KPI lists don't include it, and it's the one that decides whether the rest of your scorecard is true. Utilization, effective rate and agreement margin are all calculated from time entries. A ticket closed with no time is either free work or missing data, and you can't tell which from the report.<\/p>\n The lag matters as much as the gaps. A time entry written at 4:45 for work done at 9:15 is an estimate, not a record. ConnectWise and Autotask both store when an entry was created as well as the time it covers, so you can measure the lag directly. We covered where this time goes missing, and why it's usually at the phone, in MSP time tracking: the leak is at the phone<\/a>.<\/p>\n What it is:<\/strong> the number of support calls in the week that never got linked to a ticket.<\/p>\n Why it's on the list:<\/strong> the phone is the one intake channel the PSA can't see on its own. Email and portal requests usually become tickets on their own through the PSA's email connector or portal; calls become tickets only when someone makes them. A call that never became a ticket is invisible to every other KPI on this list. It isn't in the backlog, it isn't in FCR, and its time isn't in utilization. You can get a rough count by comparing your phone system's call log for support lines against tickets with a phone source. It's tedious to do by hand, which is why most MSPs never do it.<\/p>\n Once the weekly data is clean, the monthly numbers become worth reading.<\/p>\n Technician utilization.<\/strong> A common definition is hours worked on client tickets divided by hours available, and the choice of denominator changes the number a lot. Hours paid, hours scheduled and hours available after meetings and PTO give three different results. Pick one, write it down, and don't change it mid-year. Then remember that utilization only counts logged time. A tech who handled twelve quick calls with no tickets looks underused.<\/p>\n Effective hourly rate per client.<\/strong> Agreement revenue divided by hours logged to that client. This is the KPI that tells you which flat-fee clients are actually profitable, and it's the one most inflated by missing time. Fewer logged hours make every agreement look better. We walked through how that happens in MSP profit margins: why your busiest clients look the most profitable<\/a>.<\/p>\n Agreement margin.<\/strong> Revenue minus labor cost (hours times each tech's loaded cost) minus the cost of anything bundled into the agreement. Same dependency on time entries. If the effective rate on a client looks wrong for your pricing unit, the problem may be the agreement rather than the delivery; see MSP pricing models<\/a>.<\/p>\n Tickets per endpoint or per user, by client.<\/strong> Useful for spotting a client whose environment is generating more work than the agreement assumes. It is only honest if ticket counts include phone work and exclude alert noise, which is what the weekly scorecard checks.<\/p>\n The review works best as the same agenda every week, so the numbers become a habit and the discussion goes to the exceptions.<\/p>\n Keep the definitions stable. If you change how a KPI is calculated, note the date, because a jump in the chart that came from a definition change will otherwise get mistaken for a real improvement.<\/p>\n AI doesn't make a bad KPI good. It can fix the input problem that makes good KPIs unreliable, because the weak spots in this scorecard are records that depend on someone remembering to create them.<\/p>\n That's the part Vight works on. It pulls recorded support calls from the phone system, matches each to the right client and ticket, and posts a summary note and a time entry to ConnectWise PSA, Autotask, HaloPSA or Syncro. A quick phone fix becomes a ticket with time on it, which is exactly what first contact resolution, utilization and effective rate need. The Vight Dashboard shows how calls were matched to tickets, including the ones left unmatched, which is the "calls with no ticket" number from the scorecard above. For ConnectWise, the Time tab lays out a day of each technician's time entries next to their calls, and flags overlapping entries and, for techs running the Vight Work Notes Agent (in beta), ticket work with no time logged. Ticket triage<\/a> handles the intake side, matching new ConnectWise and HaloPSA tickets to the scenarios you configure and asking requesters for the details they left out.<\/p>\n What AI shouldn't own is the judgment. Deciding what counts as billable, which threshold makes a ticket "aging," or whether a client's ticket volume justifies a pricing conversation stays with the service manager and the owner.<\/p>\n For the service desk: backlog trend, first response time, first contact resolution, ticket aging, reopen rate and time entry completeness, reviewed weekly. For the business: utilization, effective hourly rate per client and agreement margin, reviewed monthly. Time entry completeness matters most because utilization, effective rate and margin are all calculated from time entries.<\/p>\n Review service desk KPIs weekly, because they change week to week and can be acted on right away. Review financial KPIs like margin and effective rate monthly, and client-level trends like churn quarterly. Whatever the cadence, keep the definitions fixed so trends compare like with like.<\/p>\n Divide the hours a technician logged to client work by the hours they were available in the period, and multiply by 100. The denominator matters: hours paid, hours scheduled and hours available after PTO and internal meetings give different results, so choose one and use it consistently. Utilization counts only logged time, so unlogged phone work makes technicians look less utilized than they are.<\/p>\n Usually because the records underneath them are incomplete or noisy. Calls handled with no ticket never reach the PSA, time entered hours later is an estimate, RMM alert tickets pad ticket counts, and automated acknowledgments can count as first responses. Check time entry completeness and calls with no ticket before trusting the rest.<\/p>\n There isn't a reliable published benchmark specific to MSPs, and the number depends heavily on how you define a contact and whether phone fixes become tickets. Track your own FCR by intake source over time instead of chasing an industry figure, and check how many calls have no ticket before reading too much into a low number.<\/p>\n Before you add another chart to the dashboard, run one week of the two data checks: what share of closed tickets have time on them, and how many support calls never became a ticket. If both numbers are good, your KPIs are worth trusting. If they aren't, that's the first thing to fix, and the rest of the scorecard will get more honest on its own.<\/p>\nWhy fewer KPIs, reviewed weekly, beat a long list<\/h2>\n
\n
The weekly service desk scorecard<\/h2>\n
1. Tickets opened vs. closed (backlog trend)<\/h3>\n
2. First response time<\/h3>\n
3. First contact resolution<\/h3>\n
4. Ticket aging (tickets open past a threshold)<\/h3>\n
5. Reopen rate<\/h3>\n
6. Time entry completeness<\/h3>\n
7. Calls with no ticket<\/h3>\n
The monthly KPIs, and why they depend on the weekly ones<\/h2>\n
How to run the weekly review in 30 minutes<\/h2>\n
\n
Where AI helps with MSP KPIs (and where it doesn't)<\/h2>\n
Common questions about MSP KPIs<\/h2>\n
What are the most important KPIs for an MSP?<\/h3>\n
How often should an MSP review its KPIs?<\/h3>\n
How do you calculate technician utilization for an MSP?<\/h3>\n
Why do MSP KPIs from the PSA look wrong?<\/h3>\n
What is a good first contact resolution rate for an MSP?<\/h3>\n
Start with the data you don't have<\/h2>\n