Vehicle Telematics Platform Cost: The Connector Is Not the Bill

Every quote you receive for a vehicle telematics platform will price the same thing: the connector. Read the line items. Someone has estimated the work of pulling messages off a provider feed, parsing them, and putting them in a database, and that estimate is probably close to right. It is also the part of the job that costs the least and matters the least.

The vehicle telematics platform cost that actually lands on your budget is set somewhere else. Three decisions, all taken before code, and all of them cheap to get wrong.

What you are actually buying, and what you should rent

Start by separating the estate from the platform, because they get quoted together and they should not be.

The device estate is a commodity. Hardware, SIMs, the provider's own ingest, their raw feed. Dozens of vendors sell it, the prices are public, and none of them will differentiate your operation. Rent it. If you are running mixed fleets you may end up renting two, because a light commercial estate on OBD dongles and a heavy fleet reading SAE J1939 off the FMS Standard interface are rarely served well by the same supplier.

The platform is the part nobody can rent you. It is the thing that takes the feed and makes it answer questions your business actually asks. How much did this vehicle cost us over its life. Which of these 40 vans is due for a workshop slot before it strands someone. Why does one depot burn 11 per cent more fuel on the same routes.

Notice that none of those questions can be answered from telematics data alone. Every one of them needs the feed joined to something else you already own.

That distinction is the first place a quote goes wrong. A supplier who prices "a telematics platform" and includes device management, a mapping surface and a driver app is selling you three things you can buy for less, and is usually thin on the one thing you cannot.

Ingest is a fortnight, so why do the estimates miss

Pulling a provider feed is not hard work. The message formats are documented, the volumes are predictable, and the failure modes are the ordinary ones: the feed does not stop when your database does, so you put a queue in front of it, and providers replay messages, so you make the write idempotent on their message id. Sixty to 120 hours covers it for a single provider, including the queue and the replay handling.

So a 460 hour platform quote looks padded next to a 90 hour ingest quote, and buyers reasonably ask what the other 370 hours are for.

Here is the honest answer. The ingest hours price moving data. The remaining hours price deciding what the data means, and that work does not shrink with a better connector.

Take signal naming. Your provider calls it engine_hours. The OEM feed for the same vehicle calls it total_engine_operating_time and counts from a different zero. A second provider on your mixed fleet reports it only when the ignition cycles. Nobody can write a whole life cost report until somebody decides which of those three is the truth and what happens when they disagree. That is a signal catalogue, it takes 30 to 60 hours to build properly for a typical fleet, and it is invisible in every quote that prices only the connector.

Take timestamps. A vehicle out of coverage buffers on the device and dumps 40 minutes of history when it reconnects. Your ingest is happily writing at received_at. Your fuel report is now wrong in a way that will take a week to find. The fix is trivial once you know, and unbudgeted if you do not.

Retention and resolution are the real price list

This is the line that compounds, and it is the one the automotive industry page names as a standing failure: telematics kept at full resolution forever.

Run the arithmetic on a small fleet. Five hundred vehicles, 20 signals, sampled once a second. That is 500 times 20 times 86,400, or 864 million data points a day. At a modest 12 bytes per stored point, call it 10.4 GB a day and roughly 3.8 TB a year, growing by the same amount every year after, on a fleet most operators would describe as small.

Now change one decision. Four signals genuinely need one second resolution, typically speed, position, ignition and harsh event detection. The other 16 are fine at one sample every ten seconds. Same fleet, same coverage: 500 times four times 86,400, plus 500 times 16 times 8,640, comes to 242 million points a day. A 72 per cent cut for a decision that takes one meeting with your operations lead.

Change a second decision. Keep full resolution for 30 days, because that is the window in which anybody ever replays a journey, then aggregate to one minute for everything older. A one second signal at one minute resolution is 1,440 points a day instead of 86,400, which is 98.3 per cent less on aged data. The 30 day hot window stays queryable at full fidelity and the four year archive stops being a line item.

None of that is clever engineering. It is a policy written down before ingest is built, costing 40 to 90 hours to implement as tiering and downsampling, and saving a storage bill that otherwise grows without anyone deciding it should.

Get it wrong in the other direction and it is worse than expensive. Location history at one second resolution held for five years is personal data under GDPR with no defensible retention justification, and you will meet that fact during a subject access request rather than during design.

The VIN join is where the value sits

Telematics knows how the vehicle was used. Your workshop knows what was done to it. Almost nowhere have those two been joined, because they live under different keys.

The telematics provider keys on a device serial. The dealer management system keys on a customer, with the vehicle hanging off the customer record. The parts catalogue keys on the current part number, which changes under supersession. The finance system keys on a contract. Ask "what has this vehicle cost us" and you are asking four systems that share no identifier.

The VIN is the only key that survives all of it. It survives resale, it survives the device being swapped, it survives the contract ending. Registration does not, and using a registration as the durable identifier is the single most common modelling error we meet in this sector.

Making the VIN the spine is 70 to 140 hours depending on what your DMS will expose, and it is the work that turns a feed into an asset. Predictive maintenance is exactly this join and nothing more: usage from telematics, intervention history from the workshop, matched on VIN. No telematics vendor can sell it to you, because they cannot see the workshop.

If you only fund one part of this platform, fund that one.

What the rules now require of the data path

Two things changed and both affect the build rather than the paperwork.

UN R155 and UN R156 have applied to all new vehicles in the EU since 7 July 2024, through Type Approval. They govern the manufacturer, not you, but they shape what an OEM will expose and how. ISO/SAE 21434 is the engineering process that produces the evidence those approvals rest on, which is why OEM data access negotiations now come with a security questionnaire attached.

