The SaaS Vendor Lifecycle for Small MSPs

Nobody owns your stack

Pull your credit card statement and your ACH history for the last twelve months. Circle every software charge. Most owners in the 10 to 20 employee range find between 40 and 80 vendors. Then ask three questions about each one.

Who owns it? When does it renew? What breaks if we turn it off tomorrow?

You will not have answers for most of them. That is the actual problem. Not the spend, though the spend is real. The problem is that nobody owns the decision to keep paying.

Here is how it happens. A tech finds a tool, expenses it, and it works. Two years later that tech is gone and the tool still bills monthly. A vendor sold you a bundle during a conference and you never rolled it out past two clients. Somebody signed an annual agreement with auto-renew and a 60 day notice window, and you found out about the window 30 days before it closed. A tool got replaced by a better one and the old license kept running because canceling required a support ticket nobody wanted to write.

None of that is a discipline problem. It happens because there is no process. Buying software feels like a decision and it is actually a lifecycle. You select it, you justify it, you implement it, you review it, and eventually you kill it. Skip any of those five and the stack rots.

This page walks all five. It works whether you have eight people or twenty, and it takes hours, not weeks.

The framework here comes from the GTIA SaaS Ecosystem Advisory Council's Five Phases SaaS Implementation workbook. Their version assumes you have a project manager, a security lead, and a finance owner sitting in separate chairs. You do not. This version assumes you and maybe one other person handle all of it.

Two stacks, one process

Before you start, split your vendor list in two.

Internal tools are what you run the business on. PSA, RMM, documentation platform, accounting, phone system, email. You pay for them and you absorb the cost. Success means efficiency, margin, and fewer hours per ticket.

Client-facing tools go into stacks you resell. Backup, EDR, email security, awareness training, anything you mark up and bill through. Success means margin, adoption, and a clean story when a client asks what they are paying for.

The same five stages apply to both. The questions change. A client-facing tool needs a pricing model, an MSA update, and a multi-tenant management story. An internal tool needs none of that but needs a hard answer on what it replaces.

Sort every vendor into one bucket or the other before you go further. Some tools land in both. Note those, because they carry the requirements of both.

Stage one: before you buy

You do not need a 40 point evaluation matrix. You need answers to the questions that actually cost you money when you get them wrong.

The nine questions

1. What does this replace? If the answer is nothing, you are adding to the stack, not fixing it. That is allowed, but say it out loud.
2. Who owns it after we buy it? Name a person. Not a department, a person.
3. What does it cost fully loaded? License plus onboarding plus the hours to deploy it plus the hours to support it every month.
4. What are the contract terms? Month to month, annual, or multi year. Auto renew or not. Notice window in days. Early termination penalty.
5. Where does our data live and can we get it back? Ask for the export format. Ask whether export survives cancellation.
6. Does it support SSO, MFA, and role based access? If a vendor holds client data and offers none of the three, that is your answer.
7. Does it integrate with our PSA, RMM, and documentation platform, and does that integration cost extra?
8. If this is client facing, what is the pricing model and what margin do we hold at our smallest client size?
9. Does the vendor have an API and can we get read-only credentials?

That last one used to be a nice-to-have. It is not anymore.

The AI question, and why it belongs here now

Every tool you buy either feeds your AI stack or hides from it.

If you connect your documentation platform, PSA, and RMM to an LLM through MCP servers, you get an assistant that answers real questions about your business. Which clients have the most open tickets. What did we document about this client's firewall. What has this tech been working on this week. That works because those systems expose their data through an API you can reach.

A vendor with no API is a data island. Whatever it holds stays locked in its own dashboard, and every question about it stays manual forever. That was tolerable when the answer was a report you ran once a quarter. It is expensive now.

So add these to your evaluation, for internal and client-facing tools alike.

• Does the vendor publish an API, and what does it cost?
• Can you create read-only credentials, scoped, not a shared admin account?
• Does the vendor ship or plan an MCP server?
• If you asked the vendor to explain how a partner connects their platform to an LLM, does anyone there have an answer?

Read-only matters more than the rest. When you connect a system to an LLM, you give it write and delete access at your own risk, and the failure mode is not a bad answer, it is deleted tickets or overwritten documentation. Every connection is read-only, scoped to a service account created for that purpose, never a shared login, never an admin credential borrowed from a tech who left.

