
Test the promise support included against the work your technicians still perform. Vendor performance management should count the effort needed to reproduce a fault and keep the client working, then take that evidence into the renewal decision. The vendor invoice only shows what you paid the supplier. It doesn't show the labor your MSP supplied around it.
A low subscription price can resemble a cheap appliance that needs someone standing beside it. The purchase is cheap; the attention still costs something. I'd record that attention in the work system before deciding whether the vendor is the problem or the team needs a different way to use the product.
Separate Active Work From Waiting
Count the time the technician actually spends on the case. A vendor case open across a weekend isn't continuous engineering labor. Keep the elapsed delay beside active effort because it helps explain the client impact, but don't price them as the same thing.
Record what the technician did and why it was needed. Distinguish a vendor-requested diagnostic from a client configuration correction. The first step is a usable account of the work, rather than a new label that assigns every difficult ticket to the supplier.
Use the vendor's support commitment as the comparison. Check what it actually promises about response and escalation. An initial reply and a resolved fault are different events, so don't substitute one for the other in the review.
Keep the evidence close to the time entry. The reviewer should be able to find the vendor case and understand what made another attempt necessary. A frustrated comment without that record won't settle whether the work was avoidable.
Use a Record the Technical Lead Can Check
I'd add the fields below to the relevant ticket or linked vendor-case record. Use the same method across the cases you intend to compare. The technical lead checks the cause before finance turns the time into a cost.
| Record Field | What to Capture | Who Checks It |
|---|---|---|
| Vendor and Case | The supplier case reference linked to the internal work. | The technician handling the case |
| Affected Work | The client service and product version relevant to the fault. | The technical lead |
| Active Effort | The actual investigation and workaround time, with the action recorded. | The technician handling the case |
| Reason for Repetition | What required another attempt and the supporting case history. | The technical lead |
| Cause Classification | Whether the evidence points to vendor behavior, internal practice, client configuration, or an unresolved cause. | The technical lead |
| Client Impact | What the user could not do and the temporary service arrangement. | The service lead |
| Next Decision | The unresolved question and who can settle it. | The vendor relationship owner |
Keep unknown causes marked unknown. A supplier may need information your team hasn't provided, or a workaround may be compensating for an internal configuration choice. Establish that before using the total as evidence against the vendor.
Review repeated requests for the same diagnostic with the case history available. Check whether the information was supplied in the requested form and whether the vendor explained why it needed another attempt. That gives the relationship owner a specific escalation rather than a complaint about support being poor.
Cost the Effort With the Utilization Included
Use the model's US Tier 2 salary of $62,000 as a planning input. Its 1.25 burden multiplier produces $62,000 x 1.25 = $77,500 in annual employment cost. The burden covers payroll taxes and benefits-related costs; it isn't the whole cost of running the service.
For a service-desk comparison, use the model inputs of 1,660 available hours and 70% service-staff utilization. Calculate the annual productive-hours denominator as 1,660 × 70%. For this planning example, divide the annual burdened employment cost by that result: ($62,000 × 1.25) ÷ (1,660 × 70%) gives the cost per productive hour.
Multiply the verified active hours in your selected cases by that rate to estimate the labor allocation. Keep the actual hours visible so another person can reproduce the calculation. Use the staff and utilization basis that fits your real work when replacing the model assumptions.
The available-hours figure already accounts for time away in the model. Don't add another paid-time-off allowance to the same calculation. Likewise, don't add the same employment burden again after costing the hours.
This values capacity used by the work. It doesn't establish that removing a workaround will reduce payroll by the same amount. Record any actual reduction in an expense separately from time the existing team can spend on other work.
Find the Failure Behind the Cost
Picture a monitoring integration that repeatedly needs a technician to restart a failed connection. The assigned technician finds the fault and performs the workaround. If that effort stays in general support notes, the person deciding renewal may see the subscription invoice without seeing the repeated work.
Your Tier 2 technician isn't a warranty extension. Give the technical lead the recurrence record and ask what would remove the workaround. The answer may need a vendor correction or a change to your own process.
Lisa Shorr describes trying a vendor in an office demo and asking the service team about deployment and support. That's her practitioner selection approach. I'd include the people who dealt with the problem in the renewal review, with the case evidence available.
Justin Esgar describes weighing access to support against his team's own product expertise, including an exception for a product the team knows well. Keep that as his operating preference. The same labor total can need a different decision when the team can resolve the work predictably and understands the tradeoff.
Compare the Renewal With the Cost of Changing
Put verified support effort beside the vendor's actual charges for the chosen period. Keep one-time investigation separate from work that is still recurring. Otherwise an old exceptional incident can be mistaken for an ongoing cost, or a persistent problem can disappear inside an average.
Ask the supplier for a specific response to the evidenced issue. Record who will address it and what result your team will check. A general assurance that support is improving isn't a resolution of the fault in your cases.
Compare a replacement on the same basis. Cost the migration and training work as well as the new subscription. Test the relevant support route before assuming that a different supplier removes the effort.
It depends on the verified cause and on the work needed to correct or replace the current arrangement. The subscription difference alone can't settle that choice. Keep the expected change in recurring effort separate from the cost of making the transition.
Take a Reproducible Calculation Into the Review
Have the technical lead approve the case classification and finance check the cost basis. Give the vendor relationship owner the resulting calculation before the actual notice deadline. The contract record tells them when to act; the work record tells them what to discuss.
If the vendor supplies a correction, check the same affected work after it is applied. Look for recurrence and active effort on a comparable basis. A lower ticket count by itself doesn't establish that the correction caused the change.
Start with a case your team can identify as repeated workaround work. Reconstruct its active effort and ask the technical lead to verify the cause. Then use the next vendor decision to discuss that recorded work, rather than relying on who tells the most convincing support story.
mspoutpost.com/articles/vendor-performance-management-count-the-support-work
Written by Dana Kowalski
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.
