Most of your clients now keep their email, files and calendars in Microsoft 365 or Google Workspace, and most of them assume Microsoft or Google is backing it up. Neither does, beyond short retention windows. A deleted mailbox is gone after 30 days, a purged SharePoint library after 93, and a ransomware-encrypted OneDrive syncs its damage into the cloud within minutes. When a client discovers this, the question lands on their MSP.

That makes SaaS backup one of the easiest lines to add to a service catalogue: the need is already there, the per-user pricing model is one clients understand, and the technical setup is a one-time job per tenant. This article covers what clients expect from the service, how to package and price it, and how to register the tenant application once so backups can run unattended from then on. It closes with how the managed Microsoft 365 and Google Workspace backup in the Duplicati Console maps onto each of those points.

What clients expect from SaaS backup

Clients rarely ask for "backup" in the abstract. They ask for a handful of outcomes, and the service only earns its fee if it delivers all of them.

Departed-user mailboxes. This is the single most common request. An employee leaves, the licence is reclaimed to save money, and three months later legal or sales needs that person's email. Keeping the account licensed forever is expensive; letting it expire loses the data. A backup that keeps the mailbox, drive and calendar after the account is deleted, searchable and restorable, resolves the conflict. Make it explicit in the service description that departed users remain protected and are not billed as active seats.

Cross-tenant restores. Mergers, divestitures, rebrands and migrations between Microsoft 365 and Google Workspace all end with data that needs to land somewhere other than where it was backed up. A backup that can only restore into the original tenant is a liability the day the tenant is decommissioned. Clients expect to restore a mailbox or drive into a different tenant, a different user, or a local export, and to do it without involving the vendor.

Granular, self-explanatory restores. The typical request is one email, one folder or one file from a specific date, not a full mailbox. Restores should be point-in-time, browsable, and possible without the MSP re-ingesting an entire account.

Protection against the things native retention does not cover. Ransomware that encrypts synced drives, a disgruntled admin who purges accounts, a retention policy that was misconfigured and quietly deleted two years of mail. Clients expect the backup copy to live outside the tenant, under separate credentials, so that whoever compromises the tenant cannot also delete the backup.

Per-user pricing. Clients already pay Microsoft and Google per user per month, and they expect backup to be quoted the same way. A flat per-seat price with storage included is far easier to sell than a storage-metered fee that nobody can predict. Build the storage into the seat price and keep the overage story simple.

Evidence. Clients in regulated industries, and increasingly their cyber-insurers, want to see that backups ran, that they are encrypted at rest, and that restores have been tested. Status reports and a documented restore procedure are part of the service, not an add-on.

How to package it

The service sells best as a line item on the existing per-user agreement, not as a separate project. Three decisions shape the package.

Scope: bundle or opt-in. Bundling SaaS backup into the standard per-user managed-services fee is the simplest and gets near-100% coverage, which is also what protects you when a client later asks why a mailbox was not backed up. Offering it as an opt-in add-on gives a visible price point, but leaves gaps you will be blamed for. Most MSPs that start with opt-in move to bundled within a year; if you do offer opt-in, make it per tenant, not per user, so that nobody is half-covered.

Price: seat plus included storage. Quote one price per user per month that includes a storage allowance generous enough that the typical user never exceeds it. Your cost side is the backup licence per seat plus storage, both of which are predictable, so a per-seat margin is straightforward to set. Leave room for a per-tenant minimum (a five-user tenant costs as much to onboard as a fifty-user one) and define what happens to departed users: the usual answer is that they are retained at no charge for as long as the tenant subscribes, since they consume storage but no new backup runs.

Service levels: what you commit to. Define the backup frequency (daily is the norm; more often for mail if the tooling supports it), the retention period (one year minimum; many clients want indefinite for departed users), the restore turnaround (same business day for single items, next business day for full mailboxes), and the reporting cadence (a monthly summary plus alerts on failures). Put the restore procedure in writing and test it with each new client as part of onboarding, so the first restore is not the first time anyone has tried it.

A minimal catalogue entry looks like this:

Setting up the tenant app registration once per client

Both platforms let a backup tool authenticate as an application rather than as a user. That is the right model for an MSP: the credential does not belong to any employee, it does not expire when someone leaves, it is not affected by MFA prompts, and it can be revoked from the client's admin console at any time. The registration is done once per tenant, during onboarding, and reused for every backup and restore after that.

