Counting repeats honestly

Count tickets whose root cause matches an earlier ticket for the same client in the same period. Matching by category is too loose; matching by exact device and symptom is too tight. Most PSAs let you tag a problem record; count tickets linked to a problem. If you cannot, count manually for the top ten categories and say the count is partial.

Why clients respond to it

Ticket volume sounds like your workload. Recurring incidents sound like their money. Nineteen tickets from one VPN appliance is a sentence a finance director can price: nineteen interruptions, each with a person waiting. The appliance costs less than the quarter of interruptions did.

This is also the metric that shows the MSP is looking for causes rather than closing tickets. Present it every quarter, even when it is low, because a low number is proof of the work.

From count to project

One finding, one cause, one fix, one price, one date. Do not present the whole top ten; present the one you want approved and put the rest in the source appendix. Ask for the decision. Record it, including a no.

  • Name the top recurring cause and the tickets it produced.
  • Propose the fix with cost and a completion date.
  • Agree how recurrence will be measured after the fix.

Keeping the claim checkable

The persuasive version of this number is the one the client can verify: the count in the source row, the cause in the finding, the decision beneath it, and last quarter's count beside this quarter's so the trend is not your word alone. A one-page brief built from two periods of the same eight metrics keeps that chain visible without a chart. Sourcerow produces the page from the ten-field template; the problem records, and the root-cause work that makes the count honest, are still yours to keep.

A worked example

A professional-services client with sixty seats raised 112 tickets last quarter and 134 this quarter. Nineteen of the 134 were the same complaint: the site-to-site VPN dropping between the two offices, each time a ticket, each time a reconnect, each time twenty minutes of somebody waiting. Last quarter it was eleven.

The finding is that recurring incidents rose from eleven to nineteen and every one of them is the VPN appliance. The decision requested is to replace the appliance at a quoted price with a date three weeks out. The page also notes what the count will be measured against afterwards: zero VPN tickets in the following period is the success condition, written down before the work starts. That is the whole argument, and it fits in four lines.