The difference between answering support and running a service desk.

Early access

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.

Book a walkthroughAbout CubeMSP

Almost every managed service provider starts with a shared mailbox and rules. It works until it does not, and the failure is rarely dramatic - it is a slow loss of visibility. Nobody can say how many incidents a client raised last quarter, who has the most open work, which faults keep coming back, or how long anything actually took. Service desk software fixes that by making the incident a record rather than a message: attached to a client, a site and a service, owned by somebody, prioritised, timed, and closed with a resolution that can be found again. CubeMSP does that without turning the desk into an exercise in form-filling, because a desk that is unpleasant to use quietly stops being used.

  • Owned

    Every incident has a state and a named owner

  • At logging

    Similar past incidents surfaced before work starts

  • Server-side

    Internal note visibility enforced

What it does

Inside service desk software

The parts of CubeMSP that make up service desk. Everything here shares one database, so nothing needs re-keying between them.

  • One queue, properly owned

    Every incident has a state, a priority and a named owner. Unassigned work is visible as unassigned work rather than sitting in a folder that everybody assumes somebody else is watching.

  • Linked to what it affects

    An incident attaches to a client, a site, a service and a category. That is what makes "this keeps happening to this firewall" a query rather than a memory.

  • Time booked as it happens

    Time entries against the incident, marked billable or not. Booked at the desk while the detail is fresh, rather than reconstructed on the last Friday of the month.

  • Internal and client-visible notes

    Two kinds of note on the same record, with visibility enforced on the server. The client sees progress; your engineers keep the conversation they need to have with each other.

  • Similar incidents surfaced automatically

    Semantic search over your own resolved history shows the technician the three closest previous incidents and what fixed them - before an hour is spent rediscovering it.

  • Load you can see

    Open work by engineer, by client and by priority, with ageing. Who is drowning and who is not becomes visible on a Tuesday rather than at the exit interview.

In practice

Problems this actually solves

Anonymised, but not invented. These are the situations businesses describe to us before they change anything.

  • The mailbox that had become a queue

    The situation

    Support arrived at a shared inbox with folders for each state. Two engineers occasionally worked the same issue, urgent items were sometimes read after the reply-all, and nobody could produce a quarterly figure for anything.

    What changed

    Incidents are records with owners and states. Duplicate effort stopped, priority is set at logging rather than inferred from the subject line, and the quarterly figures are produced by the system.

  • An engineer permanently underwater

    The situation

    One technician handled the awkward clients because he always had. There was no view of load, so nobody realised he was carrying two-thirds of the open work until he handed in his notice.

    What changed

    Open work by engineer with ageing is on the dashboard. Load is now redistributed weekly, and the imbalance is a conversation rather than a discovery.

  • Fixes rediscovered every few months

    The situation

    A specific line-of-business application broke in the same way roughly quarterly. Each time it took two or three hours to work out, because the last person to fix it had described it in an email nobody could find.

    What changed

    Similar-incident retrieval now surfaces the previous occurrences at logging, and the resolution has been promoted to a knowledgebase article. The same fault is now a fifteen-minute job.

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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

Service desk goes by a lot of names - if you searched for any of these, this is the page you wanted.

  • IT service desk software
  • Help desk software
  • MSP help desk
  • Support desk system
  • IT helpdesk software
  • Service desk platform

Questions

The things people ask first

  • Yes. Inbound email creates or updates an incident, and replies thread onto the record rather than starting a new one. The mailbox can stay as the client-facing address while the queue lives in the system.

  • Client users can be invited to shared project boards and to their own service reviews without a per-seat charge. A full self-service incident portal is on the roadmap rather than in the product today - we would rather say so than imply otherwise.

  • Visibility is a property of the note and it is filtered on the server, before the data leaves the API. It is not a display rule in the interface, because display rules are one bad query away from being wrong.

  • Yes. Priorities, categories and response targets are all configured per tenant during implementation, and can be changed afterwards without involving us.

  • It is migrated. This matters more than it usually would, because the similar-incident retrieval and the knowledgebase are only as good as the history behind them. An empty system is a system that helps nobody in week one.

Related

Other things we can put right

Part of a bigger system

Service desk 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.

Explore the platform

Talk to us

Is service desk 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.

Start a conversationCall 01234 672 617