The recurring book that is too detailed for a spreadsheet and too valuable to get wrong.

Early access

CubeMSP for telecoms & unified comms providers

For resellers of lines, circuits, SIP and hosted telephony: hundreds of small recurring lines per client, each with its own term and renewal date.

Book a walkthroughSee the platform

Telecoms resale has a shape that breaks most business systems: a single client might have ninety recurring lines - handsets, extensions, DDI ranges, SIP channels, broadband circuits, mobile connections and a hosted platform fee - each with a quantity, a wholesale cost, a retail price and a contract end date, and all of them moving. The margin on each is small and the total is significant, which means the errors that matter are the quiet ones. CubeMSP treats the recurring book as structured data with cost and sell on every line, so a carrier price change or an approaching cease date is a query rather than a discovery.

  • Line level

    Every handset, channel and circuit

  • Before it closes

    Alerts on the notice window

  • One operation

    Assess a carrier rise across the base

What goes wrong

The recurring problems in telecoms

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

  • Hundreds of lines per client

    Handsets, DDIs, channels, circuits and mobiles at line level. A spreadsheet copes until a client has ninety rows and three of them change every month.

  • Cease dates and notice periods

    Circuits with thirty-day notice on a twelve-month term, ceased late because the date was in a workbook. The extra month is small; the annual total is not.

  • Wholesale prices that move

    Carrier pricing changes and retail pricing does not. On thin margins, a small increase applied silently across a large base turns a profitable product into a loss-making one without a single alarming number appearing anywhere.

  • Provisioning as project work

    A new site install is a sequence of dependent tasks across several suppliers with dates that slip. Run over email, it produces exactly the customer experience that loses the next order.

  • Faults with no service context

    A fault logged against "the client" rather than against the circuit or the extension it concerns makes recurring faults invisible and carrier escalation harder to evidence.

What we do about it

How CubeMSP is set up for telecoms

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

  • Line-level service records

    Every handset, channel, circuit and connection as its own record with quantity, cost, sell, term and renewal date. Ninety lines per client is the normal case rather than the difficult one.

  • Cease dates and notice windows

    Term, notice period and auto-renewal held per line, with alerts before the notice window closes rather than after it has passed.

  • Margin per line, at scale

    Cost and sell on the same record, so a carrier increase can be assessed against every affected line and every affected client in a single operation.

  • Provisioning as a board

    Installs and number ports as templated boards with dependencies and dates, shared with the client so the slipping supplier date is visible rather than explained.

  • Faults against the service

    Incidents logged against the specific circuit or extension, so a recurring fault on one line is visible as a pattern and can be evidenced to the carrier.

  • Reviews that show the estate

    Client reviews that set out what is supplied, what it cost, what faults occurred and what is renewing - the conversation most telecoms clients have never actually been offered.

In practice

Two situations from this sector

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

  • A carrier increase absorbed for a year

    The situation

    A wholesale connectivity price rose by a small amount per circuit. Retail pricing was held in a separate list and never adjusted. The erosion was found eleven months later during an unrelated review.

    What changed

    Cost and sell sit on the same line. The next carrier change was assessed across the whole base in one operation, and the lines that fell below the margin threshold were repriced at their next renewal.

  • Circuits ceased a month late, repeatedly

    The situation

    Cease notices depended on somebody checking a workbook. Over a year, several circuits ran an extra month after the client had left, and one ran three.

    What changed

    Notice windows are held per line with alerts before they close. The extra months stopped, which paid for the platform on its own in the first year.

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

  • Yes. Services are per-client records with no practical limit, so a client with several hundred lines is held properly rather than as a summary with the detail elsewhere.

  • It holds what should be billed - quantity, price, period - and exports that to your billing platform. It is not a call-rating engine and does not process CDRs, and we would rather integrate with the platform that does.

  • Yes, as templated project boards with dependencies and dates, shared with the client if you want them to see progress. The twentieth install starts from the nineteen before it.

  • An incident attaches to the individual service record, so recurring faults on one circuit or extension are visible as a history and can be evidenced when escalating to a carrier.

  • Crushed Ice is a Wildix partner and the group has built integrations against its API before, so the ground is familiar. Nothing is shipped today - tell us what you need during discovery and we will be specific about effort rather than vague about capability.

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

Telecoms

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