Process that helps, rather than process for its own sake.
Early accessIT Service Management Software
Incidents, requests, problems and knowledge handled consistently, with the service catalogue and the client record in the same system.
- Part of CubeMSP
- Serving businesses across the UK
- 01234 672 617
IT service management is a body of good practice that has, in places, been turned into an industry of its own. CubeMSP takes the parts that demonstrably work - a defined service catalogue, incidents logged against the service they affect, categories that mean something, response targets you actually measure, and knowledge captured at the point of resolution - and leaves the parts that mostly generate meetings. The result is a service desk that is consistent without being ceremonial, and reporting that reflects the work rather than the process wrapped around it.
- Your taxonomy
Categories defined per tenant, not imposed
- Measured
Response and resolution timestamped from the record
- Immutable
Full audit log as standard
What it does
Inside IT service management software
The parts of CubeMSP that make up ITSM. Everything here shares one database, so nothing needs re-keying between them.
A service catalogue that exists
What you supply, to whom, at what level - held as data per client rather than described in a contract nobody opens. Incidents attach to the service, so impact is visible immediately.
Incidents and requests, distinguished
A broken thing and a wanted thing are not the same work, and mixing them makes every metric meaningless. Type, priority and category are set at logging, and your taxonomy is yours to define.
Problems behind incidents
Recurring faults grouped so the underlying cause is visible. Twelve tickets about the same switch is a problem record, not twelve coincidences to be closed individually.
Response targets you measure
Targets by priority and client, measured against what actually happened. A target nobody reports on is a sentence in a contract; a target that appears in the review is a commitment.
Knowledge captured at resolution
The moment of resolution is the only moment anybody knows both the symptom and the fix. Articles are drafted then, from the incident, for a human to approve.
Audit and accountability
Every state change, assignment, note and time entry recorded with who and when. An immutable audit log, included as standard rather than sold as a compliance tier.
In practice
Problems this actually solves
Anonymised, but not invented. These are the situations businesses describe to us before they change anything.
Metrics nobody believed
The situation
Everything was a "ticket", from a forgotten password to a failed migration. Average resolution time was quoted in every review and taken seriously by nobody, because it averaged two unrelated kinds of work.
What changed
Incidents and service requests are now separated at logging, with a category taxonomy the firm defined itself. The numbers in the review changed considerably, and started being discussed rather than skipped.
A recurring fault treated as twelve separate ones
The situation
A client’s branch office dropped connectivity roughly twice a month. Each occurrence was logged, worked and closed by whoever was on the queue, and the pattern was only spotted when the client mentioned it.
What changed
Related incidents are grouped behind a problem record with its own history. The pattern is visible on the client record, and the underlying circuit fault was raised with the carrier on evidence.
A service level nobody could evidence
The situation
The contract promised a four-hour response on priority one. There was no reliable record of when an incident was raised as opposed to when somebody started typing, so the promise was unverifiable in both directions.
What changed
Response is timestamped at logging and first response, measured per priority and client, and reported in the service review. Two clients were moved to a more appropriate tier on the evidence.
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
ITSM goes by a lot of names - if you searched for any of these, this is the page you wanted.
- ITSM software
- IT service management platform
- Service management software
- ITIL software
- IT support management system
- Incident management software
Questions
The things people ask first
No. The structure supports ITIL-style working if you want it - incidents, requests, problems, a service catalogue and knowledge management are all there - but nothing forces a process you have not chosen. Most providers adopt the parts that pay for themselves and ignore the rest.
Yes, and you should. The category taxonomy is per tenant and hierarchical, so it can match the language your engineers already use. We seed a sensible default during configuration and expect you to change it.
Targets are set by priority and can vary by client. Response and resolution are timestamped from the record rather than entered by hand, and performance against target appears on the dashboard and in the client service review.
It can be, but it is built for providers serving multiple client organisations - the multi-tenant client model is the centre of the design. An internal team would find a good deal of the platform aimed at somebody else.
Changes are handled through projects and approvals rather than as a separate change-advisory module. For the size of provider we build for, that is the right level of ceremony. If you need formal CAB workflow, tell us during discovery and we will say plainly if we are not the right fit.
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 moreMSP 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.
Read moreMSP Software
One system for clients, services, renewals, incidents, projects and reviews - built in the UK by a managed service provider.
Read moreKnowledge Base Software
A knowledgebase that builds itself from resolved incidents, with semantic search over your own history and a human approving every article.
Read more
Part of a bigger system
ITSM 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 ITSM 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.