The Museum Was Monitoring Its Environment. The Problem Was What Happened Between Inspections

One thing I have learned from IoT projects is that customers do not always have a technology problem. Sometimes they already have instruments, procedures and people doing the work. The weakness lies in what they cannot see between one observation and the next.

This was the situation at a national museum responsible for preserving valuable collections, including textiles, manuscripts, ceremonial artifacts and archaeological objects. Temperature, humidity and light can affect these materials over time, so environmental conditions within the storage areas needed to be carefully monitored.

The museum was already doing this. Staff conducted scheduled inspections, checked instruments and recorded readings. On paper, there was a monitoring process. In practice, there were hours between inspections when nobody knew whether conditions had changed.

What Problem Were We Actually Solving?

Suppose someone checks the humidity at 9:00 am and everything looks normal. At 10:30 am, the humidity rises beyond its acceptable range. If the next inspection is several hours later, the problem remains invisible during that period.

That was the gap we wanted to close. The museum needed continuous monitoring, automatic alerts when conditions became abnormal, historical trends and a digital record of what happened throughout the day.

We describe this condition as operational blindness. The organisation may be operating normally, but there are periods when it cannot see the actual condition of something important.

How Was the System Deployed?

Rather than trying to measure everything possible, the deployment concentrated on three important parameters: temperature, relative humidity and light.

LoRa sensors collected the readings from storage areas and sent them wirelessly to a gateway. The gateway transmitted the information through a 4G connection to the FAVORIOT Platform, where the data could be stored, displayed and continuously checked against configured thresholds.

Using wireless sensors and cellular connectivity also reduced dependence on new cabling and the museum’s internal network during the initial deployment.

The exact deployment duration was not recorded in the case study, so I would not attach an unsupported number of days or weeks to the project. What mattered was designing an architecture that could be deployed without unnecessarily disturbing the museum’s existing infrastructure.

What Changed for the Customer?

The biggest change was moving from scheduled observation to continuous awareness. Environmental conditions could now be monitored 24 hours a day, while alerts could reach designated personnel in less than 60 seconds when readings crossed configured thresholds.

The museum also gained a digital, time-stamped history of readings and events. Instead of manually collecting environmental readings during routine rounds, staff could rely on continuous data capture and focus their attention on situations that required intervention.

This is an important distinction. IoT should not simply create another task for employees. It should remove unnecessary work while helping people respond faster when their attention is genuinely needed.

Did It Save Costs?

We do not have documented figures showing the monetary savings from this project, so it would be misleading to claim a particular percentage or amount.

There were, though, clear areas where operational effort was reduced. Manual inspection rounds were no longer required specifically to collect environmental readings. The wireless architecture reduced the need for significant new cabling, while cellular connectivity reduced initial dependence on the museum’s existing network infrastructure.

For me, those are useful outcomes even before putting a ringgit value against them. Staff time has value. Avoiding unnecessary infrastructure work has value. Discovering an environmental problem earlier may have even greater value when the assets being protected cannot simply be replaced.

Connect, See and Act

This project explains our Connect • See • Act™ thinking very simply.

Connect means bringing conditions from the physical environment into the digital system through sensors and communications. See means turning those readings into continuous awareness, historical trends and alerts rather than occasional snapshots. Act means getting the right information to the right person while there is still time to respond.

The museum did not simply need more data. It needed to know when something was changing before that change became a bigger problem.

That is the difference between collecting data and creating operational visibility.

[Note: Favoriot Use Case – Museum Environmental Monitoring]

The Electricity Bill Arrives Too Late: Why Operational Visibility Matters

There is something interesting about electricity bills. They are very good at telling us what has already happened.

They can tell us how much electricity we consumed and how much we need to pay. For commercial facilities, they can also reveal the financial impact of Maximum Demand. The problem is that by the time we see the bill, the event that caused the cost may have happened weeks earlier.

That is a good example of what I call operational blindness.

The Problem Is Not Lack of Data

I recently looked at an IoT project developed to monitor Maximum Demand in real time. The problem it addressed was surprisingly common.

A large facility can have air-conditioning systems, computers, laboratory equipment, motors and other electrical loads operating simultaneously. At certain times, these loads can push electrical demand sharply upward.

