Ticketing designed around serving many organisations, not one.
Early accessMSP Ticketing System
Multi-client ticketing built for a provider - client, site and service on every ticket, and a clean line between one customer’s data and another’s.
- Part of CubeMSP
- Serving businesses across the UK
- 01234 672 617
Most ticketing systems were designed for an internal IT department: one organisation, one set of users, one estate. A managed service provider has a fundamentally different shape - many client organisations, each with their own sites, services, contacts and contractual expectations, and a hard requirement that none of them ever sees another. That difference is not cosmetic. It changes the data model, the permissions, the reporting and the search. CubeMSP is built around it: every ticket carries a client, and every query is scoped to a tenant at the data layer rather than by a filter somebody remembered to add.
- No cap
Client organisations, at no per-client charge
- 404
What a cross-tenant request returns
- Every route
Ships with an automated isolation test
What it does
Inside MSP ticketing system
The parts of CubeMSP that make up ticketing. Everything here shares one database, so nothing needs re-keying between them.
Multi-client by design
Client, site and service on every ticket, with reporting that rolls up by any of them. Serving thirty organisations is the normal case here rather than an enterprise edition.
Isolation you can point at
Queries are scoped to the tenant at the data layer. Cross-tenant access returns a 404, and every route ships with an automated test proving it. This is architecture, not a setting.
A taxonomy that fits your desk
Hierarchical categories, priorities and ticket types defined per tenant, in the language your engineers already use rather than a vendor’s idea of a standard.
Assignment and escalation
Reassign, escalate and hand over with the history intact, so the third person to touch a ticket can read what the first two did without asking them.
History that answers questions
Every ticket a client has ever raised, filterable by site, service, category and period. "Has this happened before?" becomes a search rather than a straw poll.
Data that flows onward
Ticket and time data feed the client review, the profitability view and the billing export automatically. Nothing is re-keyed to produce a figure somebody has already recorded.
In practice
Problems this actually solves
Anonymised, but not invented. These are the situations businesses describe to us before they change anything.
A ticketing tool built for one company
The situation
The provider used a well-known helpdesk product designed for internal IT. Clients were modelled as tags, reporting by client meant exporting and pivoting, and one misconfigured view had briefly shown a client somebody else’s ticket titles.
What changed
Client is a first-class part of the record and isolation is enforced at the data layer. Reporting by client is a filter rather than an export, and the near-miss cannot recur by configuration error.
Handovers that lost the thread
The situation
Work passed between first line, second line and a project engineer over email and instant messages. By the third handover, the reason for the original decision had been lost and the diagnosis started again.
What changed
Assignment, escalation and notes all live on the ticket. The current owner reads the record rather than reconstructing it, and the history is available in the review at the end of the quarter.
Billing reconstructed from memory
The situation
Chargeable work was noted on a pad, typed into a spreadsheet at month end and invoiced from that. The gap between hours worked and hours billed was significant and nobody could account for it precisely.
What changed
Time is booked against the ticket at the desk, flagged billable or not, and exported to billing. The gap became visible, then became small.
How it happens
What implementation actually involves
No mystery, no discovery phase that quietly becomes the project. Five stages, and you will know what each one costs before it starts.
Discovery
A structured session mapping how you run now - the PSA you have outgrown, the spreadsheet of renewals, the shared mailbox that is really your ticket queue, and the review deck somebody rebuilds by hand every six months. We come back with what the platform covers as standard and what needs building.
Configuration
Your service catalogue, ticket taxonomy, boards, roles, approval limits and review templates set up to match how you actually work - not a demo tenant with your logo dropped on it. Your categories, not ours.
Data migration
Clients, contacts, sites, services, renewal dates and enough ticket history to make the knowledgebase and similar-incident retrieval useful on day one. An empty AI is a useless AI, so the history matters more here than in most migrations.
Training & rollout
Role-based training - the service desk learns logging and resolution, account managers learn reviews and renewals, directors learn the reporting. We usually pilot with one technician and one client before opening it up.
Ongoing support
UK support from the people who built the platform and use it themselves, with a named contact, agreed response times, and a roadmap you can influence. Being a small vendor is an advantage here and we intend to keep it.
You might call it something else
Ticketing goes by a lot of names - if you searched for any of these, this is the page you wanted.
- MSP ticketing software
- Multi-tenant ticketing system
- IT ticketing system
- Ticket management software
- MSP ticket tracking
- Support ticketing platform
Questions
The things people ask first
There is no per-client limit and no charge per client organisation. The multi-client model is the centre of the design rather than a tier, and firms serving several hundred clients are within the intended range.
No, and we treat that as the single most important property of the system. Scoping happens at the data layer rather than in application filters, cross-tenant access returns a 404, and every route has an automated isolation test that must pass before it ships.
Alerts can raise tickets through the API and webhooks, with the client and site resolved automatically. We would rather integrate with the RMM you have chosen than persuade you to change it.
Yes. A ticket that turns out to be a piece of project work can be linked to the board it belongs to, so the work is visible in both places without being duplicated in either.
Volume, ageing and response performance by client, site, service, category, priority and engineer, plus the same data feeding client service reviews and the profitability view. Scheduled reports arrive by email rather than waiting to be run.
Related
Other things we can put right
Service Desk Software
A real queue instead of a shared mailbox - incidents logged against the client, site and service they affect, with priority, ownership and time.
Read moreIT Service Management Software
Incidents, requests, problems and knowledge handled consistently, with the service catalogue and the client record in the same system.
Read moreMSP Software
One system for clients, services, renewals, incidents, projects and reviews - built in the UK by a managed service provider.
Read moreClient Reporting Software
Branded quarterly and annual service reviews assembled from the period’s real data - every figure computed, then narrated, never estimated.
Read more
Part of a bigger system
Ticketing is one part of CubeMSP. You can start here and switch the rest on later - it is the same system, not a separate purchase bolted on.
Talk to us
Is ticketing your actual problem?
Sometimes it is not. Tell us what is going wrong and we will tell you whether this is the right thing to fix first.