Connected Devices
Hardware that reports in
A product that ships is not finished. It is the first day you can find out how it actually behaves.
What it does
Four things, from the first unit
Built into the product from stage one, rather than added by a separate team after the hardware is frozen.
Devices send back what they are doing.
Measurements, states and events, from the unit on a bench and from the unit in someone else’s hands. Both look the same to you.
The record is kept, not sampled.
Behaviour over months is a different question from behaviour right now, and it is the one that finds the fault you cannot reproduce.
One device and ten thousand look the same.
Nothing about how you work has to change when the number grows. That is a property to design in at the start, not to retrofit.
Where nothing was recorded, it says so.
A gap in the record is shown as a gap. A platform that always has a number is a platform that will eventually give you a wrong one.
Your measurements are yours
Data from your products belongs to you. What we may do with it is written in the agreement you sign before onboarding, and it is narrow. We do not sell it, we do not pool it, and we do not need it to be pooled for the product to work.
Ownership
The question you should ask every platform
Any company that connects your products to a service ends up holding measurements about how your customers use them. That is commercially valuable, and it is the thing to establish before you commit, not after.
So ask it plainly, of us and of anyone else: who owns the data, what may they do with it, and what happens to it if we stop working together. If an answer is vague, the vagueness is the answer.
What it is for
Four uses that pay for themselves
- Finding the fault you cannot reproduce
- Knowing what people actually use
- Servicing before it breaks
- Proving it works
The unit that fails once a fortnight at a customer site. Months of recorded behaviour turn it from a mystery into a pattern.
Which capability is used daily and which was a committee decision. Version two gets designed from evidence rather than from opinion.
A drift in behaviour usually appears before a failure does. Seeing it is what separates a service visit from an emergency.
When a customer says the product is at fault, a record of what it was doing is worth more than a conversation about what it should have been doing.
Questions
Straight answers
Do our products have to stay connected to work?
No. A product that only works when it can reach a service is a worse product. Connection adds visibility; it is not a dependency for the thing to function.
Where do the measurements live?
Measurements from connected devices are stored in India. Some other processing — email delivery, and the handling of design requests — is carried out by service providers located outside India. Both are set out in our Privacy Policy.
What if a device is in a place with no network?
It keeps its record and reports when it can. Intermittent connection is the normal case in the field, not the exception, and it is designed for.
Bring a product that is already out there
The most useful first session is on hardware you have already shipped and have questions about.
WeBiii Traume Private Limited
CIN U01284MH2026PTC464814
H. No. 1919, Nanapada, Vevaji, Talasari,
Palghar, Maharashtra 401606, India
Grievance Officer: Geetanjali Bharti — grievance@chtpl.org