Use cases · Multi-client IT
Multi-client ITManaged service providers
Run every client from one platform. One place to work, a hard wall between clients, and one report per client at month end.
How IT usually works in this setting
An IT provider supports a dozen organisations, each of which wants to feel like your only client. Running one system per client multiplies cost and admin; running one shared system without isolation is a breach waiting to happen.
What it costs you today
- One instance per client means one upgrade, one backup and one bill per client.
- A single shared board that every technician can see is a confidentiality problem.
- Month-end reporting is hand-assembled from several systems.
- Onboarding a new client takes days of setup before the first ticket.
What the desk does about it
- One platform, one wall per client — Clients are tenants on a single platform. Your technicians see what their role allows and nothing else — including when they work two clients in one day.
- The same service, documented — A service catalogue and knowledge base per client, with the articles and runbooks a new technician needs on day one.
- A new client in an afternoon — Clone the structure, import the users and assets, and the client has a desk with their own name, their own portal and their own reporting.
- Prove the wall on request — Sit a prospect down, sign in as one client, try to reach another client's data, and let the platform answer the isolation question for you.
“Two clients, one new starter”
The new client wants a portal, a service catalogue and asset tracking this week.
What we show you, in order
A 12-client provider onboarding a new customer
- Create the tenant, set its hours, categories and SLAs from your standard template.
- Import 15 users and 30 assets from their spreadsheet.
- Give the client's own IT contact an administrator role scoped to that tenant only.
- Raise a test request through their portal and watch it triage, assign and resolve.
- Sign in as a neighbouring client and confirm the new client's records are not reachable.
Why it lands
A working, branded, isolated desk for the new client, and a demonstration of isolation you can reuse in every sales conversation afterwards.
What we can stand behind
- Unlimited end users — you are not billed per head for your clients' staff.
- One technician account can hold roles in more than one tenant without those tenants seeing each other.
- Per-client reporting from the same data model, so month-end is an export and not a rebuild.
- No lock-in: your clients' records export in full, in an open format, whenever they ask.
What we would need from you
- Your standard service catalogue, categories and SLA matrix — we templatise it once.
- A list of your clients and who at each one administers their own desk.
- One live client to migrate first, so the pattern is proven before the rest follow.
- Your branding assets if each client wants their own portal look.
What every one of these has in common.
The configuration changes by sector. The platform underneath it does not: one record per request, service levels per team, and tenancy enforced on the server.
One request, everything attached to it
The same data model behind all eight situations — which is why a sector change is a configuration change rather than a new product.