Four worked responsibility matrix templates you can use as a starting point, covering onboarding, everyday operation, offboarding, and the case where a third party’s product is in your stack. They accompany The SaaS Roles and Responsibilities Chart. These are illustrations built for a made up company called Acme. Take the structure, not the wording.
Two things to notice. The rows are grouped by who owns them, so a customer can read one block and see everything they owe you. And “shared” is used often, because plenty of this work genuinely is shared. It never appears on its own. Every shared row says who does which part.
1. Onboarding and Implementation.
The one to build first. This is where your customer has the most work to do and the least idea that they have any.
What we do
- Environment build. We provision your tenant, configure single sign on and stand up the sandbox. Within 10 business days of the order date.
- Integrations. We build and test the connectors listed in the Order Form. Anything not on that list is a change order.
- Training delivery. We run the sessions in the Order Form and record them so you can re-use them.
- Project management. We give you one named project manager and a weekly status update until go live.
What you do
- Access and credentials. You give us identity provider metadata, firewall access and a named technical contact. Within 2 business days of our request.
- A decision maker. You name one person who can approve scope and sign off. If that person changes, you tell us.
- Acceptance testing. You test against the agreed criteria and either sign off or send a written defect list. Within 10 business days of handover. Silence for that whole window counts as acceptance.
- Getting people to training. You get your administrators to the scheduled sessions. Re-runs for people who did not show up are billable.
What we share, and who does which part
- Project plan and kickoff. We write the plan and run the kickoff call. You confirm the scope in writing. Both within 5 business days of the order date.
- Data migration. You export your data in our template and confirm it is complete. We load it and send back record counts. You check the counts and flag gaps. Each step within 3 business days of the one before it. Files outside the template are billed at our professional services rate.
- Business rules. You tell us your rules and sign off on the written summary we send back. We build to that summary. Anything not in the summary is a change order.
- Go live approval. We confirm the environment is ready. You confirm your team is ready. Neither of us goes live without the other saying so in writing.
Attached to the Order Form. Where this exhibit conflicts with the Master Subscription Agreement, the Agreement controls.
2. Everyday Operation.
Once you are live there is less handoff and more overlap. Most of the real risk sits in the shared block, which is exactly why every row in it says who does which part.
What we do
- Running the platform. Hosting, capacity and uptime, to the number in the SLA. This one is entirely ours.
- Monitoring. We watch the service and tell you about anything that affects your tenant.
- The admin console. We give you role controls, an audit log and access reports.
- Backups. Nightly, kept 30 days. Restore started within 4 hours of your request.
What you do
- Your users. You add and remove your own people, and you review the list quarterly. Access left open after someone leaves your company is yours.
- Acting on what we send. You act on the alerts, findings and end of life notices we send. We can tell you. We cannot make you.
- Your own configuration. You make your own changes in the console. What you configure is yours, including the consequences.
- Your own copy of the data. You keep a copy of anything you cannot afford to lose. Our backups are for our failures, not yours.
What we share, and who does which part
- Security patching. We patch the platform, the operating system and everything in our stack. You patch your browsers, endpoints and middleware, and apply the agent updates we push. Within 30 days of release.
- Security incidents. We detect and investigate anything inside our platform and notify you within 24 hours of confirmation. You handle anything coming from your own accounts, devices or network, and keep a current security contact on file.
- Your data. We store it, encrypt it and back it up. You decide what goes in, and you tell us before you load anything regulated.
- Releases and upgrades. We ship the release, publish notes in advance and keep the sandbox current. You test anything you built on our API and tell us about breakage, inside the 14 day notice window.
- Support. You open the ticket with steps to reproduce. We respond inside the SLA severity times and work it to resolution. We commit to a response time, not to a fix by a date.
Attached to the Order Form. Where this exhibit conflicts with the Master Subscription Agreement or the SLA, those documents control.
3. Offboarding and Transition Out.
The one almost nobody writes. Write it while everybody still likes each other.
What we do
- Keeping the lights on. The service runs normally through the last day of the term. We do not degrade it because you gave notice.
- Your data back. We give you a full export in the format named in the Order Form, within 10 business days of your written request. One export is included. Extra ones are billable.
- Deletion. We delete your data 30 days after the term ends and certify it in writing if you ask. Backups age out on their normal cycle.
- Answering questions. We answer reasonable questions about the export format at no charge for 30 days after the term ends.
What you do
- Notice. You give notice the way the Agreement says, in the window the Agreement gives you. A phone call to your account manager is not notice.
- Paying up. Fees owed through the end of the term are still owed, including any prepaid term you are leaving early.
- Taking the export. You download and verify the export before your access ends. Once the 30 days run out it is gone, and we cannot get it back for you.
- Your side of the plumbing. You remove our agents, keys and integrations from your systems, and you revoke the access you gave us.
What we share, and who does which part
- Transition plan. You tell us your target cutover date. We give you a written plan and a named contact, within 10 business days of notice.
- Knowledge transfer. We deliver the hours bought in the Order Form. You schedule them inside the notice period and bring the right people. Anything beyond those hours is a paid engagement at our then current rates.
- Helping your new provider. We answer their format and mapping questions during the transition window. You handle the relationship, the contract and the timeline with them. We do not take direction from your new vendor.
- Extending the window. Either of us can ask. Both of us have to agree, in writing, before the term ends. Extensions are billed monthly at our then current rates.
Attached to the Order Form. Where this exhibit conflicts with the Master Subscription Agreement, the Agreement controls.
4. When It Is Somebody Else’s Product.
If you resell, embed or manage another company’s software, there are three parties and your customer only signed with one of them. RapidScale publishes roughly 52 of these charts publicly, one for every product they manage, which is a recognition that the split genuinely changes depending on whose software is underneath. Their public library of responsibility matrices is the best live example we know of, and if it moves you can find it again on rapidscale.net.
What we do
- Standing it up. We size, deploy and configure the product to the design in the Order Form, and validate it against the vendor’s reference architecture.
- Day to day operation. We monitor it, triage what it reports and send you what matters.
- The vendor relationship. We open, escalate and chase vendor tickets, and keep you updated weekly until they close.
- Licence renewal. We keep the product licence current for as long as this service is running.
- Our own uptime. Our SLA covers monitoring, response and change execution. It does not cover the vendor’s product being down.
What you do
- Access. You give us network access, credentials and a technical contact, within 2 business days of our request.
- Acting on findings. You act on what we send you. Findings you leave open more than 30 days come off our responsibility.
- Telling us about changes. You tell us before you change your network, your identity provider or anything else the product sits in front of.
What we share, and who does which part
- Patching the product. The vendor publishes the patch. We test it and schedule it. You approve the maintenance window within 5 business days of our request, or we apply it in the next standard window.
- Product defects. The vendor owns the fix. We open and chase the ticket. You give us whatever the vendor asks for. None of us can make the vendor go faster.
The product vendor is not a party to this agreement. Their obligations run to us, not to you. Attached to the Order Form; the Master Subscription Agreement controls in a conflict.
The row that decides the deal. Your customer signed with you, not with the vendor, and they are not going to chase the vendor. So unless your contract says otherwise, the vendor’s failures are still your problem. Pick one, on purpose, before you sign: pass the vendor’s terms through to your customer, cap your exposure at whatever you can actually recover from the vendor, or carry the risk and price it in.
Common 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.
A Word of Warning.
These are illustrations, not templates to sign. The deadlines, retention periods and carve outs above are made up to show the format. Yours should come from what your delivery team actually does and what your agreement actually says.
Want help building yours? Contact us to talk through your onboarding, your integrations or your customer paper.