Without continuous monitoring, the people managing the facility may not realise that a demand spike is happening.

The spike occurs. The cost is incurred. The bill arrives later.

Only then does somebody ask, “What happened?”

The organisation had data, but it did not have visibility when the information could still influence an operational decision.

Seeing the Problem While It Is Happening

The project approached the problem differently. Electrical parameters such as voltage, current, power factor and demand were continuously measured and transmitted through an IoT architecture.

Operators could then observe demand behaviour as it happened rather than depending entirely on periodic readings and historical bills.

During testing, the system captured a live demand peak of 664.8 kW, compared with 680 kW recorded for billing purposes.

That difference tells an interesting story. Real-time IoT monitoring can provide a sufficiently close picture of what is happening operationally to help people recognise potentially costly conditions earlier.

The Dashboard Is Not the Real Value

We sometimes become too fascinated by dashboards. We talk about graphs, gauges, sensors, protocols and cloud systems.

But nobody wakes up in the morning saying, “I need another dashboard.”

What the operations team really needs is an answer to practical questions:

Are we approaching a costly demand threshold?
When do our highest demand periods normally occur?
What activities coincide with those peaks?
Is something behaving differently today?
Should somebody act now?

That changes the purpose of IoT. We are no longer collecting data simply because we can. We are giving people enough visibility to make a decision while there is still time to act.

From Seeing to Predicting

The next step becomes even more interesting.

Once months or years of operational data have been collected, machine learning can begin looking for patterns that humans may miss. Instead of only showing that demand is high, the system could eventually warn that current conditions resemble patterns that previously led to a demand spike.

This moves us from monitoring towards early warning.

For me, that is where AIoT becomes meaningful. IoT allows us to see the physical world. AI helps us understand what those observations may mean.

Technology creates value when it shortens the distance between something happening and somebody knowing about it.

Because when the electricity bill finally arrives, the opportunity to change what happened last month is already gone.

[Note: This is one of Favoriot‘s Use Case – Energy Monitoring]

The Pump Was Running. But Could Anyone See What Was Really Happening?

Many IoT projects begin with technology. What sensor should we use? Which controller should we install? How will we connect the equipment to the cloud? After spending many years working with IoT projects, I have learned that these should not be the first questions.

I prefer to begin with something much simpler: What operational problem are we trying to solve? A recent airport water pump monitoring project illustrates why this question matters.

The Problem Was Not the Pump

Water pump motors are the kind of assets most people rarely think about until something goes wrong. In facilities such as airports, factories, commercial buildings and utilities, pumps may operate quietly for years while supporting critical operations behind the scenes.

The real problem was not whether the pumps could operate. The problem was that the people responsible for maintaining them did not have continuous visibility into their operating condition. Between routine inspections, a motor could begin behaving differently without anyone immediately knowing.

That creates what I call operational blindness. The equipment is running somewhere in the physical world, but the people responsible for it cannot continuously see what is happening.

The objective was therefore straightforward: monitor the behaviour of the pump motors remotely and provide enough visibility for the maintenance team to recognise abnormal conditions earlier.

This is where Connect → See → Act becomes useful as a way of thinking about IoT.

CONNECT: Bring the Physical Asset Into the Digital World

The first step was to capture electrical current from the pump motors using current sensors. The readings were collected through an industrial controller before being transmitted through an industrial communications gateway to a cloud-based monitoring platform.

This created a digital connection to equipment that previously depended heavily on local observation and periodic inspection. Data from the physical asset could now travel continuously from the field to people who needed to monitor it.

But connectivity alone does not solve the operational problem. Sending thousands of readings to the cloud only creates more data unless someone can understand what those readings mean.

SEE: Understand What Is Happening

Once the data reached the monitoring platform, engineers could observe pump behaviour remotely. They could view current readings, examine operating patterns and compare historical behaviour without physically visiting the equipment.

This changes the maintenance question. Instead of simply asking, “Is the pump running?”, the team can begin asking, “Is the pump behaving normally?”

That distinction matters. A machine can still be operating while its behaviour is beginning to change. Continuous visibility gives maintenance teams an opportunity to notice those changes earlier.

