Solutions · Managed service providers
Build the service.
Own the customer relationship.
Office Unbound is being designed so a managed service provider can deliver email, documents, files, chat and meetings to many customers from infrastructure it chooses — provisioning them, isolating them, administering them and migrating them, under its own service.
Project status MSP capabilities are planned for the MSP and enterprise phase of the roadmap. Nothing on this page is available yet, and no provider is operating Office Unbound for customers today.
The position most MSPs are in
Supporting a platform you do not control.
For many managed service providers, productivity services mean reselling Microsoft 365 or Google Workspace licenses and supporting them. That arrangement works and is well understood. It also sets hard limits on the business. The platform, its release schedule, its admin console and its license terms belong to the vendor. The provider’s value sits in the support and the relationship, while the product itself is identical to what the customer could buy from anyone else — including the vendor directly.
When a customer asks for something the platform does not do, the answer is no. When an outage affects every tenant at once, the provider waits along with its customers. When licensing changes, the provider explains it and absorbs the consequences.
Office Unbound is intended to give MSPs a different option: an open-source platform they operate themselves, on infrastructure they choose, with management tooling built for serving many customers rather than retrofitted onto a single-organization product. The provider decides the deployment architecture, the service levels it offers, the maintenance windows and the shape of each customer’s service. In return, it carries the operational responsibility that the cloud vendor carries today.
One management layer, many isolated customers
The intended model: MSP staff work through a single management layer; each customer is a separate tenant with its own domains, users, policies and data, and optionally its own delegated administrator. The same layer exposes a management API for the provider’s own systems.
Planned MSP capabilities
What the multi-tenant management layer is being designed to provide. These depend on the core services being built first, so all of them are planned.
- Available Available and verified in a release
- In development Being built now
- Planned In the roadmap, not yet started
- Under evaluation Being assessed; not yet selected
| Capability | What it means | Status |
|---|---|---|
| Multi-customer provisioning | Create a customer tenant with its domains, services and limits from one place, repeatably. | Planned |
| Tenant management | Suspend, resize, reconfigure and eventually decommission customer tenants. | Planned |
| Customer administrative delegation | Give a customer’s own IT contact administration of their tenant only, with limits the MSP sets. | Planned |
| User provisioning and lifecycle | Onboard, change and offboard users, including mailbox and file handling when someone leaves. | Planned |
| Group administration | Groups, distribution lists and team memberships per customer. | Planned |
| Service assignment | Choose which workloads each customer, and each user, receives. | Planned |
| Mailbox management | Shared mailboxes, aliases, forwarding, delegation and quotas. | Planned |
| Storage management | Storage allocation and usage per customer and per user. | Planned |
| Customer security policies | Per-customer authentication, MFA, session and sharing policies. | Planned |
| Customer-specific domains | Several domains per customer, with the DNS records each one needs. | Planned |
| Administrative roles and technician permissions | Role-based access for MSP staff, scoped to particular customers and tasks. | Planned |
| Resource quotas | Limits on users, storage and services that match what each customer has bought. | Planned |
| Central monitoring and service health | One view of the health of every customer’s services and the infrastructure under them. | Planned |
| Patch management | Staged, scheduled updates with MSP-controlled update policies. | Planned |
| Backup management | Backup status and restore operations across customers. | Planned |
| Migration project management | Assessment and migration projects per customer, tracked centrally. | Planned |
| Reporting and audit logs | Per-customer reports, and an audit trail of administrative actions by MSP and customer staff. | Planned |
| API access | A management and provisioning API covering the operations above. | Planned |
| Integration with MSP systems | Connection to PSA, RMM and documentation platforms, starting with clientst0r. | Planned |
Tenant isolation and delegation
The property every other MSP feature depends on.
A multi-tenant platform is only as good as the boundaries between its tenants. One customer must never see another’s mail, files, users or audit records, and a customer administrator must not be able to reach outside their own tenant however a request is constructed. Office Unbound is being designed with tenant-specific authorization throughout, so that the tenant is checked on every administrative and data operation rather than assumed from the session. Cross-tenant security testing is part of the planned verification practice, not an afterthought.
On top of that boundary sit the roles an MSP actually needs:
- MSP administrator
- Creates and configures customer tenants, sets service plans and quotas, manages technician access, and controls update and backup policy across the platform.
- MSP technician
- Works within the customers and tasks they are assigned — for example user changes and mailbox issues for a set of customers — without platform-wide rights.
- Customer administrator
- A delegated role inside one tenant, for customers with their own IT contact: add users, reset MFA, manage groups, within limits the MSP defines.
- End user
- Uses the services. Sees nothing of the tenant structure or the provider’s tooling.
Every action at every level is intended to be written to an audit log that records who acted, on which tenant, and what changed — so that when a customer asks what their provider did, there is an answer.
Packaging it as a service
Office Unbound is software, not a price list. How a provider turns it into services is the provider’s decision; the platform’s job is to make each of these practical to deliver. The examples below are illustrations of service shapes, not offerings that exist.
Hosted productivity
Mail, calendars, documents, files, chat and meetings for each customer, on infrastructure the MSP operates, billed per user or per tenant on terms the MSP sets.
Migration projects
A defined engagement: assessment report, migration plan, pilot, staged transfer and cutover, priced and scoped from the assessment rather than guessed.
Dedicated deployments
A separate installation for a customer that wants its own infrastructure — in its own premises or a dedicated environment — still administered by the MSP.
Co-managed service
The MSP runs the platform; the customer’s IT staff handle users and day-to-day changes through the delegated administrator role.
What the platform is meant to make repeatable
Selling a service only works if delivering it is predictable. The design goal is that a new customer tenant is provisioned the same way every time, from a defined service plan, with its quotas, policies and domains set by template rather than by hand. Deployments on the initial target — Linux virtual machines on Proxmox VE — are intended to be reproducible, so that an MSP can build a second cluster, or a dedicated customer environment, from the same documented configuration as the first.
What the provider controls
- Deployment architecture and where customer data is held
- Service plans, quotas and what each customer receives
- Maintenance windows and update approval
- Security policy defaults per customer
- Support processes and escalation
- Operational workflows and tooling
Migration across your customer base
Assess every customer before you quote a single one.
Most of an MSP’s future Office Unbound customers will arrive from Microsoft 365 or Google Workspace. The planned Migration Assessment & Readiness Engine is being designed with that in mind. For each customer, it connects with authorized, least-privilege access, inventories users, mailboxes, storage and collaboration workloads, and reports what will move, what needs conversion and what will not move at all — before any data is transferred.
For a provider, the value is in running that across many customers at once, with each assessment kept inside its own customer’s boundary.
Separate assessments per customer
Each customer authorizes its own source tenant; credentials, inventory and reports stay within that customer’s project.
Compare complexity
Data volumes, unsupported workloads, identity mapping issues and blocking items side by side, to decide which customers move first.
Customer-facing reports
PDF and CSV reports written for the customer’s management as well as its IT staff, with assumptions and uncertainty stated.
Plan resources
Estimated transfer time, bandwidth, storage and infrastructure per project, to schedule technicians and capacity.
Track centrally, isolated per tenant
One view of every migration’s status for the MSP; each customer sees only its own.
Planned capability. Moving from assessment to migration requires explicit administrator approval.
Provisioning API and clientst0r integration
Office Unbound intends to provide management and provisioning APIs that MSP platforms can call, so that work started in a PSA or documentation system — a new customer, a new starter, a leaver — is carried out in the platform without a technician re-keying it. clientst0r is the first planned integration. The actions below are the intended scope; none is functional yet, and the API itself has not been designed in detail.
| Action | What it is intended to do | Status |
|---|---|---|
| Customer creation | Create a tenant from a service plan, with its initial domains, quotas and policies. | Planned |
| User onboarding | Create an account, assign services and groups, and start authentication enrollment. | Planned |
| User offboarding | Disable sign-in, end sessions, and hand over or retain mailbox and files according to policy. | Planned |
| Service provisioning | Enable or remove a workload — mail, files, chat, meetings — for a customer or user. | Planned |
| Mailbox administration | Shared mailboxes, aliases, forwarding, delegation and mailbox quotas. | Planned |
| Group configuration | Create groups and distribution lists and manage their membership. | Planned |
| Storage quotas | Read and set storage limits for a customer and its users. | Planned |
| Domain settings | Add a domain and retrieve the DNS records it needs, and report their verification state. | Planned |
| Customer policy management | Apply authentication, sharing and retention policies to a tenant. | Planned |
| Migration status reporting | Report assessment and migration progress per customer project. | Planned |
| Service health retrieval | Return the health of a customer’s services for display in the MSP’s own tools. | Planned |
The API is intended to be documented publicly and usable by any MSP platform, not only clientst0r. Authentication, scoping of API credentials to particular customers, and auditing of API calls are part of the design work. Developers can read more on the developers page.
The commercial case, stated carefully
What changes when you run the platform instead of reselling it.
Office Unbound is intended to let MSPs:
Differentiate
Offer a managed service that is genuinely the provider’s own, rather than the same license every competitor sells.
Build recurring hosting
Develop hosting offerings on infrastructure the provider operates, with service plans it designs.
Control the architecture
Choose hardware, data location, redundancy and network design per customer or per cluster.
Customize delivery
Tailor services, policies and support to individual customers, including dedicated environments.
Own the workflows
Run provisioning, change, updates and backups through the provider’s own processes and tools.
Reduce single-vendor dependence
Rely less on one upstream licensing ecosystem whose terms the provider cannot negotiate.
No margins, savings percentages or pricing are stated here, because none can be supported yet. Whether an Office Unbound service is profitable for a given provider depends on its infrastructure costs, staffing, support model, customer mix and the licensing of any commercial components it chooses to use — some candidate components have commercial editions or terms that need review. Running the platform also moves real work to the provider: capacity planning, monitoring, security maintenance, backups and incident response that a cloud vendor handles today.
Questions MSPs ask
Can we start offering this to customers now?
No. The project is in its first phase, architecture and evaluation. The core services come first, and the multi-tenant management layer is in the MSP and enterprise phase of the roadmap. Registering interest now lets your requirements shape that phase.
Will customers see our brand or Office Unbound’s?
Branding options for providers have not been decided. They depend partly on the licensing and branding terms of the open-source components finally selected, which are under review.
How are customers kept apart?
Each customer is a separate tenant with tenant-specific authorization on every operation, separate administrative boundaries and resource separation. Dedicated deployments are also intended for customers who want their own infrastructure. Isolation will be tested, and the testing approach documented, before any claim about it is made.
Who controls updates?
The provider. MSP-controlled update policies, staging and maintenance windows are planned, alongside security advisories and an emergency patch path — with clear guidance that delaying critical security patches carries real risk to your customers.
Do we need Proxmox VE?
Linux virtual machines on Proxmox VE are the initial deployment target, so that is where documentation and testing will start. Other environments may follow; none is committed to yet.
Does it work with clientst0r today?
No. clientst0r integration through the planned management API is on the roadmap. No integration exists yet.
Is there a partner program or reseller pricing?
Not yet. Any commercial arrangements for providers will be announced on the project updates page when they exist.
Running a managed services business?
Tell us how many customers you support, what they run today and which tools you use to manage them. MSP requirements will shape the multi-tenant management layer and the provisioning API.