A vendor that cannot support a read-only service account tells you something about how they think about security generally.

Copy this into an email to the vendor

Send this before the second demo.

Before we go further I need answers to a few things in writing.

1. Contract term, notice period to cancel, and whether the agreement auto renews.
2. Early termination terms and any penalty.
3. Data export. What formats, and does export remain available after cancellation.
4. SSO, MFA, and role based access. Which are included and which cost extra.
5. Integrations with [PSA], [RMM], and [DOCUMENTATION PLATFORM]. Native, through a third party, or none. Any additional cost.
6. API access. Included or extra, rate limits, and whether we can create read-only service accounts.
7. Whether you offer or plan to offer an MCP server.
8. Compliance attestations you hold today. SOC 2 type, HIPAA, ISO 27001, CMMC alignment.

If any of these are not available in writing, tell me that directly and I will factor it in.

A vendor who answers all eight in two days is a vendor who will answer a support ticket. A vendor who stalls on question three is telling you what leaving them looks like.

Stage two: justify it in one page

Most business case templates fail because they are twelve pages long and nobody fills them out. Yours is one page and it takes fifteen minutes.

Copy this. Make it a required document before any software purchase over whatever number matters to you. For most shops that number is somewhere between $100 and $500 a month.

Tool: Requested by: Owner after purchase: Internal or client facing:

What problem does this solve, in one sentence:

What it replaces: If nothing, why we are adding it:

Cost. License per month: Onboarding or setup cost: Estimated hours to deploy: Estimated hours per month to support: Fully loaded monthly cost:

If client facing. Our cost per seat or endpoint: Our price per seat or endpoint: Margin at our smallest client: Does this go into the base stack, a bundle, or an add-on:

How we know this worked in 90 days. Pick metrics you already pull from the PSA:

Contract. Term: Notice period: Renewal date: Auto renew yes or no:

Approved by: Date:

The 90 day metric line is the one people skip and it is the one that matters. Pick numbers you already have. Average time on ticket. First call resolution. Tickets worked per day. Hours logged against a specific board. If a tool cannot move a number you already track, you are buying a feeling.

Set the renewal date as a calendar reminder the day you sign, 30 days before the notice window opens. Not the renewal date. The notice window. That single habit saves more money than any negotiation you will run.

Stage three: your kickoff before the vendor's kickoff

Vendors run their own onboarding. That call is about their product. It is not about your business, and you will spend it reacting.

Spend 45 minutes internally first. Three people is enough. Whoever owns the tool, whoever owns the integrations, and you.

Run this agenda.

Ownership, five minutes. Name the owner. Name the backup. Write both down somewhere permanent, which means your documentation platform, not a Slack message.

Scope, ten minutes. What are we turning on in week one. What are we deliberately not turning on. Most tools fail because a shop tried to deploy everything at once and finished nothing. Pick two features.

Access and security, ten minutes. Configure SSO and MFA before the first user logs in, not after. Define who gets admin and who gets standard. Create the read-only service account now if you plan to connect it to anything. Add the vendor domains to your allowlist. Put the vendor's security documentation where your team can find it during a client questionnaire.

Integrations, ten minutes. Which systems does it touch. Who has the credentials. What scope does each integration get. Write down what breaks if the integration fails.

Rollout, ten minutes. Internal first, always. Deploy to your own environment before a client sees it. Set the go-live date. If this is client facing, decide now whether it goes into the base stack, a bundle, or an add-on, and whether your MSA needs an update. Decide who tells clients and what that message says.

You walk into the vendor call with a list of questions instead of a blank page. The whole point.

Stage four: the quarterly review nobody runs

Once a quarter, block 90 minutes. Do not review all 60 vendors. Review five.

Pull your vendor list and sort it three ways. Anything renewing in the next 120 days. Anything with a price increase since the last review. Anything anyone complained about. The top five off that combined list is your agenda.

For each one, answer ten questions. The first five should be yes. The second five should be no.

Should be yes:

1. Did we finish onboarding, including the parts that were our fault?
2. Is this business critical today?
3. Does this still fit how we operate now, not how we operated when we bought it?
4. Are we using more than the two features we launched with?
5. Are we hitting the 90 day metric we wrote in the business case?

Should be no:

