The four pricing shapes you will meet
- Per technician, per month. The most common shape for PSA-type products. Predictable, and it scales with your team rather than with your clients.
- Per endpoint or per device. More common where monitoring is bundled. Scales with your clients’ estates, which can move faster than your headcount.
- Tiered by capability. A per-user price that varies by which functional tier you need. The risk is discovering in month nine that a feature you assumed was included sits one tier up.
- Quoted through a partner or portfolio. Common with the larger platforms. Perfectly legitimate, and it makes like-for-like comparison hard unless you insist on a full written total.
The costs usually left out of the comparison
- Implementation and configuration, particularly where the platform is highly configurable and the configuration is therefore the project.
- Data migration, and specifically ticket history - which is often priced separately and which you should not skip.
- Integration or connector licensing, where each connection to another system carries its own annual charge.
- Client portal seats, charged per client user. This is the charge that quietly stops providers inviting clients in.
- Training, both initial and for people who join afterwards.
- Your own internal time. Usually the largest single cost of any implementation and almost never in anybody’s spreadsheet.
- The tier upgrade you will need in year two, which should be modelled now rather than discovered later.
Ask every supplier for a single document showing the full three-year total including all of the above. The ones who provide it readily are telling you something, and so are the ones who do not.
How to think about implementation cost
Implementation effort scales with two things: how much configuration the platform requires before it is usable, and how unusual your operation is. A highly configurable product is more capable and more expensive to set up, and both halves of that are true at once.
What matters most is the shape of the arrangement. A fixed price per stage, with what each stage delivers written down, is a supplier taking the estimation risk. A day rate with an estimate is you taking it. Both are legitimate, but they are very different propositions and the second one has no natural end.
What we charge, plainly
CubeMSP is priced per named technician per month, with one edition and no functional tiers. Client users invited to shared boards or reviews are not charged for. The API is included and is not licensed per connection.
Implementation is a one-off fixed fee covering discovery, configuration, data migration and training, quoted after discovery so that it cannot quietly become an open-ended project. Ticket history migration is part of it rather than an extra, because the knowledge features depend on it and charging separately for that would be perverse.
We are in early access, and pricing for early customers reflects both that and the expectation that they will influence the roadmap. Ask us for current figures - they are on the pricing page and we will put them in writing.
Working out whether it pays for itself
Build this by measuring one thing rather than modelling everything. Pick the largest of: renewals missed or auto-rolled in the last year, vendor price rises not passed on, licence counts billed incorrectly in either direction, chargeable work never invoiced, or engineering time spent rediscovering known fixes.
Most providers find that a single one of those, measured properly for one year, exceeds the annual cost of the platform. If none of them does, that is a useful finding and it means you should wait.