Responsibility Matrix for SaaS: Onboarding, Operation, Offboarding

A roles and responsibilities chart says which parts of the job are yours and which parts are your customer’s. If you sell SaaS, you want one. (Some people call it a responsibility matrix. Same thing.) Not because it is tidy, but because almost every fight I get pulled into is a version of the same sentence: “I thought you were doing that” or “I can’t believe the customer believes we should handle that and they won’t pay unless we do it!“.

Build three of them, one for each stage of the relationship:

• Onboarding. Getting them live.
• Operation. The years in the middle.
• Offboarding. Getting them out.

Here is what goes in each one, and the one rule that matters more than the rest.

First, the Rule About Shared.

You will read advice telling you never to write “shared” in a responsibility chart. Ignore it.

Plenty of this work genuinely is shared. Security is shared. Data is shared. Pretending everything splits cleanly makes the chart dishonest, and your customer will spot it in about ten seconds.

The problem is never the word. The problem is a chart that says “shared” and stops there, because “shared” on its own is how a job ends up done by nobody.

So define it. Every time you write shared, add the sentence saying who does which part:

Security patching. Shared. We patch the platform, the operating system and everything in our stack. You patch your browsers, endpoints and middleware, and you apply the agent updates we push, within 30 days of release.

Still shared. Just shared with the ambiguity taken out.

1. Onboarding.

Start here. It is the easiest to write and it pays for itself on the first project.

Implementation is where your customer has the most work to do and the least idea that they have any. Put their side in writing before the project starts:

• Data, in your format. Say what the template is and who checks the record counts.
• Who handles onboarding the data. Always a hot issue.
• Access and credentials. An easy one.
• Testing. And what happens if they go quiet. Silence for the whole acceptance window should count as acceptance.
• People at training. Re-runs for no-shows are billable.

Then put a deadline next to your own rows too, so it does not read like a list of demands.

When the data shows up four weeks late in the wrong format, you are not arguing about whose fault the delay is. You are pointing at a line they already agreed to, and the conversation is about a change order instead. Expert Tip: The funny thing is customers actually WANT to know what they need to do to make your service successful, so you will have their full attention.  

Click any chart to open it full size. The full onboarding chart, written out row by row.

2. Operation.

Once you are live there is less handoff and more overlap, and the overlap is where the risk is. Most of this chart is shared rows, which is fine, as long as each one is spelled out:

• Security patching. You patch your stack. They patch their endpoints.
• User access/provisioning. You give them the tools, they decide who gets access.
• Their data. You store it and back it up. They decide what goes in, and maybe they keep their own copy of anything they cannot lose.
• Security incidents. You handle anything inside your platform. They handle anything coming from their own accounts and devices.
• API Changes. You ship it and give notice. They test whatever they built on your API inside the notice window.
• Support. They open the ticket with steps to reproduce. You respond inside the SLA. Commit to a response time, never to a fix by a date.

The full operation chart, written out row by row.

3. Offboarding.

Almost nobody writes this one, and it is the one that goes worst when it is missing. Write it while everybody still likes each other.

What to cover:

• What notice actually means. In writing, in the window the agreement gives them. A phone call to their account manager is not notice.
• The export. What format, how long you take, and how many are included. One free export, extras billable, is a reasonable default.
• The window. How long they have to download it before access closes. Say plainly that once it lapses the data is gone.
• Deletion. When you delete, whether you certify it, and what happens to backups.
• Transition help (the big one!). They typically want it for free, but rarely do vendor’s price this in. So say that.

Two reasons this is worth the hour it takes. Transition assistance is a service, and if you have not priced it in advance you will end up giving it away during the worst month of the relationship. And a prospect who can see exactly how they would get their data out is easier to sell to in the first place. (I know that sounds backwards. It is not.)

The full offboarding chart, written out row by row.

One More, If You Resell Somebody Else’s Product.

