Vendor Selection Criteria: Test Margin and Support

Why Every Vendor Pitch Feels Like a Trap

Picture a vendor site that promises a seamless partnership and a generous partner program. You check the distributor catalog and find the product you would resell carries zero margin. You would handle billing, support, and the occasional angry client call, and you would make nothing for it. One owner who found themselves in that spot gave the end user a direct purchase link instead of reselling. No profit in doing the work for free.

The trap is not that vendors lie. It is that a good pitch tells you nothing about what the relationship costs you in a bad week. So the question becomes: how do you pick a partner without getting burned? My view is you choose on margin and support behavior, not on promises. And both are testable before you commit.

The Two Numbers That Decide Any Vendor

The first number is margin. Not the list price, not the partner discount. What you actually keep after billing, support, and the occasional headache. The second is support quality. How fast does a real problem get resolved, and does the vendor treat your production issue like an emergency or like a ticket to close?

In one reported case, an MSP contacted a networking vendor about a controller migration issue. The support team gave useless advice, told them to re-adopt all devices, was slow, and never resolved the problem. The MSP rolled back on their own. In another, an MSP kept a support ticket open with the same vendor for almost 500 days. The vendor only asked for logs and advised updating the controller. That is not support. That is a holding pattern.

Those are specific reported cases, not a verdict on the vendor. But they show what you are actually buying when you resell a product: you are buying the vendor's support behavior, and if that behavior is broken, you own the fallout.

Test Support With a Real Issue Before You Commit

One owner reported stopping sales calls and only approaching vendors when they had a problem to solve. That owner described reviewing potential new solutions for months, for free, or not reviewing them at all. That is an account of their approach, not a universal best practice.

The trial period is where you test support with a real issue. Not a hypothetical. Not a question about a feature. A genuine production-adjacent problem that you would normally open a ticket for. You want to see how the vendor handles it. Do they respond within a day? Do they escalate? Do they resolve it, or do they keep asking for logs and telling you to update the firmware?

Use your own test cases to decide whether a trial has covered the support problems you need to see, rather than assuming a fixed duration will expose every failure.

The cost of this approach is time. One operator reported rolling outages after deploying a vendor's switches and access points at client sites, damage to a client's CNC tooling and thousands in damages. That operator said they never used the vendor again.

Pick a Deal Structure That Puts Margin in Your Pocket

One MSP reported using three deal structures, choosing according to what the client would accept and what they could deliver:

1. Option 1: bundle everything. The client pays one price for hardware, software, support, and services.
2. Option 2: software plus services. You sell the software and charge separately for implementation and support. A good fallback when a client pushes back on bundling.
3. Option 3: software direct. The client buys the license directly from the vendor, and you do not touch the billing.

This MSP transitioned from option 2 to option 1, kept option 2 as a fallback to close deals, and always offered option 3 for retail SaaS. They report that offering all three let them win deals even when clients resisted bundling, while still making margin on the retail SaaS items they did not have to support.

My view is that you don't have to commit to one model. The structure is a tool, and you can carry all three in your pocket. But the margin only survives if you account for the real cost of per-user licensing on shared endpoints, which the scoping section below covers.

Set up a Referral Agreement That Both Sides Use

Picture a referral deal agreed with a handshake and a vague promise, followed by silence. The fix is a simple agreement that names the terms. My view is that a referral agreement only works when both sides see profit and follow up on leads. If one side makes nothing, or neither side tracks who sent whom, the agreement dies quietly.

A lightweight memorandum of understanding is enough. Spell out the commission percentage or flat fee, what counts as a qualified lead, and a cadence for checking in. A monthly ten-minute call to review the pipeline beats a contract nobody reads. And keep the tracking simple: a spreadsheet column for source and status beats a CRM nobody opens.

Scope the Deal so No One Guesses Who Owns What

In a co-managed IT deal, ambiguity is the failure. Who handles a password reset at 3am? Who owns the M365 licensing for a workstation that three people share? Who is responsible for patching the firewall? If the answer is "we will figure it out," you will figure it out at 3am, on a call, with a client who is already angry.

The fix is a shared scope document. It lists each party's responsibilities for support, security, and licensing, names who owns what in writing, and both sides sign it. One MSP reported billing by endpoints with a one-user-per-endpoint expectation, adding per-user charges for shared endpoints and itemizing M365 separately while bundling security and support with quarterly on-site hours. That MSP reported clearer invoicing and avoiding losses on shared endpoints for products licensed per user.

The scope needs to be revisited as endpoints and users change. A client adds five shared workstations and suddenly your 1:1 ratio is off. You are paying for licenses out of your own margin. The document is not a one-time artifact. It is a living agreement that you update when the environment changes.

When to Walk Away From a Deal or a Partner

There are times when I'd walk away, even if it means losing the RFP or the revenue. Compare the potential revenue and margin with the support burden, transition work and any documented client complaints. A loss of trust or staff frustration is a risk to assess, not an inevitable cost of staying.

If an RFP demands terms you can't deliver profitably, record that conflict before you bid. Ask whether the scope or price can change. If neither can, I'd decline rather than assume a better pitch will fix the economics. One operator reported advising an MSP client to decline an RFP with demands they regarded as impossible; the client followed that advice.

The same applies to vendor partners. If the margin is zero, the support is chronically bad, or the trial period surfaces a pattern of unresolved tickets, walk away.

On Monday, list your top three vendor relationships. Check their actual margins, not the partner program brochure. Test their support with one real issue. If they fail, you have your answer.

And if you are in a co-managed deal without a scope document, write one this week.