ACT: Respond When Something Changes

The final stage is where monitoring becomes operationally useful. Thresholds can be established so that unusual conditions generate alerts, allowing responsible personnel to investigate rather than waiting for the next scheduled inspection or an obvious equipment failure.

The complete process becomes simple to understand:

Connect the equipment and collect its condition data. See its behaviour remotely and recognise changes. Act when the information indicates that attention may be required.

That is Connect → See → Act.

The lesson from this project is not really about pumps, sensors or cloud platforms. It is about removing an operational blind spot. The best IoT projects are often not those with the most technology. They are the ones that help people discover what is happening in their operations early enough to do something about it.

[Note: This is one of Favoriot‘s Commercial Use Case – Pump Monitoring]

What Taiwanese Companies Taught Me About Building IoT Together

Knowing your place in the value chain

During my recent meetings with Taiwanese companies, one thing stayed with me. They understood clearly where they fit in the IoT value chain. Each company had its own area of focus, and its people could explain what they did well and how their capabilities might work with others.

Some specialised in hardware and connectivity. Others focused on sensors, gateways, energy systems, communications or software. They were not trying to own every part of the solution. They had chosen a role, built experience in it and were open to collaborating with companies whose strengths filled other gaps.

That way of thinking feels practical to me. IoT projects bring together many moving parts, from devices in the field to networks, data platforms and applications. It is difficult for one company to be equally strong in every layer. A well-matched group of partners can bring the right expertise together around a customer’s needs.

Where FAVORIOT fits

FAVORIOT’s role is to provide an AIoT platform for operational visibility. We help organisations collect data from connected assets, understand what is happening and respond when attention is needed. That role can sit alongside partners who provide devices, connectivity, specialist applications, deployment services or customer access.

For me, the meetings were a useful reminder that we do not need to own every layer to contribute meaningfully. We need to make our part of the stack useful, clear and practical to connect with the strengths of others.

A partner does not have to sell every part of a solution either. Each company can focus on what it knows best, while the group works out how those capabilities fit together for a particular project.

What a partner network can make possible

A network of companies with complementary strengths can offer customers several advantages:

More complete solutions: Customers can bring together devices, networks, platforms and services that suit their needs without relying on one supplier to cover everything.
Clearer project roles: When each partner knows its area of responsibility, planning and coordination can become easier.
Access to new markets: Partners can introduce one another to industries, regions and customer groups that would take longer to reach alone.
Faster delivery: Teams can combine existing products and experience instead of building every component from scratch.
More choice: Customers can compare options based on their budget, site conditions, preferred hardware and technical requirements.
Shared credibility: A trusted relationship with one partner can help a customer feel more comfortable meeting the rest of the team.
More routes to market: Several partner channels can create opportunities even when one sales route slows down.
Room to grow together: A successful project may lead to new services, markets and joint offerings.

A shared path forward

What I appreciated about these meetings was the clarity. The companies knew what they did well, and they were willing to discuss how their strengths could support a broader solution.

That is a useful lesson for IoT businesses. Growth does not always come from doing more things ourselves. Sometimes it comes from becoming very good at a clear role and building working relationships with others who bring different capabilities.

When every partner understands its contribution, the customer has a better chance of getting a solution that works as a whole. Each company also gains a clearer path to contribute and grow.

“Send Me a Proposal”: The Costly B2B Sales Mistake I Made as a Startup Founder

When a Proposal Felt Like a Breakthrough

In the early days of my startup, hearing a company say, “Send me a proposal,” felt like recognition. Someone had noticed our work and thought we might be able to help. I was happy to spend time on it because I could imagine the proposal becoming our first project with that customer. If it went well, perhaps a small project would grow into a long relationship.

A request worth millions of ringgit was even harder to resist. Before anything had been agreed, I found myself thinking about hiring, growth and what similar projects might mean for the next three to five years. For a founder building a company from the ground up, those possibilities feel real. They give you energy when the business needs it most.

The Work Begins Before the Deal Exists

My team and I would prepare the architecture, estimate the costs and ask partners for their prices. We wanted to give the customer our best answer. Yet sometimes we did not know enough about the site, devices, data, responsibilities or expected outcome to design a sound solution. When we asked, the reply was often, “Just give us your best proposal,” or “You suggest.”

