About us
We build the systems hotels forget are there
TES is an engineering company in Bengaluru. Our first installation went live in February 2005, and for twenty years since we have designed and built centralised control systems for hospitality and commercial buildings — the hardware in the wall, the firmware inside it, and the software that runs the estate.
Twenty years in the same problem
TES started with a straightforward observation: hotels were paying to cool and light rooms nobody was in, and nobody at head office could see it happening. Solving that properly meant more than a timer on a wall. It meant knowing whether the room was occupied, whether the guest had checked out, whether the door was open, and whether the unit in room 412 was drawing more current than it did last month.
That question has kept us busy ever since. It produced two product lines — PACsys for power and access control, and TCMsys for centralised air conditioning — that today run in roughly three hundred properties. More recently it produced Tnode and Knode, which take the same control down to a single air-conditioning unit for buildings that will never need a site-wide system.
We are not a systems integrator reselling somebody else's platform. The circuit boards, the bus protocol, the firmware and the dashboards are all ours. That is a slower way to build a company and a much better way to support one: when a customer calls about a fault on a segment, the person who designed that segment is in the building.
The record
We started before we had a website, which is common for a company of our age and confusing if you only check the domain. The sequence:
- 2005
- First installation goes live February.
- 2009
- Registered for VAT in Karnataka 16 May, TIN 29590843927.
- 2011
- tes.ind.in registered Our original domain, held through 2035.
- 2014
- tesbms.com registered For a name that says what the systems do.
- 2017
- Migrated to GST Proprietorship, Bengaluru Urban, Karnataka.
Everything from 2009 onward is a matter of public record and can be verified independently.
- First installation
- February 2005
- Experience
- 20+ years
- Properties live
- ~300
- Products
- PACsys, TCMsys, Tnode, Knode
- Presence
- India & Canada
- Original domain
- tes.ind.in, 2011
Capability
Four disciplines, one team
Most companies in this space do one of these and buy the rest. Doing all four is what lets us change the protocol when the product needs it.
Hardware
Board design for floor controllers, room modules and segment gateways, built for the environment they actually live in — in a distribution board, on a long cable run, for a decade.
Firmware
Embedded C on the microcontrollers, plus the wired bus protocol they speak to each other. Deterministic, power-aware, updatable in place.
Backend
The site and cloud platforms — APIs, real-time event pipelines, reporting, and the integrations into property and building management systems.
Applications
Web dashboards, desktop clients and mobile tools for the people who work in the building rather than on the system.
How we work
Four things we will not trade away
The room comes first
A guest should never be able to tell that the network is down. Every design starts from what the room does on its own, and adds central control on top of that — never the other way round.
No black boxes
When something breaks, the engineer should be able to see the raw traffic on the bus. We build the diagnostic tools we would want at two in the morning, and we ship them to customers too.
Boring infrastructure
Our customers are hotel IT teams, not platform engineers. We deliberately choose ordinary, well-understood technology that an in-house team can run without us.
Own the whole stack
Because we design the hardware, the firmware and the software, a fault has one owner. There is no vendor to point at.
Track record
What roughly 300 properties taught us
We keep an honest internal record of what has gone wrong at fleet scale and what we changed because of it. Some of the most useful things we know came out of incidents, not design reviews.
Push beats polling, every time
Almost every performance problem we have had traced back to something asking repeatedly instead of being told. Live connections replaced polling across the platform, and the class of problem went away with it.
Keep customers’ data apart structurally
One database per property is more work up front than one shared pool. It is also the reason we have never had a cross-property data question to answer, and why a busy property cannot slow down a quiet one.
A durable local queue is worth more than uptime
Nothing we run has perfect connectivity, and hotel WAN links are worse than most. Buffering events on site and shipping them in order is why a bad connection has never cost a customer a check-in.
Never ship to the whole fleet at once
Version-gated rollouts have contained a bad release to a handful of pilot sites more than once. Without them, that same release would have reached every property we operate.
Log everything, with the payload
Reconstructing an incident three days later is only possible if the record includes what was actually sent. Every time we shortened an audit payload to save space we regretted it.
Design for the ceiling you can see
We built for the estate we had and factored the code so it could be split when load demanded. Designing on day one for ten times the customers we had would have meant never shipping.
We will show you the scars. If you are evaluating us seriously, ask. We would rather walk you through the incidents we have had and what changed afterwards than pretend a system this size has never had one.
Work with the people who built it
Whether you are specifying a new property or replacing a system that has stopped being supported, we are happy to talk through the engineering before anyone talks about price.