The system that makes the move from break-fix to managed service visible rather than aspirational.

Early access

CubeMSP for IT support companies

For firms whose revenue is still largely break-fix and blocks of hours, and who want to move towards recurring contracts without losing the work they already do.

Book a walkthroughSee the platform

Plenty of good IT support businesses have never made the transition to a fully managed model, and not because they do not want to. The transition is hard to see: you cannot tell whether a fixed-fee contract would be profitable until you know what reactive support actually costs, and you cannot know that without recording it. CubeMSP makes the reactive work measurable first - incidents against clients, time against incidents - so the recurring proposition can be built on figures rather than on hope, and so blocks of hours, ad-hoc work and contracts can coexist while the mix shifts.

  • Billable

    Flagged at the desk, not reconstructed

  • Per client

    Real consumption, before you price a contract

  • Both models

    Ad-hoc and recurring, side by side

What goes wrong

The recurring problems in IT support

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

  • Chargeable work that never gets charged

    Ad-hoc work agreed on the phone, done, and remembered at invoicing time - or not. The write-off line is significant and nobody can explain where it came from.

  • Blocks of hours tracked by hand

    Prepaid blocks drawn down in a spreadsheet, reconciled monthly, and occasionally exhausted without anybody noticing until the client queries an invoice.

  • No basis for a fixed fee

    Moving a client to a monthly contract requires knowing what they consume. Without recorded time against recorded incidents, the first fixed fee is a guess, and guesses in this direction are usually low.

  • Reactive scheduling

    The day is set by whoever rings first. Planned work is displaced by urgent work indefinitely, and the improvement projects that would reduce the urgent work never start.

  • Client history in an inbox

    What was done for a client last year exists as email. Answering "have we seen this before?" depends on the memory of whoever happens to be in the room.

What we do about it

How CubeMSP is set up for IT support

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

  • Time captured at the desk

    Booked against the incident while the detail is fresh, flagged billable or not. The gap between hours worked and hours billed becomes visible, and then becomes small.

  • Blocks, contracts and ad-hoc together

    Prepaid hours, recurring agreements and chargeable one-off work held on the same client without forcing every client onto the same commercial model.

  • Real cost before the fixed fee

    What a client actually consumes, measured over a quarter. The managed-service proposal is then built from the figure rather than from an optimistic estimate.

  • History that answers questions

    Every incident a client has ever raised, filterable by site, service and category. "Have we seen this before?" becomes a search rather than a memory test.

  • Planned work that survives

    Project boards keep improvement work visible alongside the queue, so the thing that would reduce next quarter’s reactive load is not permanently displaced by this quarter’s.

  • Billing data without reconstruction

    Billable time and out-of-contract work exported to your finance system at month end, from what was recorded rather than from what can be remembered.

In practice

Two situations from this sector

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

  • A firm that could not price a contract

    The situation

    Three clients had asked about a fixed monthly fee. The business wanted the recurring revenue but had no reliable way to say what any of them consumed, so the proposals kept being deferred.

    What changed

    One quarter of recorded time against incidents produced real consumption figures. Two clients moved to contracts priced on evidence; the third turned out to be far heavier than expected and was priced accordingly rather than accidentally.

  • Blocks of hours that ran out unnoticed

    The situation

    Prepaid blocks were drawn down in a shared workbook updated when somebody remembered. Two clients went significantly over without being told, and the resulting invoices were both awkward and partly written off.

    What changed

    Consumption is tracked as time is booked, with alerts as a block approaches exhaustion. The top-up conversation now happens before the overrun rather than after the invoice.

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

  • Not usually. Most of what makes the transition possible - incidents, time, clients, history - is exactly what a break-fix business needs anyway. The recurring service and renewal modules simply sit unused until you need them.

  • Yes, and most providers in this position do for a couple of years. Commercial model is a property of the client rather than of the system, so there is no need to convert everybody at once.

  • Yes. Blocks are held per client and drawn down as billable time is booked, with alerts as the balance runs low.

  • They will if it takes seconds and happens where the work does. Time entries live on the incident rather than in a separate timesheet application, which is the single biggest determinant of whether time recording survives its first month.

  • Then you have a service desk that produces reliable information about a business that previously produced none, which is worth having on its own terms. Nothing in the platform requires a recurring model.

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

IT support

Show us a real job from your IT support 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