Two rules apply to both platforms. First, the client's global admin (or you, acting under delegated admin rights) performs the registration inside the client's own tenant, so the client always retains control and can see exactly what the application is permitted to do. Second, record the resulting identifiers and secret in your password manager under the client's entry, with the secret's expiry date as a calendar reminder, since a silently expired secret is the most common cause of backups stopping months later.

Microsoft 365 (Microsoft Entra ID)

1. In the Microsoft Entra admin centre, open App registrations and create a new registration. Name it clearly (for example "Backup – YourMSP") and set it to single-tenant.

2. Note the Application (client) ID and Directory (tenant) ID from the overview page.

3. Under Certificates & secrets, create a client secret. Choose the longest expiry your policy allows (24 months is the maximum) and copy the value immediately; it is shown only once. A certificate works as well and does not expire as quickly, at the cost of a little more setup.

4. Under API permissions, add Microsoft Graph application permissions (not delegated) for mail, calendars, contacts, OneDrive files, SharePoint sites and the user directory. The backup tool documents the exact list; use read permissions for backup and the matching read/write permissions if you want restores into the tenant.

5. Click Grant admin consent for the tenant. Until this is done, the permissions are requested but not active.

6. Enter the tenant ID, client ID and secret into the backup tool and run a first backup to confirm access.

Google Workspace

1. In the Google Cloud console, create a project for the client (or one per client in your own organisation, if you prefer to hold the projects) and enable the Gmail, Google Drive, Google Calendar, People and Admin SDK APIs.

2. Create a service account in that project and generate a JSON key for it. Download and store the key; it is the credential the backup tool will use.

3. On the service account, note the numeric client ID (not the email address).

4. In the Google Workspace Admin console, go to Security → Access and data control → API controls → Domain-wide delegation and add the client ID with the OAuth scopes the backup tool requires. Domain-wide delegation is what lets the service account act on behalf of every user in the domain.

5. Enter the service account key and the admin email the tool should impersonate for directory lookups, then run a first backup.

Keeping it tidy

Use the same naming convention across tenants so a client's admin can recognise the registration years later. Document the permission set in the client's runbook. When you offboard a client, delete the registration or the service account, which revokes access cleanly without touching anything else in their tenant.

How this maps onto managed backup in the Duplicati Console

The Duplicati Console now offers fully managed Microsoft 365 and Google Workspace backup, built so that an MSP can deliver everything above without running backup infrastructure of its own. The Console handles scheduling, runs the backup jobs on demand, and stores the encrypted result; you handle the client relationship.

Per-user seats with storage included. You buy one seat per protected user, billed yearly, monthly or pay-as-you-go. Each seat adds 100 GB of Duplicati cloud storage to the organisation's pool, so the per-user price you quote to clients already covers storage, with no metered surprises. If a client requires data to stay in their own cloud account, point the backup at their own destination instead; the managed runner and the Console workflow stay the same.

Same-tenant and cross-tenant restores. Restores can go back into the original tenant or into a different one, which covers the migration and divestiture cases above. Departed users remain in the backup set and restorable after the account has been removed from the tenant.

One registration per client, then nothing to maintain. The tenant app registration described above is done once, in the client's tenant, and the credentials are handed to the Console. From then on the backups run on Duplicati's infrastructure with no agent to install, no VM to patch and no schedule to babysit. The same credentials work if you would rather run the backup from a self-hosted Duplicati instance.

Encrypted before it leaves, and an exit path. Data is encrypted client-side before it reaches storage. The encryption key for a managed backup is shown to you before it is stored, so you can keep your own copy, and a restore-only key for Duplicati-provided storage lets you read the backup from outside the Console if you ever need to. Your clients' data is never locked to the platform.

Reporting your clients can see. Backup status, history and failures are visible per organisation in the Console, with alerts on problems, so the monthly evidence your clients and their insurers ask for is already there.

Getting started

If you already manage client endpoints through the Duplicati Console, adding SaaS backup is a matter of buying seats for a first tenant, completing the app registration during that client's next scheduled maintenance window, and running the first backup and a test restore the same day. Most MSPs pilot with their own tenant first, which doubles as the test environment for the restore procedure that goes into the client runbook.

If you are new to the Console, sign up at app.duplicati.com, create an organisation for your first client and pick the Microsoft 365 or Google Workspace backup licence. The setup wizard walks through the registration steps above and shows the exact permission set to grant.