What Your PSA Already Knows About Your Next Sale

Every MSP owner has been told to "sell more to existing clients." Almost nobody is told where to look. So the account manager opens the PSA, sees a list of companies and agreements, and closes it again — because a list of companies is not a list of opportunities.

Here is the thing that gets missed: the gap between what a client is contracted for and what they are actually running is already recorded in your systems. Your PSA knows what you agreed to deliver. Your RMM knows what is really deployed on their endpoints. Your Microsoft 365 tenant knows what they bought and who is using it. Nobody reconciles those three, because reconciling them by hand across 40 clients is a week of work that never rises to the top of anyone's list.

That reconciliation is where the revenue is. Not in a list of services you could pitch — in the specific, provable differences between what a client pays for and what they have.

The Three Systems and What Each One Knows

Your PSA knows the promise. Agreements, agreement additions, seat counts, contract end dates, and what each line item is supposed to cover. It is the record of what the client agreed to buy and what you agreed to deliver.

Your RMM knows the reality. Which endpoints exist, what operating system each runs, whether an EDR agent is installed and reporting, patch levels, disk and memory pressure, hardware age, and warranty status. It is ground truth about the estate.

Your Microsoft 365 tenant knows the consumption. How many licenses were purchased per SKU versus how many are actually assigned to a human being. Which users have registered for multi-factor authentication and which have not.

Individually, each of these is an operational tool. Together they are a sales report, because the interesting information is not in any one of them — it is in the disagreement between them.

What the Disagreements Look Like

Contracted but not deployed. The agreement says endpoint detection and response for 62 seats. The RMM reports an EDR agent on 47 machines. Fifteen endpoints are billed as protected and are not protected. That is not an upsell — that is a service problem you want to find before your client does, and it is the single most valuable thing this reconciliation produces.

Deployed but not billed. The reverse case, and far more common than MSPs expect. The client grew from 38 seats to 51 over eighteen months. Onboarding happened through the helpdesk. The agreement still says 38. You have been delivering thirteen seats of service for free, quarter after quarter, and the longer it runs the more awkward the conversation becomes.

Bought but not used. The client is paying Microsoft for 60 Business Premium licenses. Forty-one are assigned. Nineteen licenses — real money, every month — are being paid for by your client and consumed by nobody. Finding that makes you the advisor who saved them money, which is a very good position from which to propose the thing you actually want to sell.

Nothing in place at all. No backup line item anywhere in the agreement, and no backup vendor reporting into your stack. No email security. No MFA enforcement. These are the classic gaps, and they are only credible when you can say precisely which client and which seats.

Running out of road. Machines past end-of-life on their operating system. Hardware beyond warranty. Software versions no longer receiving security updates. All dated, all countable, all a hardware refresh or migration project that has to happen anyway.

Why Nobody Does This By Hand

Because the arithmetic is brutal. Reconciling three systems for one client is perhaps forty minutes if you know exactly what you are looking for. Across forty clients that is a full working week, and it is stale the moment you finish, because seats changed while you were counting.

So it does not happen. Instead the QBR gets prepared from memory and last quarter's deck, the account manager asks "how's everything going," the client says "fine," and both parties leave without discussing the nineteen unused licenses or the fifteen unprotected endpoints.

This is not a discipline failure. It is an arithmetic problem, and arithmetic problems are what software is for.

What Changes When the Reconciliation Is Automatic

The QBR stops being a relationship meeting and becomes an evidence meeting.

You walk in with a per-client list: here is what you are contracted for, here is what we found deployed, here are the differences, and here is what each difference is worth per month. Some of those differences are things you owe them. Some are things they owe you. Most are things neither of you knew.

That is a fundamentally different conversation from a service catalog. The client is looking at their own environment, not your brochure. You are not pitching — you are reporting. And the items you are proposing arrive with the credibility of the items you just fixed for free.

The MSPs who run this well tend to lead with the uncomfortable finding. "Before anything else: we bill you for EDR on 62 seats and we found it running on 47. That is on us, we are fixing it this week, and we are crediting the difference." Every proposal after that lands differently.

Turning a Finding Into an Invoice

A finding is not revenue until it moves through your normal sales motion, so the mechanics matter more than the discovery.

Dollarize everything. "Fifteen endpoints without EDR" is a fact. "Fifteen endpoints without EDR — $10 per seat per month, $1,800 a year" is a decision. If a finding cannot be priced from your own rate card, it is not ready to present.

Present a selection, not a dump. Ten findings handed over at once produces paralysis. Three, ranked by risk, produces a decision. Hold the rest for the next quarter — a roadmap you visibly work through is more valuable than a single overwhelming list.

Push it into the pipeline the same day. A finding discussed in a QBR and not entered as an opportunity is a finding that will be rediscovered next quarter. It should land in your CRM or PSA sales pipeline before the meeting notes are written.

Count what closes. This is the part almost everyone skips. If you cannot say at renewal how much signed revenue came out of these findings, you are relying on goodwill. If you can, the renewal conversation starts with a number instead of a feature list.

What This Is Not

It is not a vulnerability scan. It does not touch your clients' endpoints or change anything in their environment. The whole exercise is read-only: it reads what your own systems already recorded.

It is not a replacement for a vCIO. It is the preparation a vCIO never has time to do — the counting, so the human can spend the meeting on judgment instead of arithmetic.

And it is not a prospecting tool. These are clients who already trust you, already pay you, and already answer your calls. That is precisely why this revenue closes faster and at higher margin than anything you win competitively.

Where to Start

Pick your five largest clients by monthly recurring revenue. For each, reconcile three things by hand: contracted seats versus RMM-reported endpoints, contracted services versus deployed agents, and Microsoft licenses purchased versus assigned.

It will take you an afternoon and you will find something in at least four of the five. That afternoon is also the business case — whatever you find across five clients, multiply by your client count and decide whether doing it continuously is worth automating.

Most MSPs discover the answer is obviously yes, and that the first client they check pays for the whole exercise.

Frequently Asked Questions

Does connecting our PSA give anyone access to our client data?

It should not, and you should insist on read-only. A tool that reconciles contracts against reality needs to read agreements, endpoints and license counts. It has no reason to write anything, and no reason to read ticket bodies, notes or resolutions. Ask any vendor exactly which API endpoints they call and what permissions they request. If the answer is vague, that is your answer.

Our PSA data is messy. Does this still work?

Messy data changes what you find first. If agreements are inconsistent, the first pass surfaces the inconsistencies rather than the upsells — which is itself worth knowing, because you cannot bill accurately from records you do not trust. Most MSPs run one cleanup cycle and then find the reconciliation useful forever after.

How is this different from a cross-sell list?

A cross-sell list tells you what a client could buy, generally, based on their industry and size. This tells you what a specific client is missing right now, based on their own systems, with a seat count attached. The first is a conversation starter. The second is a proposal.

Won't clients be annoyed that we found things we should have caught?

Some findings are uncomfortable, and the ones that show you under-delivered are the most uncomfortable of all. In practice, MSPs who lead with those findings — and fix them without being asked — report that trust goes up, not down. The alternative is that the client finds it during an incident, which is a far worse meeting.

---

MSProspector is built by Marketopia, the MSP channel's growth partner since 2014. Client Upsell connects your PSA, RMM and Microsoft 365 read-only and reconciles what you are contracted for against what is actually deployed — dollarized per client. See how it works.