That left us making assumptions about the scale of the work. We spent days debating options with partners and trying to price a project whose boundaries nobody had defined. The proposal might look complete when we submitted it, but much of it rested on guesses. Even a carefully written price could be wrong if the actual requirements later changed.

Then came the silence. Some customers never replied. Others said they would keep the proposal and budget for reference. Often, we never learned whether the project went to someone else, lacked funding, had no internal owner or was never ready to enter procurement. The hours we had spent preparing it were gone.

What Those Proposals Taught Me

That experience was frustrating because I had mistaken interest for commitment. A request for a proposal can be a serious step toward a project, but the words alone tell me very little. The lessons cost my small team time and money:

Find the problem owner. I need to know who will use the proposed solution, who is responsible for the outcome and who can approve the next step.
Ask what is known about the budget and timing. A customer may not have a final figure, but they should be able to explain whether funding exists and when a decision could be made.
Understand the buying process. A direct award, competitive tender and early market study call for different amounts of work.
Record what remains unknown. If key requirements are missing, I should not present assumptions as firm scope or a final price.
Protect the team’s time. Preparing a detailed design has value. Giving it away repeatedly leaves fewer resources for customers who are ready to act.

These are practical business lessons I did not learn at university. I learned them while trying to keep a startup moving with limited people and cash.

A Different Answer Today

When someone now asks for a large proposal without a clear scope, I first ask about the problem, budget, timeframe, project owner and procurement route. If they need us to investigate requirements, work through the architecture and develop a costed plan, I propose a paid consultation. It gives the customer something more useful than a proposal built on guesses, while allowing us to put proper care into the work.

I still welcome a genuine opportunity. I also understand that a proposal request may be the start of a conversation, rather than a sign that a project is ready. It took me longer than I wish to learn that distinction. The cost was real, but so was the lesson: a founder must believe in what the company can build and know when to ask whether the customer is ready to build it with them.

From Teaching IoT to Solving Real Problems: Lessons I Learned the Hard Way

Looking back at my years of building IoT solutions, I can see how much the conversation around IoT has changed. In the beginning, our challenge was convincing people that IoT mattered. Later, people wanted to learn how to build it themselves. Today, building an IoT prototype has become much easier, especially with generative AI helping people write code and solve technical problems. Yet one uncomfortable reality remains: the IoT market has not grown as quickly as many of us expected.

That experience has forced me to rethink what customers actually need from IoT. After years of developing FAVORIOT, conducting training, working on projects and watching pilots succeed technically but struggle commercially, I have learned that the biggest challenge is rarely the technology itself. The harder question is whether we are solving an operational problem that matters enough for someone to take ownership, allocate a budget and keep the solution running.

The Early Days Were About Explaining IoT

In the early days, many of our conversations started with a basic question: “What is IoT?” People had heard the term, but few understood how sensors, connectivity, cloud platforms and applications could work together. We spent considerable time educating customers, students and organisations about what IoT could do and why connecting physical assets could change the way operations were monitored.

At that time, simply demonstrating the technology could create excitement. When someone saw a sensor transmitting data to a cloud platform and displaying the information on a dashboard, it felt like something new. We could demonstrate remote monitoring, automatic alerts and real-time data collection, and people immediately became curious about the possibilities. We believed that once awareness increased, adoption would naturally follow.

Then People Wanted to Build IoT Themselves

As awareness grew, the questions changed from “What is IoT?” to “How can I build an IoT solution?” This created another chapter for FAVORIOT, where training became an important part of what we did. We conducted many IoT programmes involving sensors, Arduino, ESP32, Raspberry Pi, MQTT, cloud platforms, dashboards and application development.

The appetite for learning was strong because people wanted practical experience. Students wanted to build projects, lecturers wanted to introduce IoT into teaching and research, while engineers and professionals wanted to understand how connected systems could be applied in their organisations. IoT was gradually moving from something people heard about at conferences into something they could actually build with their own hands.

