Most platform evaluations run the same way. A spreadsheet with a row per feature, a row per limit, a row for price, and somewhere near the bottom a row called “support” with values like “email” or “24/7” copied from the plan table. Features and price deserve the attention; the buyer’s guide questions cover them well.
Support gets one row because nobody knows how to evaluate it from the outside, and during the trial nothing has broken yet.
Then the devices ship. Eight months in, a gateway firmware update changes a payload format and 300 sensors start writing garbage at 2 a.m. on a Saturday. At that moment the feature list is irrelevant. What you are buying now is whoever answers, how fast, and whether they understand the device layer or only the platform. The support you get in that hour was decided by things the pricing page never showed you: who staffs the queue, what “response” means per severity, and whether you can help yourself when nobody is awake.
This post is about finding those things out during the trial, when you still have time and a choice.
Who answers, and what do they know
“24/7 support” describes a schedule, not a capability. The question that matters is what the person reading your ticket knows. There is a wide gap between a triage tier that classifies tickets and asks for screenshots, and an engineer who has built on the platform and can read your Payload Parser code.
The test: during the trial, open a real ticket with a real technical problem. A decoder question works well. Send a raw payload, your parser code, and the wrong output. Then watch. A first reply that asks which browser you use tells you one thing. A first reply that spots the byte offset error tells you another. Time both the first response and the time to a useful answer; they are different numbers, and the second is the one you live with.
Ask directly whether support is staffed by the vendor’s own engineers or by an outsourced tier, and whether the people answering can reach the people who write the platform. You want a yes to the second even if the first is mixed.
Response commitments per severity, in writing
Most plan tables list a single response time or none at all. Incidents are not one size. A dashboard widget rendering wrong is not the same as data ingestion failing for every device at a customer’s site, and a support model that treats them the same is either over-promising on the small stuff or under-delivering on the big stuff.
What you want is a severity ladder: a definition of each level, the response commitment for each, the hours it applies to, and the channel you use. Ask for the escalation path in writing: who gets involved when the first responder is stuck, and how you trigger that. A vendor who cannot describe escalation does not have one; they have a queue.
Do not accept “we usually answer within an hour.” Usually is not a commitment, and the incident that costs you a customer is by definition unusual.
Platform help vs device help
This is where most IoT support disappoints. The platform vendor supports the platform. Your problem lives in the device: a LoRaWAN uplink on an unexpected port, a Modbus register map off by one, a decoder that worked on firmware 2.1 and breaks on 2.3. Vendors draw the support line at the API boundary, and everything below it becomes “your device manufacturer’s problem.”
Find out where the line is before you need it. On TagoIO, the device layer is part of the product: Connectors and Networks decode payloads for published sensor models, and the Payload Parser is a first-class place to fix decoding, so a decoder question is inside scope rather than outside it. Whatever platform you evaluate, ask the question plainly: “If my parser produces wrong values, will you look at the parser?”
Can you help yourself at midnight
Support tickets are the slow path. The fast path is documentation (TagoIO publishes its own at docs.tago.io), and the quality of the docs decides how many tickets you need in the first place. During the trial, skip the getting-started guide. Read the docs for your exact use case: the Action type you plan to use, the Analysis trigger you need, the Access Management policy shape for your customers. If the docs answer the question you actually have, with a working example, you will spend most nights not filing tickets.
More self-serve checks:
- A public status page with history. A green dot is not enough; you want the record of past incidents, how they were communicated, and how long they lasted. TagoIO publishes one at status.tago.io.
- A community where other integrators answer. TagoIO’s is at community.tago.io. Read the unanswered questions as carefully as the answered ones; the ratio tells you how alive it is.
What happens when you resell
If you are a system integrator putting your own customers on a TagoRUN portal, the support question doubles. Your customers call you, not the platform. You are first line whether you planned for it or not, and the platform vendor is your second line. That changes what you need from them.
Ask: can I open a ticket about a customer’s issue and get it treated as mine? Do the Profiles I run for customers get the same support standing as my own? When I promise my customer a response time, what response time do I get from you to back it? The gap between those two numbers is your risk, and you cannot close it with goodwill. The SLA reselling post covers how to structure the promise; the point here is to get the upstream number before you write the downstream one.
Confirm what your plan actually includes
Support tiers often follow plan tiers, and the trial runs on whichever tier the vendor chose for trials. Before signing, name the plan you will actually buy and ask, in writing, what support comes with it: channels, hours, severity commitments, and whether escalation exists at that tier or only above it. For TagoIO, the current terms are on the pricing page and in the account plans docs; read the version that is live when you sign, not a summary from a sales call.
The trial test plan
Run this during the evaluation, not after:
- Open one real ticket with a real payload-parser problem. Record time to first reply and time to a useful answer.
- Read the docs for your exact use case, not the tutorial. Note what is missing.
- Read the status page history for the last year.
- Search the community for your device model and the features you plan to depend on.
- Ask for the severity definitions and the escalation path in writing.
- Ask what the plan you will buy includes, and whether the trial tier matched it.
- If you resell, ask how tickets work for your customers’ issues and what response time you can pass through.
Two days of this work tells you more about the next three years than any feature comparison. The platform that wins the spreadsheet and loses the 2 a.m. ticket is the expensive one, whatever the price row says.
