Total cost of ownership - why the sensor price isn't the bill
The cheapest quote is rarely the cheapest system. The price of a sensor is the figure everyone compares - and the part of the bill that says least about what the next five years will cost.
Where the money actually goes shows across the whole lifecycle. Costs start with selection, climb steeply during implementation and keep running in operation. Besides the devices themselves, installation, calibration and validation account for a large part of the upfront investment. On top of that come two biases that cloud any cost calculation: short- and long-term costs get overlooked, and benefits get estimated too optimistically.
This article is a framework for your own calculation. It shows which items belong to which phase, which of them are easily missed, and why the benefit side belongs in your hands.
Four phases, four kinds of cost
The cost of a data capture system, from first consideration to replacement, falls into four sections. The structure works as a checklist, because each phase has its own hidden items:
| Phase | What belongs to it | What is easily missed |
|---|---|---|
| Consideration | Needs assessment, procurement, sizing the number of sensors, pre-sales advice | Lead time as an opportunity cost: every week of delay pushes back every phase that follows |
| Implementation | Mounting, brackets, network connection, commissioning, calibration, validation | The premium for specialist work and the effort of getting access to data and interfaces |
| Operation | Oversight, firmware updates, manufacturer support, user training, internal security requirements | Rework caused by the environment, such as changing light, and devices that have to be sent back |
| Maintenance | Maintenance contract, device status monitoring, renewal | Additional devices if a new use case calls for new hardware |
Consideration is easily underestimated, because it looks like preparation rather than cost. Yet for newcomers in particular, the time between decision and delivery is considerable. A coverage calculation that settles the number of sensors before ordering saves measurable effort there.
Why implementation is the most expensive stretch
A sensor hanging from the ceiling isn't counting correctly yet. It has to be connected, configured, checked against a manual count and signed off. Each of those steps needs someone who knows what they're doing, and each of them can slip.
The questions that save money here are unglamorous. How quickly is a device mounted, and are there suitable brackets? Does it need on-site configuration, or can that be done remotely through a web interface? How do you check it counts correctly? What a rollout looks like phase by phase, and who is responsible for which part, is covered in Rolling out a counting system.
Two lifespans that don't match
Two figures need to be read together. In retail, five years is considered a normal useful life for a data capture system, and renewal after five to seven years is the market norm. The devices themselves last much longer: for the best of them, the manufacturer gives a mean time between failures of more than 30 years.
So why renew after five to seven years if the hardware lasts thirty? Because the use case changes, not the device. Whoever counts entrances today wants zones, queues or demographics tomorrow. The hardware doesn't expire; the use case does.
Two planning questions follow from that:
- Does a new use case need new devices or just a new licence? Add-on functions such as gender, age or object detection need a licence. Whether a mounted sensor can support them also depends on model and mounting height, though. Planning today for later use cases saves a second installation tomorrow.
- Can the analysis grow without the data having to move? A software layer that builds new analyses on the same sensor data extends the life of the whole system.
The bill of quantities: what goes into your calculation
A solid cost calculation doesn't start with prices but with quantities. You put in the prices yourself - they depend on project, supplier and timing. The quantities can be settled in advance:
| Item | What it depends on |
|---|---|
| Sensors | Coverage planning per entrance and zone - which also determines cable routes and switch ports |
| Mounting and electrical work | Ceiling height, brackets, accessories, per site |
| Commissioning and acceptance | Calibration and acceptance count - the steepest stretch |
| Network and power | Power over the network cable, PoE class 0: 7.5 to 12.95 W per sensor, depending on model (data sheets) |
| Licences | Add-on functions per sensor; group counting is included with no extra licence |
| Platform | Subscription, credits for alerts, quota for webhook deliveries |
| Your own process costs | Who looks at the figures how often, and what does a deviation trigger? |
The last row is missing from almost every calculation, and it decides the benefit. A system whose figures nobody reads costs the same as one that drives staff planning every Monday.
Where operating costs hide
In operation, costs don't come from the sensor but from the people who have to look after it. Three questions make the difference between a system that runs and one that needs tending:
- Remote access or a site visit? A device that can be checked and configured in a browser costs a fraction of a call-out.
- Automatic or manual monitoring? Checking device status by hand is a cost you pay every week. A platform that detects a silent or half-failed sensor on its own saves that round - and protects against statistics that drift without anyone noticing. How that works is covered in The half outage.
- Open or closed data? Being able to pull figures into your own systems through a documented interface saves the detour through exports and manual work. What makes an interface open is covered in Open interfaces.
The benefit side is yours
Cost calculations for counting systems often end with an elegant payback: after so many months the system has paid for itself. Such calculations have one flaw - they run on the assumptions of whoever is selling. How much more revenue a shorter queue brings, how much staff time better planning saves, how much space frees up after an occupancy study: that depends on your operation, not on an example.
So one simple rule applies to every figure in a cost calculation: it is either measured and backed by its formula, or it is explicitly marked as an assumption. There is no third category. An assumption dressed up as a measurement is exactly the kind of figure The blind spot describes as the most expensive.
The most honest route to the benefit side is a small start with a concrete question and a baseline period. After a few weeks, instead of an assumption, you have a before and an after from your own operation.
What belongs in the tender
- How is the number of sensors determined, and is coverage planning available before ordering?
- What effort goes into mounting, calibration and acceptance, and who bears it?
- What is the power draw per sensor, and is the PoE budget of the existing switches sufficient?
- Which add-on functions need licences, and can the planned sensors support them at the intended mounting height?
- Can devices be checked and configured remotely, and how is an outage detected?
- What running costs arise for the platform, alerts and interfaces, and what do they depend on?
- Which figures in the benefit calculation are measured, and which are assumptions?
How we do it
For a rollout of the ANALYSIT Counting System we provide the structure and the bill of quantities: the four lifecycle phases as a framework, the number of sensors from coverage planning, the effort for mounting, calibration and acceptance counting, the PoE budget from the sensor data sheets, the licences for the add-on functions per sensor, and the platform's running items - subscription, alert credits and the monthly webhook delivery quota. You put in the prices.
In operation, ACS monitors the sensors itself: a sensor that goes offline triggers an alert, and a half outage is detected against the site's own history and taken out of correlation, opening-hours and weather analysis. The data is available to your own systems through an open REST API, webhooks and exports, and new analyses build on the same sensor data.
Every figure we show you is either measured and backed by its formula, or explicitly marked as your assumption. If you want to work through the numbers for a counting system, talk to us. We'll bring the bill of quantities.