A production engineer wants three more sensors on a problem well. Suction pressure, discharge pressure, and a vibration point on the compressor, because the well keeps going down and nobody can tell why from the data that exists.
The conversation that follows is not about whether the sensors are worth it. It is about what three more tags cost per month, forever, across a licensing agreement nobody in the room negotiated.
That is a licensing model shaping an engineering decision, and it is shaping it in the wrong direction.
Four shapes, and they behave differently
Industrial software has settled into roughly four licensing shapes. The rate matters less than the shape, because the shape decides what behavior it rewards.
| Shape | What you pay for | Marginal cost of one more sensor |
|---|---|---|
| Per-tag tiers | Capacity bands sized by monitored points | Real, recurring, and visible to the engineer asking |
| Unlimited tags, per server or connection | The platform instance | Zero, until you add a site |
| Subscription or consumption pools | Credits drawn down across a product family | Opaque, and only clear at renewal |
| Hosted per-well or per-site SaaS | A business unit rather than a technical one | Zero on an existing well, real on a new one |
Only the first makes an engineer hesitate before adding an instrument, and that hesitation is what this post is about.
What per-tag pricing optimizes for
Every pricing model teaches the customer something. Per-tag pricing teaches your engineers to want fewer tags.
Watch what that looks like in practice. Marginal instrumentation stops getting added, because three sensors on one problem well is a recurring cost that needs approval and the well is not important enough to fight for. Diagnostic points get dropped from new builds to hold the tag budget. Existing tags get pruned during renewals, which means somebody is choosing which visibility to give up based on a license rather than on operational value.
The deeper problem is that the tags you cut are exactly the ones worth having. Core measurement is never at risk; nobody deletes the sales meter. What gets cut is the second-order stuff: the vibration point, the auxiliary temperature, the extra pressure that would let you distinguish between two failure modes. That is the data that turns “the well went down” into “the well went down because of this,” and it is the first thing a tag budget removes.
You are optimizing a small line item by degrading the thing the whole program exists to produce.
You are paying to store a number that never changes
There is a specific absurdity worth naming, and it falls straight out of the tag taxonomy from earlier in this series.
On the inventory we ran, 19 percent of tags were configuration: alarm setpoints, deadbands, timers, scaling factors. Values that change a handful of times a year, if ever. Another 6 percent were alarm bits, and 2 percent had never recorded a value at all.
Under a per-tag model, all of that is billable. You pay a recurring fee to monitor a trip setting nobody has touched since commissioning, at the same rate as the flow measurement the business runs on.
That is not a vendor being unreasonable. The tag exists in the tag database and the platform is serving it. It does mean the number your bill is calculated from includes a meaningful fraction of points carrying no time-series information, and almost nobody audits it.
One warning on acting: a silent tag is not automatically dead weight. Ours included H2S and LEL detectors that have correctly never alarmed. Reading zero for two years is a gas detector working. Pruning by silence alone will eventually remove a safety signal to save a license fee, so the audit finds candidates and a person who knows the equipment decides.
The license is usually the smallest line
Here is the part that reframes the negotiation.
For a producing operator, market commentary consistently puts the SCADA software license well below the other lines in the operational data stack: field hardware, instrumentation, communications, the automation contractor’s time, integration work, internal engineering effort. We have not measured the ratio ourselves and would not publish one. Directionally the point holds, and the license gets attention because it is visible and annual rather than because it is large.
So the common move, grinding the vendor on rate while accepting a per-tag structure, optimizes the smallest number in the stack and leaves in place the mechanism that suppresses instrumentation. That trade is backwards. A ten percent rate reduction on a small line is worth considerably less than removing the reason your engineers stopped asking for sensors.
This is the same error as measuring vendor sprawl by license fees. The invoice is the visible number and the smallest one. The real cost is the work that does not happen.
Negotiate the shape, not the rate
The practical guidance is short.
Ask for the shape you want first. An unlimited-tag instance, a site-based band, or a generous tier with headroom removes the per-sensor conversation entirely. Vendors will often move on structure when they will not move on rate, because structure is a smaller concession to them than it is a benefit to you.
If you must take a per-tag model, size the band for growth. Buy the tier above what the census says you need, so the marginal sensor is free until the next renewal. The point is not to save money. It is to make the engineer’s decision about the well rather than about the contract.
Audit the tag count before every renewal. Duplicate nodes from a site rename, tags on equipment nobody can locate, points that have never reported. All of it is billable, some of it is removable, and the ways a tag count misleads are predictable enough to check.
Separate the meter from the decision internally. Even under a per-tag agreement, keep the marginal cost away from the engineer proposing the sensor. Hold a tag budget centrally, with room in it. Somebody has to own that cost, and it should not be the person deciding whether a well needs another pressure point.
Ask what happens if the count doubles. Any model that cannot answer that question with a number you can plan against is a model you are going to renegotiate under pressure later.
The per-well model has the same flaw, one level up
Hosted SCADA priced per well looks like it escapes this, because the meter is a business unit rather than a technical one. Engineers can add sensors to an existing well without the bill moving, which is exactly the property you want.
It moves the disincentive rather than removing it. Under a per-well model, the marginal cost lands on connecting a well at all, which is where it bites on the low-rate tail. The stripper well making four barrels a day is the one where an extra monthly fee is hardest to justify, and it is also frequently the one where remote monitoring would save the most windshield time.
The question to ask about any pricing shape is the same: what does this make my team reluctant to do? Then check whether that reluctance points at something you actually want less of. Sometimes it does. A model that discourages instrumenting genuinely dead assets is doing you a favor. A model that discourages instrumenting your marginal producers is quietly setting your surveillance strategy for you.
The direction you actually want
Ask an operator where they want to be in five years and the answer involves more instrumentation, more automated surveillance, and more decisions made from data rather than from a windshield survey.
A structure that charges per point of visibility pulls against that in every individual decision, quietly, without anyone ever deciding to instrument less. No one writes that policy down. It accumulates out of a hundred small approvals that were easier to decline.
Which is why this belongs in the contract conversation rather than the sensor conversation. By the time an engineer is justifying three transmitters on a marginal well, the decision has already been made somewhere else, by someone optimizing a different number.