Then generative AI arrived, and we noticed another shift. Demand for traditional IoT training appeared to decline. One possible reason is that people can now ask an AI assistant how to connect an ESP32, generate MQTT code, troubleshoot an error or explain how a sensor works. Knowledge that once required attending a two-day workshop can now be accessed within minutes.

If IoT Is Easier to Build, Why Is the Market Still Slow?

This became an uncomfortable question for many IoT solution providers, including us. Sensors became cheaper, connectivity improved, platforms matured and technical knowledge became easier to obtain. Generative AI lowered the technical barrier even further, yet the commercial market for IoT still seemed to move much more slowly than the technology.

For a long time, we believed demonstrating stronger technology would help overcome this problem. We showed customers devices, dashboards, alerts, analytics and different ways of connecting physical assets. A good demonstration could attract attention, lead to discussions and sometimes result in a pilot project. Technically, many of these pilots worked exactly as expected.

The problem came afterward. Some pilots simply stopped. The sensors were working, data was flowing and dashboards were displaying information, yet the project never expanded. We slowly realised that proving technology could work was very different from proving that an organisation needed it badly enough to continue investing in it.

A Successful Pilot Can Still Become a Failed Project

That experience taught us to ask a different question: who owns the project after the pilot? Someone might approve an experiment, another department might provide the equipment and an IT team might help with connectivity, but nobody may actually be responsible for turning the pilot into part of daily operations.

Without operational ownership, a pilot can easily become a technology showcase rather than a working system. If nobody is accountable for the problem being addressed, nobody feels enough urgency to expand the solution. There may also be no operational budget, measurable outcome or internal champion willing to push the project beyond its experimental stage.

This changed the questions I now believe we should ask at the beginning of an IoT project. What operational problem is the customer experiencing? Who suffers when that problem occurs? What does the organisation lose when the problem remains invisible? Who receives the information generated by the system, and what action will that person take? Most importantly, who owns the outcome after the pilot finishes?

Customers Rarely Wake Up Wanting IoT

A maintenance manager probably does not arrive at work thinking about buying an IoT platform. He may simply want to know whether a remote pump has stopped running before someone complains. A facilities manager may want to understand why electricity consumption suddenly increased, while an environmental officer may need an early warning when water quality begins moving outside acceptable limits.

The same applies to energy systems, buildings, factories and remote assets. Customers are usually concerned about downtime, wasted energy, unnecessary site visits, equipment failures, delayed responses and things happening in their operations that they cannot see quickly enough. IoT becomes valuable when it helps expose those problems early enough for someone to act.

This has changed the way I think about FAVORIOT as well. Connecting devices remains necessary, but connection alone is not the outcome. Data must help someone see something they could not previously see, understand what is happening and decide what to do next. That is why Connect → See → Act represents something much deeper to me today than simply describing how an IoT platform works.

Lessons I Learned the Hard Way

After years of explaining IoT, teaching people how to build it, developing our own platform and watching projects move through different stages, several lessons have become difficult to ignore.

Awareness does not automatically create demand. Someone can understand IoT very well without having a strong enough operational reason to buy a solution.
Technical success is different from commercial success. Getting a sensor to transmit data and displaying it beautifully proves that the technology works. It does not prove that the organisation will continue paying for it.
Every pilot needs an operational owner. Someone inside the customer’s organisation must care about the outcome, be responsible for the problem and have enough influence to move the project forward.
Start with the pain, not the platform. Conversations about downtime, energy losses, unnecessary site visits, equipment failures and delayed responses are usually more meaningful than conversations about protocols, dashboards and technical specifications.
IoT creates value when visibility leads to action. Collecting more data is not enough. The real value comes when information helps someone recognise a problem earlier and respond before the consequences become more expensive.

Perhaps this has been one of the hardest lessons from building IoT solutions over the years. We spent the early years proving that IoT technology worked. We then spent years teaching people how to build it. Today, I believe the conversation has to move beyond both.

The future of IoT will not be decided by how many sensors we can connect or how impressive our dashboards look. It will be decided by whether we can help organisations see operational problems they could not see before and give the right people enough information to act.

That lesson took years of projects, pilots, training programmes, successes and disappointments for me to fully appreciate. Stop trying to sell customers IoT. Find the operational problem they desperately need to see, and make that problem visible.