This article is for you if you run an MSP (Managed Service Provider) and handle IT for more than one company. We discuss the architecture of ITSM systems designed for multi-tenant work, the most common mistakes when choosing a tool, and a decision matrix to help you match the solution to the scale of your organization.
1. How ITSM for MSPs differs from corporate ITSM
Most ITSM systems were built for a single organization: one tenant, one set of processes, one SLA, one logo on the portal. That works perfectly in a corporation serving its own employees but does not fit the MSP model.
An MSP manages IT for many independent clients at once. Each of them has different:
- Incident priorities and categories: a manufacturing client reports a line failure, an office client reports problems with Outlook
- SLA contracts: 1h response time for a premium client, 8h for a basic one
- Working hours and maintenance windows: one client works in a 24/7 shift system, another only from 8 to 17
- Billing models: hour packages, retainer, per-incident rate
- Data isolation requirements: a client from the financial sector cannot see data from a retail client
For an MSP what matters is: data isolation, separate client portals, per-client billing and per-client reports, managed from a single panel. Without these elements the team drowns in manual administration instead of handling tickets. You can read more about building a profitable MSP model in the article MSP value model: how to build an offering.
Key difference
Corporate ITSM optimizes one process for one organization. ITSM for MSPs has to handle many independent processes, SLAs and business models at the same time, without administrative chaos.
2. The biggest MSP mistake when choosing a system
We talk to dozens of MSPs and almost always hear the same scenario: a company starts with one or two clients, deploys an ITSM system designed for a single organization (e.g. Jira Service Management, classic GLPI, or the free version of Freshdesk). It works. Then a third client comes in. A fourth. A seventh.
And the era of workarounds begins:
- A separate instance per client: five Jira instances, five separate logins, five separate configurations
- Projects as a multi-tenant simulation: one system, but each client is a separate "project", permissions managed manually
- Excel for billing because the system cannot bill per client
- Manual report filtering: export to CSV, processing, send by email
Warning: simulating multi-tenancy with separate instances or projects is not a scalable solution. As clients keep being added, the time spent on system administration alone grows disproportionately - maintaining several separate instances can eat up as much time as actually handling tickets.
- Separate instances = many logins, many configurations
- No central view of all clients
- Manual per-client SLA management
- No built-in billing: Excel or external tools
- Per-client reports require manual filtering
- Escalations inconsistent across clients
- Onboarding a new client = new system configuration
- One admin panel, full control over all clients
- Data isolation at the architecture level
- SLA configured per client, automatic escalations
- Built-in billing: per-client work time report, export to invoice
- Client portal with its own domain and branding
- Onboarding a new client: a few clicks in the panel
- Integration with Endpoint Central MSP and external RMM via REST API
3. What native multi-tenant means
The term "multi-tenant" is used loosely. Let us be specific about what we mean by native multi-tenant architecture in the ITSM context.
Architecture
In native multi-tenancy a single system stores data for all clients (tenants), but at the database and application logic level full isolation is provided. Client A cannot see client B's data. Not because filters are set well, but because the architecture does not allow it.
What is part of native multi-tenant for MSPs
- Separate client portals: each client has its own site (e.g.
clientA.rotechgroup.eu) with its own logo and branding - One MSP admin panel: from a bird's-eye view you see all clients, open tickets, breaching SLAs, team workload
- Configuration per client: SLA, categories, forms, working hours, escalations, everything defined separately for each tenant
- Billing per client: the system tracks agent work time on specific tickets and assigns the costs to the right client
Jira Organizations vs SDP MSP: a practical difference
Jira Service Management offers an "Organizations" feature that lets you group clients. That is an approach stuck on top of a single-tenant architecture: permission management requires manually built rules at the project level, client portals are shared, and billing does not exist as a native feature.
ManageEngine SDP MSP was built from the ground up with MSP architecture: every tenant is a separated unit, the client portal with its own domain is built in, and the billing module is part of the base platform.
4. ManageEngine SDP MSP: why it dominates this segment
ManageEngine ServiceDesk Plus MSP (SDP MSP) is a dedicated platform for managed IT service providers. Its advantage is not marketing - it comes from architecture.
Native MSP architecture
One system, many tenants: data isolation at the architecture level, not filters.
Built-in billing
Per-client work time tracking, generation of billing reports, PDF export.
Client portal with a domain
Each client has its own portal under its own subdomain with logo and branding.
RMM integrations
Native integration with Endpoint Central MSP: monitoring alerts create tickets automatically. Integration with other RMM systems is available via REST API.
Per-client reports
Ready report templates: SLA compliance, response time, agent workload, per client.
One admin panel
Full overview of all tenants in one place, no jumping between logins.
SDP MSP also integrates with the wider ManageEngine ecosystem (OpManager, Endpoint Central, ADAudit Plus), which makes it possible to build a complete IT management stack without integrating third-party tools.
5. How many clients you can handle before the system starts slowing you down
The answer depends on the tool's architecture, not its name. Below is a matrix based on the number of actively served MSP clients:
Starting MSP
At this stage almost any tool works, workarounds are still manageable. The priority is simplicity and low cost.
Growing MSP
This is where workarounds start to hurt. Administration eats up hours. Native multi-tenant is mandatory, otherwise operating costs quickly eat into the margin.
Mature MSP
At this level the lack of a native MSP platform is a brake on growth. Automation, advanced billing and RMM integrations are required.
Important rule
Migrating the system at 15 clients is 3x harder than at 5. The earlier you pick a scalable platform, the less migration pain. Plan the architecture for the next 3 years, not just for today.
6. SLA per client: how to configure it correctly
SLA (Service Level Agreement) is the operational contract with the client. If your system cannot enforce separate SLAs per client, your team will track priorities manually, which leads to mistakes and tension with clients.
What should be configured separately per client
Premium client: 1h response, 8h resolution. Basic client: 8h response, 48h resolution.
24/7 client: SLA runs around the clock. Office client: SLA active 8:00-17:00, Mon-Fri.
Escalation to a manager after 80% of the SLA time. A different escalation contact for each client.
Manufacturing client: "line failure" = critical. Office client: no such category.
A weekly SLA compliance report sent automatically to the designated contact at the client.
SLA does not tick during planned maintenance breaks, defined per client.
In a native MSP system (such as SDP MSP), the above settings are separate profiles per tenant. In systems with workarounds these are manually maintained rules that are easy to forget to update when a client's contract changes.
7. Billing and reporting for clients
For an MSP, accountability of work is the foundation of profitability. The ITSM system should be both an operational tool and a source of data for invoicing.
What the system should do in terms of billing
Agents log time on tickets. The system sums it per client, per agent, per project.
Client A: 150 PLN/h. Client B: 200 PLN/h for out-of-hours work. Configured in the panel.
Ready printout with a list of tickets, work time, total cost, branded with the MSP logo.
Client bought 40h/month. The system shows usage in real time, alert at 80%.
Monthly archive with the ability to compare: how much work each client generates over time.
CSV or PDF with data ready to be transcribed onto an invoice or imported into the finance system.
MSP with several clients: migrating from separate Jira instances to SDP MSP
Consider a typical situation: an IT company managing the infrastructure of several clients runs on several separate Jira Service Management instances. Each client is a separate subscription, a separate configuration and a separate login for the agents.
Typical issues: every morning agents check many different panels, billing is done manually in Excel, there is no central view of team workload, prioritization of tickets across clients is impossible.
After migration to a platform with native multi-tenancy (e.g. SDP MSP): one panel, automatic per-client SLA, built-in billing, reports generated with a single click. The main benefit is a clear reduction in administrative time - the larger, the more clients the MSP serves.
8. Matrix: which system for which MSP size
| MSP scale | System recommendation | Multi-tenant | Built-in billing | Why |
|---|---|---|---|---|
| 1-5 clients | Freshdesk, Zammad, Jira JSM Starter | Limited | No | Low cost, simple administration. Plan migration as you grow. |
| 5-15 clients | ManageEngine SDP MSP | Native | Yes | Native MSP architecture, billing, client portals with their own domain. |
| 15-50 clients | ManageEngine SDP MSP | Native | Yes | Critical automation, RMM integrations, advanced SLA. |
| 50+ clients | SDP MSP Enterprise or PSA + ITSM | Native | Yes | Advanced PSA (Professional Services Automation) or integration with ConnectWise Manage required. |
| Jira JSM (all sizes) | Workaround via Organizations | Not native | No | Requires manually maintained permissions per project, no billing, no data isolation. |
| Oxari | MSP up to about 10 clients | Partial | Limited | Polish tool with multi-tenant option. Focus on enterprise, public sector and hospitals. MSP capabilities should be verified directly with the vendor (Infonet Projekt SA). |
Jira Service Management works well for internal IT departments or an MSP serving one large client. However, it does not have native multi-tenant architecture. As you scale to many clients the administrative costs grow quickly. If you are looking for tools for the whole MSP stack, read ManageEngine vs NinjaOne for MSPs.
9. FAQ: frequently asked questions
ManageEngine ServiceDesk Plus MSP (SDP MSP) is a separate ManageEngine product dedicated to managed service providers (MSPs). The main difference from the standard ServiceDesk Plus is the native multi-tenant architecture: a single system serves many clients with full data isolation, separate client portals (with their own domains), configurable per-client SLAs and a built-in billing module. Standard SDP is optimized for one organization: an internal help desk. SDP MSP is optimized for serving many independent clients managed from a single panel.
ManageEngine SDP MSP is licensed per technician (agent), not per client. This means you can add new clients without additional license costs - you pay for the number of agents handling tickets. The specific price depends on the number of agents, the chosen plan and any additional modules. Contact a partner for the current price list. As a certified ManageEngine partner, Rotech Group can provide a quote and a demo environment.
Jira Service Management is a great tool but was not designed for MSPs managing many clients at the same time. The "Organizations" feature allows some grouping of clients but it is not native multi-tenant architecture: no full data isolation, no built-in billing, no separate client portals with their own domain. In practice MSPs on Jira build workarounds (separate projects or instances) that work well up to about 5 clients. Beyond that, administrative costs grow noticeably. Jira does work very well when an MSP serves a single large client and wants to offer them a system with strong Atlassian integrations (Confluence, Bitbucket).
The migration usually runs in four stages: (1) Audit of the current structure: catalog of clients, their SLAs, incident categories, billing models. (2) Configuration of tenants in SDP MSP: creating client profiles, portals, SLAs and categories. (3) Migration of ticket history (optional, via API or CSV import). (4) Agent training and switching active clients over. With good preparation, migrating 5-10 clients can take 2-4 weeks. Rotech Group runs projects like this. Contact us for a free initial consultation.
ManageEngine SDP MSP natively integrates with Endpoint Central MSP: monitoring and device management alerts automatically create tickets in SDP MSP assigned to the right tenant (client). You do not waste time manually rewriting alerts - the system processes and prioritizes them according to the client's SLA. Integration with other RMM systems (NinjaRMM, ConnectWise Automate, etc.) is available via REST API.
Want to assess whether your MSP is ready for native multi-tenant?
We will run a free review of your current ITSM stack and show you where you lose time on administration.
Book a free consultationRelated articles
ManageEngine ServiceDesk Plus: pricing and quote What is RMM: guide to Remote Monitoring ManageEngine CVE and security: what you should know ERP integration with the help desk: how to do itLooking for an ITSM solution for your MSP? See what an implementation with Rotech Group looks like →