6. Are we paying more than this is worth?
7. Has the team complained about it since the last review?
8. Is there something already in our stack that does this?
9. Has the vendor had a breach or serious vulnerability since the last review?
10. Has the price changed, or does the contract renew before our next review?

Add an eleventh now.

11. Is this tool still a data island, and has the vendor moved on API or MCP access since we last asked?

Vendors ship API and MCP support quarterly these days. The vendor who told you no eighteen months ago may have shipped it since. Nobody sends you that email. Ask.

Any answer that lands on the wrong side becomes one task with one owner and one due date. Not a discussion. A task.

Close each vendor with a single decision. Keep, optimize, renegotiate, replace, or decommission. Write the reason in one line. Next quarter you will want to know what you were thinking.

Stage five: killing a vendor properly

Cancellation is not a decommission. Most shops cancel the billing, forget the rest, and leave agent software on endpoints, API tokens live, and the vendor's name sitting in a client-facing compliance document.

Work this list.

Contract. Confirm the notice window and the exact date notice is due. Confirm who sends it and in what format, because some vendors require written notice to a specific address and will not accept an email to your rep. Confirm early termination fees. Confirm auto renew is actually stopped, in writing.

Data. What can you retain and in what format. Can you still export after you give notice, because some platforms cut export access on the cancellation date. Pull the export before you send notice, not after. Get evidence of deletion on their side if the tool held client data.

Access and integrations. Revoke API tokens. Unlink integrations from your PSA, RMM, and documentation platform. Remove the read-only service account. Remove user accounts. Check whether the vendor had any standing access into your environment or a client's.

Technical footprint. Is there an agent on endpoints. Are there cloud configurations, tenant level permissions, DNS records, or mail flow rules. Know how to remove each one before you turn off billing, because support goes away with the subscription.

Downstream. Is this vendor named in a client contract, a quote, a proposal, or an MSA. Is it on a sub-processor list. Is it on your website or in sales collateral. Does removing it change a compliance commitment you made to a client. This is the step that generates the awkward call six months later.

Communication. Who needs to know. Your team, affected clients, and anyone whose workflow changes. Update documentation the same week, not eventually.

Then, and only then, cancel the billing.

What good looks like in 90 days

You do not need all five stages running at once. Run them in this order.

Week one. Build the vendor list. Every recurring software charge, one row each, with owner, renewal date, notice window, and internal or client facing. A spreadsheet is fine. This is the whole foundation and most shops have never done it.

Week two. Set calendar reminders for every notice window, 30 days before it opens. This alone pays for the exercise.

Week three. Run your first quarterly review on your five worst vendors. You already know which five they are.

Week four. Put the one page business case in front of the next purchase request. Make it the rule going forward.

After that it is maintenance. 90 minutes a quarter and 15 minutes per purchase.

Where this usually goes sideways

The list gets built and never updated. Assign one person to add a row every time a new charge appears. It takes 60 seconds.

The review gets skipped in a busy quarter. Skip it twice and the discipline is gone. Put it on the calendar as recurring, same week every quarter, and treat it like a client meeting.

The owner leaves and takes the knowledge with them. That is why owner and backup go in your documentation platform, not in somebody's head.

Everything gets kept. If a review never ends in a decommission, you are not reviewing, you are confirming. Some tools should die.

Source

Adapted from the Five Phases SaaS Implementation workbook produced by the GTIA SaaS Ecosystem Advisory Council, part of the Global Technology Industry Association. The original is written for larger providers with dedicated project management, security, and finance roles. This version is rebuilt for owner-operated shops in the 10 to 20 employee range and adds the API and MCP evaluation criteria the original predates.

Talk it through

Most owners can build the vendor list themselves. Where it gets harder is deciding what to cut, what to renegotiate, and how to connect what remains to an LLM without handing write access to a system that runs your business.

Everything above is a template. Run it yourself this week and never talk to me. What I will not do is hand you a system and tell you your shop is wrong for not matching it.

Not sure this is your actual constraint? Take the MSP Owner Reality Check. Five questions, nine minutes, and it names the two or three things quietly capping your growth. https://themsphero.com/resources/msp-owner-reality-check-assessment

If you already know what is broken, book a 30 minute fit call at https://letschat.themsphero.com

Mike Kolb The MSP Hero