Two columns stop working the moment there is another company’s software in your stack. Look at what RapidScale does about it: roughly 52 separate responsibility charts (you heard that right), one for every product they manage. Alert Logic, Fortinet, Veeam, Citrix, Cisco SD-WAN, Datadog, Mimecast, Zerto, Microsoft 365, and on down the list. There is even one for managing FortiGates the customer bought themselves.

Fifty two charts is not enthusiasm. It is a recognition that the split genuinely changes depending on whose software is underneath.

So add the vendor as a third party in the chart, and be specific about the handoffs. Who tests the vendor’s patch. Who approves the maintenance window. Who chases the vendor ticket when the vendor goes quiet.

And then the row that decides the deal: your customer signed with you, not with the third party vendor, and they are not going to chase the third party vendor. Unless your contract says otherwise, the third party vendor’s failures are still your problem.

The full three party chart, written out row by row.

Three Things That Make a Responsibility Matrix Work.

• Define every shared row. Covered above, and it is the most important one by a distance.
• Put a deadline on both sides. Almost nobody does this. “Within 3 business days” on your line and theirs turns the chart into a mutual clock, and when they are the one who is late you have a document that says so. Same thinking as your SLA.
• Say what it attaches to and what wins. A chart on your website is marketing. A chart named in the order form, with a line saying the agreement controls in a conflict, is a term. Same question as contract or policy.

Frequently Asked Questions.

If I only build one, which? Onboarding. Your delivery team already knows the answers, and that is where the customer dependencies are heaviest.

Can I really write “shared”? Yes, as long as you say who does which part. Shared with a definition is honest. Shared on its own is a gap with a label on it.

Does it have to be in the contract? It does nothing for you legally until it is named in the order form or referred to in your SaaS agreement or Terms of Service. Until then it is a sales asset.

Who should write it? Your delivery team drafts it, because they know what actually happens. Then your lawyer makes it enforceable. The other way round produces a document nobody in operations recognizes.

How long should it be? Long enough that you never wrote shared without explaining it. That is the test, not the page count.

Start with onboarding. You will use it on the next project. I hope this helps.

A Real World Example Worth Ten Minutes.

RapidScale publishes its entire library of responsibility charts publicly, and it is the best live example I know of: RapidScale Responsibility Matrices. Roughly 52 of them, one per product they manage. Open two or three and look at how they handle the joint rows, how they scope a line to a specific tier, and how they split implementation from ongoing support.

RapidScale’s public library, roughly 52 charts, one per product they manage. Click to open it full size. Source: RapidScale.

Go look at it before you write your own. You will steal something. (If that link has gone stale by the time you read this, search “responsibility matrix” on rapidscale.net. Their library moves around, the charts do not.)

 

Two Old Ones That Are Still Great Examples.

These two are more than a decade old between them, and both companies have since been renamed. I still send them to clients, because I have not seen either one improved on.

FireHost, 2014. Sixteen security areas, three columns, one page. It groups the rows by owner in color blocks, which is exactly the layout you want. It carries a version number on its face, “v. 4.3,” which almost nobody bothers to do. And it is honest about being an abstract, telling you at the bottom to email sales for the full responsibilities matrix. The public sheet is the hook. The real one is a conversation. FireHost became Armor in 2015 and this PDF is long gone from the web, which is its own small lesson about where you keep these things.

Kareo, 2016. The best one I have ever seen (oh yea, sorry, I created this with them), and it comes from medical billing rather than software. Both columns are written out in sentences instead of checkmarks. Every row carries a turnaround time on both sides, which quietly turns it into a mutual clock. It is organized around the customer’s own workflow rather than Kareo’s org chart. And it states its own fee triggers and carve outs right in the rows. It opens by telling the customer “we cannot do this without you, but together we can succeed,” which is the whole idea in one sentence. Kareo merged with PatientPop and is now Tebra.

Click either one to open it full size.

Resources:

• SaaS Agreements Are NOT Good Communication Vehicles
• SLA in Software: What Goes In One and What It Costs You
• Contract or Policy?
• Tell Your Customer to Backup Their Data

Disclaimer:

This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.