Built by an MSP, for the firm that has outgrown the spreadsheet and cannot justify a tier-one PSA.

Early access

CubeMSP for managed service providers

The core case: recurring support contracts, a shared service desk, project work alongside the day job, and a review meeting every quarter.

Book a walkthroughSee the platform

A managed service provider is one of the harder businesses to run on general-purpose software, because almost nothing about it is general-purpose. You serve many client organisations that must never see each other. Your revenue is recurring but your cost base is reactive. The most valuable thing you own is knowledge that lives in people’s heads. And the meeting that renews the contract depends on evidence you gathered incidentally over three months. CubeMSP is shaped around all four of those facts, because the people who built it run into them every week.

  • 5-50

    Technicians - the range this is built for

  • 2003

    The MSP that builds it has run since then

  • One model

    Clients, services, tickets, projects, reviews

What goes wrong

The recurring problems in MSPs

Not every business has all five. Almost every business we speak to has three.

  • The shared mailbox that became a queue

    Support arrives at an address, rules sort it into folders, and whoever is free picks it up. It works up to a point and then quietly stops producing any information about the business at all.

  • Renewals in a workbook

    Licences, circuits and contracts tracked in a spreadsheet maintained by one person. It is accurate when they update it, and the year one renewal auto-rolls at old pricing is the year it becomes a board matter.

  • Margin that nobody can locate

    Fixed monthly fees against reactive effort. Without time booked against the work it was spent on, the clients subsidising the rest of the book stay invisible for years.

  • Knowledge with legs

    The senior engineer knows every client’s quirks. When they leave, three previously solved problems get solved again from first principles, and one client notices.

  • The review that slips

    Quarterly reviews are promised in the contract and prepared by hand. In a busy year some of them simply do not happen, which is noticed at renewal rather than at the time.

What we do about it

How CubeMSP is set up for MSPs

Configuration, not a separate edition. Everything here is in the same product - it is switched on and shaped during implementation.

  • Many clients, isolated properly

    Client is a first-class part of every record, and scoping happens at the data layer rather than in a filter. Cross-tenant access returns a 404 and every route has a test proving it.

  • The recurring book as data

    Every service you supply, per client, with quantity, cost, sell price, term and renewal date. Recurring revenue and its margin become a query rather than an afternoon.

  • A desk that produces information

    Incidents against a client, site, service and category, with priority, ownership and time. Volume, ageing and response performance fall out of doing the work rather than being measured separately.

  • Knowledge captured at resolution

    Resolved incidents drafted into knowledgebase articles for approval, and semantic retrieval that shows the technician who has solved this before. Experience stops walking out of the door.

  • Projects the client can watch

    Shared boards for migrations and onboardings, with internal-only tasks filtered on the server. The Friday status email stops being necessary.

  • Reviews that assemble themselves

    Branded quarterly reviews composed from the period’s real data and narrated by AI around computed figures, then approved by a person before anyone sees them.

In practice

Two situations from this sector

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

  • A fourteen-person MSP running on four tools

    The situation

    A CRM held clients, a helpdesk held tickets, a project tool held migrations and a spreadsheet held renewals. All four disagreed about which clients were active, and reporting on any client meant three exports and a pivot table.

    What changed

    One client record with services, incidents and projects attached. Three subscriptions cancelled, the weekly argument about which list was right stopped, and the quarterly review became a twenty-minute review rather than a day of preparation.

  • A provider that lost a ten-year account

    The situation

    A long-standing client gave notice at renewal. The warning signs - incident volume up by half, two escalations, two skipped reviews - had all been present, but in three different systems.

    What changed

    Incident trend, response performance, review history and renewal date now sit on one screen. Renewal conversations start two months out, from evidence rather than from an impression.

How it happens

What implementation involves

The same five stages whatever you make. Discovery, training and go-live are done on your site, because most of what the system needs to know is learned in the building.

  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.

Questions

What this sector asks first

  • Five to fifty technicians is the range we design for. Below five, a spreadsheet and a good mailbox may still be adequate, and we will say so. Above fifty, you may need formal change management and resource levelling that we do not currently offer.

  • No. CubeMSP is the business layer - clients, services, renewals, incidents, projects, knowledge and reviews. Your RMM handles monitoring, patching and remote access, and talks to CubeMSP through the API.

  • Yes. Crushed Ice has been running as an MSP since 2003 and is the first tenant on the platform. That is the reason several of the less obvious features exist.

  • Six to twelve weeks for a typical provider of ten to thirty people: discovery, configuration, data migration, training and a supported cutover. Ticket history migration is the part worth not rushing, because the knowledgebase depends on it.

  • Clients, contacts, sites, services, renewal dates and ticket history all migrate. You reconcile against the old system, and we cut over once the numbers agree rather than on a date somebody picked in advance.

Where to start

The parts that usually matter most here

Related

Sectors with similar problems

If your process really is unusual

Some requirements are specific to one business rather than one sector. Those get built against the same documented API everybody else uses - not bolted on to the side of a database nobody is allowed to look at.

How the platform is built

MSPs

Show us a real job from your MSPs operation

Bring one order that went wrong and the paperwork that went with it. That tells us more about whether this fits than any list of features.

Start a conversationCall 01234 672 617