The EU Data Act applied in full from 12 September 2025, and the connected product duties, the design by default obligations, started applying on 12 September 2026. In practice that means a user of a connected vehicle can require in scope data to be made available, including to a third party they nominate. Operating vehicles in the EU means your platform needs to answer that request without an engineer writing a query each time.

Budget 50 to 110 hours for consent handling and data access. It sounds like compliance overhead. It is mostly plumbing you would want anyway, because a system that can export one vehicle's data cleanly for a regulator is a system that can also hand a leaving customer their history without an argument.

What a vehicle telematics platform costs, with the hours shown

The rate is $40 to $100 per hour by role. Reporting work sits near the floor, identity resolution and consent handling near the ceiling, and mixed teams blend to around $65.

Module	Hours	What it covers
Feed ingest and normalisation	60 to 120	Queue, idempotency on provider message id, buffered replay handling
Signal catalogue and retention policy	30 to 60	Naming, units, source of truth per signal, resolution and retention decided per signal
VIN identity resolution and service history join	70 to 140	VIN as spine, device and contract mapped to it, workshop history joined
Storage tiering and downsampling	40 to 90	Hot window, aggregation rules, archive
Consent and data access	50 to 110	EU Data Act request handling, GDPR retention justification, export
Reporting and alerting surface	50 to 100	The three to five questions the business actually asks

Worked example. Ingest 90 plus catalogue 45 plus VIN join 105 plus storage 65 plus consent 80 plus reporting 75 equals 460 hours. At $40 that is $18,400. At $100 it is $46,000. At a $65 blend, about $29,900.

The full span across the six modules runs 300 hours at every minimum to 620 at every maximum. Every line above sits inside its own published range, so move any of them and watch what it does to the total.

Deliberately excluded from that number: the devices, the SIMs, the provider subscription and the storage bill itself. The first three are commodities you should rent, and the fourth depends entirely on the retention decision in the third section.

The three questions that justify the whole thing

Before any of the six modules gets funded, write down the questions the platform has to answer. Not twenty. Three to five, each one owned by a named person who currently cannot answer it.

We keep meeting the same shortlist.

What has this vehicle cost us, all in, since we took it on? Purchase or lease, fuel or charge, every workshop visit, every part, every downtime day. Today this takes an analyst two days per vehicle and nobody asks it more than once a quarter. After the VIN join it is a query.

Which vehicles will strand someone in the next 30 days? Usage from the feed, intervention history from the workshop, and a rule as simple as engine hours since last service crossed against the manufacturer interval. Most operators are running this on a spreadsheet that one person maintains, which means it stops when they take leave.

Where is the fuel going? Two depots, same routes, same vehicle mix, and an 11 per cent gap. That gap is either driver behaviour, idle time, or a routing difference, and telematics can separate the three in an afternoon once the signals are named consistently. Before that it cannot, because one depot's provider reports idle time and the other's infers it.

Scope the reporting module to those questions and it costs 50 hours. Scope it to a dashboard and it costs 100, then gets opened twice.

Two ways this goes wrong that cost more than the build

The pilot that never ends. Fifty vehicles, a proof of concept, a report that looks convincing, and then eighteen months of nobody funding the rollout because the pilot answered a question no budget holder had asked. Pilots should be scoped to one of the three questions above and should end with a number a director can act on, not with a demonstration.

The provider migration nobody costed. Telematics contracts run three to five years. When you switch, the device serials change, the signal names change, and the historical data you spent two years accumulating is keyed to a provider you no longer use. If the VIN is the spine and the signal catalogue names the truth rather than the vendor's field, migration is 40 hours of remapping. If neither is true, it is a rebuild, and we have seen operators simply abandon their history instead. That is the single strongest argument for spending the 30 to 60 hours on a catalogue that most quotes leave out.

Where the number moves, with direction

Up. A second telematics provider on a mixed fleet, because the signal catalogue work roughly doubles even though the ingest barely changes. OEM feeds in scope, because each manufacturer negotiates access separately and their security review takes calendar time you cannot compress. A DMS that exposes nothing, which turns the VIN join from an integration into a data extraction project.

Down. A single provider. A VIN that is already the spine of your existing systems, which removes most of the identity work. A short hot window, because 7 days rather than 30 costs nothing extra to build and cuts the storage tier substantially. Reporting scoped to three questions instead of a dashboard nobody opens twice.

Neutral, despite what you will be told. Vehicle count. Going from 500 vehicles to 5,000 changes your storage bill and changes almost nothing about the build, because the same six modules do the same work. Anyone pricing this per vehicle is pricing a subscription, not a platform.

A sequence that reaches something usable

Do not build all six modules and then switch on. Build in an order where each step is independently useful, because telematics projects that go dark for four months tend not to come back.

Weeks 1 to 2. Capability read. Call the provider API, call the DMS, and write down what each will actually expose and accept. Not what the brochure says. This single artifact decides the hours on everything after it.

Weeks 2 to 4. Ingest plus signal catalogue, together. They are the same conversation and splitting them is how you end up naming things twice.

Weeks 4 to 7. VIN join. At the end of this step you can answer a whole life cost question for one vehicle, by hand if necessary. That is the moment the project stops being infrastructure and starts being worth funding.

Weeks 7 to 9. Retention and tiering, before the storage bill forms a habit.

Weeks 9 to 12. Consent, data access and the reporting surface.

Twelve weeks, roughly 460 hours, and something answering real questions by week seven.

One last thing worth saying plainly. If a supplier quotes you a telematics platform without asking what your DMS exposes and whether the VIN is already your primary key, they have not scoped the job. They have scoped the connector, and you will meet the rest of it later at a worse rate.