Most system integrators price a managed service the same way they price a project. They add up the platform cost, add their support hours, put a markup on top, and quote a monthly number. It works. The first invoice goes out, the client pays, and the deal closes. But that math ties your price to your cost instead of the value the customer gets, and it quietly leaves recurring margin on the table every month for the life of the contract. So the question is not whether you can price a managed service. It is whether the model you picked will still pay you well when you have fifty clients instead of five.
This post walks through the pricing models you can use, when each one fits, how to handle the platform cost, and how to set up recurring revenue instead of one-time project billing. It also covers the case most pricing advice skips: when a managed service is the wrong model entirely.
Why cost-plus markup is the trap
Cost-plus is how almost every service business starts. You calculate what the service costs you to deliver, add twenty or thirty percent, and that is your price. It feels safe because it guarantees you are above cost.
The problem shows up over time. Your costs rise. Cloud bills go up, a senior engineer gets a raise, a client’s deployment grows and needs more attention. Meanwhile the client sees your price as a number to negotiate down, because you have framed it as a markup on inputs rather than a price for an outcome. You get squeezed from both sides. Industry data on managed service providers puts cost-plus gross margins around fifty percent, while providers who price on value land closer to seventy.
The deeper issue is what you are anchoring to. When your price is your cost plus a margin, you are selling infrastructure. When your price reflects what the client avoids losing or gains by having the service, you are selling an outcome. The same monitoring service that prevents a refrigeration failure in a food distribution warehouse is worth far more than the cloud and labor that produce it. Cost-plus pricing never captures that gap.
The pricing models and when each fits
There is no single correct model. There is a model that fits your service, your client, and the way your costs behave. Here are the ones worth knowing.
Per-device pricing. You charge a fixed amount per connected device per month. A temperature sensor might be one rate, a gateway another, a complex asset tracker a third. This is the easiest model to quote and the easiest for a client to understand, because the bill scales with something they can count. It fits well when your support effort genuinely tracks device count, for example fleet monitoring where each device is roughly the same work. The risk is that device count and value diverge. A client with a thousand cheap sensors is not getting a thousand times the value of a client with ten critical ones.
Tiered pricing. You build packages: basic, standard, premium. Each tier bundles more services, more support response speed, more dashboards, more users. This is the most common model among managed service providers, and for good reason. It gives the client a clear upgrade path, it lets you stop negotiating every line item, and it nudges buyers toward the middle tier where your margin is healthiest. It fits when your clients fall into recognizable segments. It works poorly when every client is a custom snowflake, because the tiers stop meaning anything.
Flat monthly pricing. One predictable number covers an agreed scope. Clients love the predictability, and so does your finance team. It fits mature, stable deployments where you understand the support load well enough to price it without surprises. The danger is scope creep. If “flat” quietly becomes “unlimited,” a single demanding client can erase the margin on three others. Flat pricing needs a written scope and a clear line for what triggers a change order.
Usage-based pricing. You charge by what the client consumes: data volume, messages, active assets, API calls. This aligns your price with the client’s own growth, which feels fair and scales naturally. It fits high-variance workloads where consumption really is the cost driver. The trade-off is that the client cannot fully predict their bill, which makes some buyers nervous, and your own revenue becomes harder to forecast. Usage models often work best as a hybrid: a flat base plus usage above a threshold.
Value-based pricing. You price against the outcome the client gets, not your inputs. If your monitoring service prevents an estimated quarter million in spoiled product per year, a price of thirty thousand a year is an easy yes and has nothing to do with your cloud bill. This model produces the strongest margins because it is decoupled from cost entirely. It also demands the most from you. You have to understand the client’s economics, quantify the value credibly, and be willing to walk away from buyers who only want to talk about cost. Value-based pricing is not a starting point. It is where you move once you can prove outcomes.
In practice most integrators end up with a hybrid: a tiered structure with per-device or usage components, priced with a value anchor in mind. The model is a tool, not a religion.
How to handle the platform cost
Your IoT platform is a real cost, and you have two honest ways to treat it.
You can pass it through. The client sees a platform line on the invoice and you add your service on top. This is transparent and easy to defend, and it makes sense when the client is sophisticated and wants to see the breakdown. The downside is that it caps your margin at your markup and invites the client to ask why they cannot just buy the platform directly.
You can absorb it. The platform cost disappears into your monthly price, and the client buys a single service from you. This is almost always the better choice for a managed service. It protects your margin, it keeps the client focused on your outcome rather than your supplier, and it stops the platform from becoming a negotiation point. With a white-label layer, the client never sees the platform brand at all, which makes absorbing the cost feel natural rather than like something you are hiding.
The mistake is doing neither clearly: burying a thin platform markup inside a cost-plus quote so that you are technically passing it through but presenting it as your own. That gives you the worst of both, low margin and an exposed dependency.
Setting up recurring revenue instead of project billing
The reason to care about all of this is that a managed service is a recurring revenue business wearing a project’s clothes. One-time project billing pays you once for work you do once. A managed service pays you every month for as long as you keep the deployment healthy and the client served.
That changes how you should price. A project quote optimizes for winning the deal. A managed service price optimizes for the lifetime of the relationship, which means you can afford to price the initial setup closer to cost if the recurring term is strong. It means contracts with terms, not month-to-month arrangements that evaporate the first time a client reviews spend. It means building the renewal into the model from day one, with clear scope, clear escalation, and a price that has room to hold its margin as the deployment grows.
Recurring revenue is also what lets you invest. Predictable monthly income is what funds the next hire, the better tooling, the deeper expertise that makes your service worth more next year than it was this year.
When a managed service is the wrong model
This is the part most pricing guides leave out. Sometimes the answer is not a better price. It is a different relationship.
A managed service is the wrong model when the customer wants to own everything. Some clients, for good reasons, want the deployment, the credentials, and the platform account in their own hands. Forcing a recurring service on them creates friction and resentment. Sell them the build and the handover, charge properly for it, and offer support as a separate optional contract they can take or leave.
It is the wrong model for a genuine one-off. If the client has a fixed-scope project with a defined end, no ongoing devices to monitor, and no real need for you afterward, a managed service is you inventing recurring work that does not exist. Price the project, deliver it, and move on. Padding a real project into a fake subscription damages trust.
It is the wrong model when there is no appetite for recurring spend at all. Some buyers, especially smaller ones or those with capital budgets but no operating budget, simply cannot or will not commit to a monthly line item. Pushing them into one produces a contract that churns in three months and costs you more to onboard than it ever returns. Be honest about the fit, take the project revenue, and keep the door open.
Knowing when not to sell a managed service is what makes your managed service offer credible when it does fit.
Where TagoIO fits
TagoIO is built for the resell and managed-service model, which is why the platform cost is something you can cleanly absorb. TagoRUN, the white-label portal layer, lets you deliver the client-facing experience under your own brand, your domain, your logo, with no TagoIO branding visible to the end user. That matters for pricing because a client paying for your outcome under your name does not anchor on what your underlying platform costs. The platform stays invisible and your price stays attached to your value.
The TagoIO partner program is structured around this model: integrators who build, deploy, and run solutions for their own clients on a platform that is already ISO 27001 certified and GDPR-aligned, with 500-plus device integrations and multi-tenant environments so one account can serve many clients cleanly. The compliance posture you inherit is also something you can price for, because it is something your client would otherwise have to build or buy.
Next steps
- Partner program for integrators: tago.io/partners
- TagoRUN white-label portals: tago.io/run
- TagoIO pricing: tago.io/pricing
