Thailand Manufacturing IoT Case Studies 2026 — 5 Patterns, 5 Boundaries

If you have spent any time reading Thailand manufacturing IoT case studies, you have probably hit the same wall. Every write-up says roughly the same thing — sensors were installed, data was collected, the floor was made visible — and yet the moment you try to map it onto your own plant, you have no idea what to do first. The problem is not a shortage of information. It is that case studies are almost always read through the lens of “what did they install.” This article puts the dividing line somewhere else: what separates an IoT rollout that takes root from one that stalls at the PoC stage is whether the team decided, before measuring anything, which decision the data would feed. From there, we work through how to re-read case studies so they become reproducible. This is not a list of other companies’ projects.

Why IoT adoption is accelerating in Thailand in 2026

“IoT is trendy in Thailand too” is not a basis for a decision. The increase has concrete drivers that land directly on a plant’s P&L, and if you cannot articulate them, you cannot answer the one question every internal approval process asks: why now?

There are three drivers: a structural change in labour costs, a shift in the investment environment through the BOI, and real money moving on the market side. We will take them in order.

Labour costs: the move toward a uniform 400 baht and the 4.64% Japanese-affiliate wage increase

Thailand’s minimum wage was revised in January 2025 to a range of 337 to 400 baht per day across most provinces. In July 2025, all industries in Bangkok were unified at 400 baht per day. For 2026, a nationwide uniform rate of 400 baht is widely expected, but it is not a settled policy as of today. If you are writing this into an approval document, keep the wording at the level of “widely expected.”

The more important number, however, is not the minimum wage — it is the pay-rise rate at Japanese-affiliated companies. That rate has moved from 3.8% in 2023 to 4.58% in 2024 and a projected 4.64% in 2025. On top of that, engineers and technical staff have been seeing annual increases of 5 to 8%.

These two figures behave differently. Minimum wage revisions bite mainly at the operator level, while 4.64% and 5–8% bite at the unit cost of the core people who actually keep the plant running. It is the latter that matters in an IoT investment case, because what IoT usually replaces is not operator labour — it is the time core staff spend walking the floor to check status, writing it on paper, and compiling it into reports.

The judgement call in this section. If you try to justify IoT investment as “headcount reduction,” the argument almost always strains. It turns into a conversation about cutting operators, which drags labour-relations risk into the room. Instead, frame it as how many hours you recover, and from which tasks, of the technical and managerial staff whose unit cost is rising 5 to 8% a year. One hour a day transcribing daily reports, eight hours a month on monthly aggregation, ten hours a month reconstructing why a machine stopped — whether you can write at that level of granularity is usually what determines whether the approval goes through.

The BOI investment climate: 649 projects, 330,132 million baht, and a digital tilt

For the first quarter of 2026, the Thailand Board of Investment (BOI) recorded 649 approved projects worth 330,132 million baht. On the applications side — a separate tally from approvals — the value passed 1.01 trillion baht across more than 600 applications, driven by the digital and electronics sector against the backdrop of AI demand.

Two things follow from this. First, the centre of gravity of Thailand’s industrial promotion has clearly shifted toward digital. Second, the room for IoT-related capital investment to be treated as eligible for incentives has widened.

Here are the BOI incentives most relevant to IoT investment.

The two most frequently overlooked are the 200% training deduction and the import duty exemption. The top reason IoT projects fail is consistently “the people who are supposed to use it never get up to speed” — and the fact that the cost of addressing that can itself qualify for an incentive changes how you build the plan.

The judgement call in this section. Whether to build your investment plan on the assumption of BOI incentives should come down to how you weigh the application effort against the timing at which the benefit becomes certain. Eligibility varies with each company’s business activities and existing promotion certificates, so a plan built on “we should be able to use this” collapses entirely if approval does not come through. In practice, the safe construction is to build a plan that stands on its own without incentives, and pull it forward if the incentives land. For the detailed cost structure, the Factory IoT implementation guide 2026 breaks costs into five layers, and that is the piece to work from when you are assembling the numbers for approval.

What the market is doing: roughly JPY 54 billion in smart-factory investment, up more than 10% year on year (press reports)

On Thailand’s factory smart-manufacturing market, NNA has reported a market size of roughly JPY 54 billion with expected growth of more than 10% year on year. The same reporting names Chinese automotive and home-appliance manufacturers among the leading investors. (The article is paywalled, so we deal only with the gist here.)

Read this number carefully. “The market is growing, so we should do it too” is not a reason. What is worth reading is the breakdown of who is investing. Reporting that names Chinese manufacturers as investors can also be read as a signal that competitors making the same products inside Thailand are moving first on production visibility and changeover speed. For a Japanese-affiliated plant, the pressure sits there, not in the headline market size.

On the Japanese side, activity is also verifiable from public sources. NEC has published information describing, among Japanese-affiliated initiatives, the deployment of an equipment-utilisation visualisation IoT platform at a major Thai food manufacturer, and a predictive system for equipment failure and quality defects at a Japanese-affiliated automotive parts maker. (Neither company is named.)

What matters here is that the publicly described cases fall into just two shapes: “visualising equipment utilisation” and “predicting failures and quality defects.” Nothing exotic. In the five patterns we cover in the following sections, these correspond to pattern A and to patterns B and C. The fact that these two shapes are the ones most readily discussed in public is itself a useful signal about where to start.

The judgement call in this section. If you are going to use other companies’ cases as evidence in an investment decision, do not look at “which company installed what.” Look at which pattern the publicly discussed cases cluster around. The patterns that cluster are the ones whose results are easy to explain and hard to get wrong. Conversely, choosing a pattern for which you can find no precedent anywhere is a poor trade for whoever has to stand up and explain it internally first.

How to read IoT case studies properly — the four-part set

This is the core of the article. Unless you change how you read case studies, no amount of collecting them turns into a plan for your own plant.

Why “what did they install” cannot be reproduced

Put a Thai plant where IoT took root next to one where it stalled at PoC, and the equipment configuration is almost identical. Pick up the stack light with an optical sensor, take signals from the PLC, aggregate through a gateway to the cloud, view it on a dashboard — as long as you are talking about configuration, the success case and the failure case draw the same picture.

The difference sits in exactly one place: whether, before measuring, the team decided “when this number moves, who does what.”

This is not a motivational point; it drives system design directly. If you have decided that “when this number moves, the production engineering lead reports the cause at the next morning meeting,” then what you need is a daily close and a screen that shows yesterday’s figures by 07:00. If instead you start from “let’s see everything in real time for now,” you end up with a design that accumulates second-by-second data, bandwidth and storage balloon, and nobody ever uses that granularity.

“What did they install” cannot be reproduced because what was installed is a result, not a cause. The cause sits one step earlier, in the design of the decision.

There is another classic path to a stalled PoC. Sensors go on two machines, data is collected for a month, and a nice chart appears. The chart is shown at the review meeting. Someone asks, “Right — so what do we do with this?” No answer. That is where it stops. A plan that treats the appearance of a chart as the deliverable is structurally incapable of answering that question. The only plans that can answer it are the ones that decided the answer before the PoC started.

Problem → what you measure → the decision it feeds → the number that changed

To read a case study in a reproducible form, extract these four things as a set. Conversely, a case study that does not supply all four may be interesting reading, but it is not material for a plan.

The order matters too. In practice, you do not decide 1 through 4 in sequence — you decide 3 and then go back to 2.

An example. Say the problem is “machines seem to be down a lot but we do not know the reality.” The straightforward path makes “run/stop” the thing you measure. But consider decision 3 first: “once we know the downtime, who does what?” If the answer is “production engineering goes after the causes of the long stoppages,” then what you need is not total downtime but the breakdown of stop reasons. Which means run/stop alone is not enough — reason entry at stoppage (selected on a shop-floor terminal) becomes mandatory.

If, on the other hand, the answer is “the plant manager uses the real utilisation rate as an input when building next month’s production plan,” then what you need is not a reason breakdown but a utilisation figure closed over a period. In that case, asking the floor to enter reasons only adds workload without affecting the decision.

Starting from the same problem, how you settle 3 changes what you measure, what you ask the floor to do, and what it costs. That is the real explanation for “identical equipment configurations, different outcomes.”

What it looks like rewritten as a four-part set

For reference, here is the way case studies are usually written next to the same thing rewritten as a four-part set. The following is not a real company’s project; it exists to compare two ways of writing.

The judgement call in this section. When reading someone else’s case study — or writing your own plan — start from 3, the decision it feeds. If the only thing you can put in slot 3 is “share it at the management meeting,” the plan is not yet ready to carry an investment decision. Only once “who,” “when,” and “decides what” are all filled in can you narrow down what to measure.

Five patterns of factory IoT in Thailand

The IoT projects people talk about at Japanese-affiliated plants in Thailand sort, in practice, into five patterns. Below, each is laid out along the four-part set from the previous section. Read these as type patterns — generally reported configurations plus the shapes we commonly encounter on site — not as individual company projects. The magnitude of improvement varies enormously between companies and is not something that can be asserted.

Here is the overview.

Now each in detail.

Pattern A: Equipment utilisation visualisation (starting from stack lights and PLCs)

The most common pattern and the one most often chosen as a first step. The major Thai food manufacturer described in NEC’s public information falls into this pattern as written (deployment of an equipment-utilisation visualisation IoT platform; company not named).

What you measure. Whether a machine is running or stopped, and if stopped, why. Do not make the reason a free-text field; the standard approach is a selection list of roughly six to eight categories. Start with something like changeover, material wait, minor stoppage, breakdown, quality check and planned stop, then add or remove categories as operation reveals the reality.

How you pick it up. Broadly two ways: read the illumination state of the stack light (signal tower) with an optical sensor, or take signals from the PLC. The former requires touching nothing on the existing machine, so electrical work permits and machine-downtime coordination are minimal. The latter is more accurate and can capture output count and cycle time, but it depends on the PLC’s manufacturer, model and communication specification, and it may run up against the machine builder’s warranty conditions. In plants with a lot of older equipment, the realistic approach is a two-stage one: spread coverage with the stack-light method first, then switch only the critical machines to PLC connection. The methods themselves are laid out option by option in Retrofitting IoT onto legacy equipment.

The decision it feeds. This is what decides whether the pattern succeeds. Two decisions work well:

• At the next morning meeting (07:30–08:00), review the top three stoppages by duration from the previous day and assign a cause owner and countermeasure owner on the spot.
• Monthly, use the real utilisation rate as the planning assumption for next month’s production plan (replace the denominator in the plan with the measured value).

The first connects to the shop-floor improvement cycle; the second connects to planning accuracy. One of them is enough. Aiming at both from day one changes the required data granularity and blurs the design.

Where it goes wrong. Stop-reason entry does not survive. That is the whole story. Entering a reason on a floor terminal is pure additional work from the operator’s point of view. If the result of entering reasons never comes back to the floor — i.e. entering changes nothing — the entry rate collapses within a month. The fix is not technical, it is operational: keep showing the floor that their entries moved something, in the form of “there was a lot of material wait yesterday, so we’re checking with purchasing.”

When to choose this pattern. If you have not decided where to start, this is almost always the answer. Three reasons: you can begin without touching existing equipment, the result is explainable with a single number (downtime), and the later patterns (B and E) sit on top of this one.

Pattern B: Catching early signs of equipment failure

The Japanese-affiliated automotive parts maker in NEC’s public information (deployment of a predictive system for equipment failure and quality defects; company not named) is described in terms that straddle this pattern and pattern C.

What you measure. Physical quantities — vibration, current, temperature, pressure — captured continuously as time series. The point is not to “detect abnormal values” but to accumulate the normal-state trend over a long period and watch for deviation from it. Which means that immediately after deployment you learn nothing. Until enough baseline normal data has accumulated, there is a period of several months to half a year during which no judgement is possible.

The decision it feeds. “When an early sign appears, order the spare part and pull maintenance forward to the next planned shutdown.” That is the destination. Put the other way round: in a plant where spare-parts stocking policy and maintenance planning are not settled, an early warning leaves you with nothing to do about it.

Where it goes wrong. Three places. First, management cannot wait out the “no judgement possible” period described above. Second, threshold setting is hard, and alerts that fire too often start getting ignored. Third, on machines that rarely fail, the training data never accumulates. Trying to catch early signs on a machine that breaks once a year means waiting years for the data to arrive.

When to choose this pattern. It comes down to whether you can narrow the scope. If you can pin down one to three machines where “if this one stops, the whole plant stops,” the pattern works. If you cannot pin them down and spread it across “all major equipment,” the cost and effort do not pay back. This pattern also comes after pattern A as a rule. Chasing failure precursors while you cannot even see run/stop is the wrong order.

Pattern C: Making in-process defects traceable

What you measure. Inspection results (good/defective, defect category), the process conditions at that moment (temperature, pressure, time), and the linkage to the product lot. The third is the most important and the most commonly missing.

The decision it feeds. “When the customer reports a defect, identify the range of product made under the same conditions and decide whether to hold or release the shipment.” That decision is a race against the clock.

Where it goes wrong. The granularity of the linkage. Linked at lot level, you can narrow the range; linked only at day level, the scope becomes “everything produced that day.” Granularity cannot be refined after the fact. Going back and making historical data finer is impossible in principle, and this is the most expensive regret in pattern C.

The other failure mode: if even one process still holds its inspection results on paper, the trace breaks there. Digitise nine processes and leave one on paper, and defects originating in that one process cannot be traced.

When to choose this pattern. If the effort spent handling customer complaints has become a problem, or if a ship/hold decision takes more than a full day, the cost is justified. Conversely, a plant with almost no complaints starting from this pattern “for the future” will struggle to explain the return. On isolating defect causes, Quality data management systems breaks the subject into three layers, and if you are considering this pattern, reading that before you start designing is the faster route.

Pattern D: Seeing power and energy per process

What you measure. Not just the incoming supply point, but energy by circuit and by machine. Metering the incoming point alone does not count as this pattern — for that, the utility bill is enough. The value of this pattern lies in being able to allocate the plant’s total electricity cost to processes and machines.

The decision it feeds. Mainly three: reviewing contracted demand, shifting the operating hours of the machines that create the peak, and allocating power cost into product costing.

Where it goes wrong. The outcome is essentially decided by where you place the measurement points. Measure too finely and CT (current transformer) installation cost and electrical work balloon; measure too coarsely and you cannot tell which machine is consuming what, so it never connects to a decision. The test is simple: “when the number at this measurement point moves, is there an operational change we can actually make?” Measuring something you cannot change only adds cost.

When to choose this pattern. It works if electricity cost is a non-negligible share of the P&L. The thinking behind measurement-point design is covered in Factory power monitoring systems, and reading it before you start designing can cut the number of measurement points substantially. This is also one of the few patterns you can run in parallel with pattern A, because power metering can be built independently of PLCs and production data.

Pattern E: Remote monitoring of the Thai plant from Japan HQ

What you measure. Nothing new. You simply make the data already captured in pattern A viewable from Japan. Misread this and you start scoping a separate “remote monitoring system,” at which point the project balloons.

The decision it feeds. Decisions on the headquarters side: prioritising capital investment, deciding whether to dispatch support staff, and reconciling the Japan-side production plan with the reality in Thailand.

Where it goes wrong. Three places. First, trying to make the HQ screen and the shop-floor screen the same screen. The floor wants to see today. HQ wants to see monthly and quarterly trends. The granularity and the time window are both different. Satisfying both on one screen produces a screen that is awkward for everyone.

Second, HQ starting to use the floor’s numbers as surveillance. Once “a query arrives from HQ in any week where utilisation dips” becomes the norm, the floor starts behaving so the numbers do not look bad. Data reliability degrades structurally. The first thing to settle in this pattern is not technical — it is the operating rule that these numbers will not be used in personnel evaluation.

Third, network and security. How data travels from the Thai site to Japanese headquarters — VPN, or via the cloud — depends on the policy of HQ’s information systems department. This is not something the local site can decide alone, and it is a classic reason projects are slow to start. Whether you bring HQ IT in while the plan is still being drafted locally is worth about three months.

When to choose this pattern. If business travel has dropped and headquarters has lost sight of what is actually happening on the floor, this has value. It is not a pattern to start on its own, though. It presupposes that pattern A is running, and the right framing is “adding a way to present what already exists.” On how to view cost and payback, Overseas plant IoT and remote monitoring covers the ground, and that is the piece to work from when preparing material for headquarters.

Five boundaries that separate projects that stick from projects that stall

We have covered the patterns, but even within the same pattern some sites make it stick and others stall. In our experience the difference concentrates in five places. None of the five is a technical issue.

Boundary 1: Was the decision settled before measuring

We have hammered this point already, but of the five boundaries it produces the widest gap. The test is easy: before the PoC starts, can you write even one sentence of the form “when this number does X, this person does Y”? If you cannot, the plan will very likely end with a chart.

The remedy when you cannot is equally simple. Before measuring, observe how decisions are currently made. Who builds the production plan, and when? Who gets called when a machine stops? Who judges when a defect appears? Inserting data into decisions that already exist is by far the surest route. Trying to create a decision that does not yet exist means standing up the system and the operating routine at the same time, and the difficulty jumps.

Boundary 2: Whether the viewer is Thai staff or an expatriate

Underestimate this boundary in a Thai plant and it will almost certainly fail to stick. The reason is simple: expatriates rotate out in a few years; Thai staff stay.

Three things matter concretely.

UI language. Can the dashboard and the shop-floor terminal be used in Thai? The depth of English-capable staff varies a lot by plant, and assuming English all the way down to the operators near the line is usually unrealistic. The parts touched daily — the stop-reason selection list, above all — need Thai.

Duty roster. Is “the person who checks the data every morning” defined by job title? Defined by individual name, it stops the moment that person transfers. Define it by title and the routine survives a change of personnel.

Handover. Does a written procedure exist in Thai, and can a newcomer read it and operate from it? Only when you get this far does the system survive expatriate rotation.

The judgement call at this boundary. Make “can this support a Thai-language UI” a mandatory check item during vendor selection. Bolting on multilingual support later, once the screen count has grown, costs sharply more. Also worth noting: Thai-language support is not a translation problem — it is the problem of matching the option wording to how the floor actually talks. The phrasing people actually use raises entry rates more than the dictionary-correct term does.

Boundary 3: Whether the design lets you refine granularity later

This one is technical, but it carries weight because it is irreversible.

As a rule, data captured coarsely cannot be refined afterwards. If you stored only hourly aggregates, then when someone later asks to see it in ten-minute intervals, the historical data simply is not there. The reverse — capturing finely and aggregating later — is always possible.

That does not make “store everything at second resolution forever” the right answer. Storage and bandwidth costs bite, and in practice almost none of it gets used. The practical compromise looks like this.

The judgement call at this boundary. What you need to decide at design time is not the storage granularity itself but which data you are most likely to want at finer resolution later. In our experience that concentrates on two things: stop reasons and defect-to-lot linkage. Those two, and only those two, are worth capturing finely from the start.

Boundary 4: How far you touch existing equipment (electrical work and acceptable downtime)

This is the most physical reason plans stall. Fitting sensors requires stopping the machine, electrical work requires licences and permits, and PLC work may run up against the machine builder’s warranty conditions.

Three issues are particularly acute in Thai plants.

Timing of machine downtime. The higher the utilisation, the less time available to stop. If you plan around the year-end holidays or Songkran (April), missing that window can mean waiting six months. Scheduling backwards from the installation window fits reality better.

Machine builder warranty. If you are connecting to the PLC, you need to check the builder’s warranty conditions. There is a risk the warranty lapses, or that fault isolation becomes a dispute when something goes wrong. Fix the installation date before doing this check and the project stops at the last minute.

Electrical work licences and contractors. You will need licensed local contractors. Whether the plant’s existing maintenance contractor can handle it or a separate arrangement is required changes the lead time.

The judgement call at this boundary. Start by asking whether there is a way to avoid touching existing equipment at all. Optical sensors on stack lights, clamp-on CTs and similar — prioritising non-contact, retrofit-only methods makes most of the problems at this boundary disappear. The loss in accuracy can be recovered by narrowing the scope and switching those machines to PLC connection. The available options are laid out in Retrofitting IoT onto legacy equipment.

Boundary 5: Whether the system survives expatriate rotation

Go back to a site two years after deployment and find nothing running, and there is a common pattern behind it: the expatriate who drove the project returned to Japan, and the successor could not pick it up.

What it takes to prevent that comes down, in practice, to four things.

1. A duty roster written by job title (not by individual name)
2. A Thai-language operating procedure (with screenshots)
3. A monthly forum where the numbers are reviewed (built into an existing meeting as an agenda item; do not create a new one)
4. Vendor and support contact details plus contract terms, held as local documents

The fourth is the one that goes missing. If the deployment correspondence exists only in the departing expatriate’s personal mailbox, the successor has to start by working out what has even been contracted.

The judgement call at this boundary. Write “the four items above exist as documents held locally” into the completion criteria of the deployment project. Make go-live the completion criterion and those four items generally never get produced.

Practical issues specific to plants in Thailand

General IoT guides do not cover these, but in a Thai plant they always come up.

Power and connectivity: in-plant Wi-Fi, the rainy season, lightning and outages

In-plant Wi-Fi. Drop an office-grade access point into a factory and the signal simply will not reach. There is metal equipment, high ceilings, forklift traffic and electrical noise. Where the IoT gateway sits and how it communicates from there (Wi-Fi, wired, LTE) has to be decided after taking real measurements on site. Proceeding on a desk-based design and discovering on installation day that there is no signal is not at all unusual.

Rainy season and lightning. Thailand’s rainy season, roughly May to October, brings a lot of lightning. Outdoor cabling and equipment without surge protection get destroyed by lightning surges. Equipment used for power monitoring in particular, and anything installed near outdoor incoming switchgear, should have surge protection budgeted from the start. Fixing it after something fails means data gaps in the meantime.

Power outages. In areas with brief outages and voltage fluctuations, gateways and servers go down every time. Whether to install a UPS depends on “does it come back automatically?” If the configuration does not auto-recover, checking the auto-recovery settings is cheaper than buying a UPS. An operating routine that requires someone to walk to the equipment and reboot it after every outage will definitely not last.

The judgement call on this issue. Connectivity and power problems are largely preventable with a single site survey at the design stage. Put “half-day site survey” explicitly into the PoC plan. Plans that skip it always slip at the production design stage.

Sequencing when you use BOI incentives and import duty exemption

Of the incentives covered earlier, the one that actually generates procedural work in an IoT investment is mainly the import duty exemption. Sensors, gateways, edge devices, industrial robots, GPUs and similar can qualify.

What you need to get right is the order. You cannot import the equipment and then apply for the exemption. The flow is: submit the list of target equipment in advance, obtain approval, and then import. Which means you need to put out a broad list before equipment selection is finalised — and that has a direct effect on the project schedule.

Separately, the 200% training cost deduction may be usable for the education costs of an IoT rollout. Operator training and maintenance training for local staff can qualify. This too has to be arranged in advance, not after the fact: decide the training plan and how records will be kept before you run it.

The judgement call on this issue. Since eligibility varies with each company’s situation, consult your BOI contact (internal or advisory) early in the project and settle “usable or not usable” quickly. Carrying “we might be able to use it” forward tangles both the equipment selection and the application schedule. As noted earlier, building a plan that stands without incentives is the safe construction.

Thai-language UI, the duty roster, and handover to local staff

Some practical additions to what boundary 2 covered.

Deciding the terminology. The stop-reason options and the screen labels should follow how the floor talks, not the dictionary. The method is straightforward: show the draft screens to two or three senior Thai staff and have them rephrase the wording. Thirty minutes spent on this step changes the entry rate.

Designing the training. Do not finish it with a single classroom session. For the first month after go-live, hold a session — fifteen minutes a week is enough — where you look at real data together and confirm what each number means. Hand over a screen without teaching people how to read the numbers and it will not be used.

The unit of handover. Write the procedure as a workflow, not as a feature description. A procedure written as “in the morning, open this screen → check the top three stoppages from yesterday → report at the morning meeting” can be handed over. A procedure that opens with “how to read the chart” cannot.

The judgement call on this issue. Whether a handover succeeds can be predicted almost entirely by whether the procedure is written in the order of the work. In a project review, this single point is worth checking.

Maintenance: who can physically touch it locally

After go-live, physical trouble is guaranteed: sensors come loose, terminals break, connections drop. When that happens, if who handles first response locally is undefined, the data from that machine goes missing, and gaps eventually become the norm.

The realistic structures are one of the following.

The judgement call on this issue. Settle the maintenance structure at the same time you are collecting implementation quotes. Sites that start thinking about maintenance after go-live tend to see operation stop at the first failure and never come back. Even just keeping a handful of spare sensors on hand changes recovery time dramatically.

One more thing: how to connect to upper-level production systems (MES or ERP) does not need to be decided at this stage. In sequence, it is something to consider once utilisation data is being captured reliably; starting the upper-system discussion first tends to stall everything. The boundaries between them are laid out in MES implementation cost and approach.

Where to start — the first 90 days

Now to convert all of the above into an execution sequence. The structure is to split 90 days into three blocks of 30 and decide in advance what exists at the end of each.

For overall timing, a common guideline is: problem inventory 2–4 weeks → PoC 1–2 months → production design and development 2–4 months → installation, migration and training 1–2 months, for a total of 6–12 months. The 90 days below are the front half of that.

Days 0–30: Problem inventory and settling on a single KPI

What you do. Walk the floor and collect the pain points in plain sentences. Do not talk about sensors or vendors at this stage. Then map what you collected into the four-part set format described above, paying particular attention to filling in “the decision it feeds.”

Narrow to a single KPI. Chasing several KPIs simultaneously blurs the PoC design. If it is downtime, it is downtime; if it is energy, it is energy. If you cannot narrow it down, that means the priority among problems has not been settled — and you are not yet at the PoC stage.

The judgement to make in this period. Can you write in one sentence “when this single KPI moves, who decides what, and when”? If you can, move on. If you cannot, extending this period is faster in the end.

Days 31–60: PoC (1–2 machines)

Scale guideline. A typical PoC runs 1–2 months, costs JPY 500,000–1,000,000, and covers fitting sensors to one or two machines. A PoC beyond that range is not a PoC — it is a small production deployment.

What the PoC actually tests. Confirming that data can be captured is, in fact, not the main purpose. Technically it almost always can be. What you need to test is the operating routine.

• Does stop-reason entry work without interrupting the operator’s work (what is the entry rate)?
• Used in the morning meeting, does an actual discussion happen?
• Does the connection stay stable (including in wet weather, if it is the rainy season)?
• When Thai staff look at the screen, does it mean anything to them?

The judgement to make in this period. During the PoC, actually execute the decision you defined at least once. Run the real process: report the top three stoppages at the morning meeting and assign a countermeasure owner. If it does not work when you run it, it will not work in production either.

Days 61–90: Set the expand-or-stop criteria in advance

The most important thing is not to think about these criteria on day 61. Write down, back in the 0–30 day block, “what state of the PoC means we go to production, and what state means we stop.”

Some example criteria.

On the cost outlook. As a sense of production scale, the guideline investment for a small or medium enterprise at Level 1 (visualisation) under the METI guidelines is put at JPY 3–10 million. It is standard to plan ROI on a 3–5 year payback. When you estimate production cost from the PoC results, it is worth checking once whether you land inside that range. If you are far outside it, the scope has probably grown too wide or you are capturing more granularity than you need. How to break the cost down is handled in five layers in the Factory IoT implementation guide 2026.

Build the people problem into the plan. Survey results report that more than 85% of companies cite a shortage of DX personnel, in both quantity and quality, as a cause of failure. What that number means is that a plan not built on the assumption that people are short will fall over. When you draft the 90-day plan, confirm what percentage of their time the assigned person can actually give. If there is no dedicated resource, decide up front what you will outsource.

The judgement to make in this period. Build the decision forum into an existing meeting (the monthly plant meeting, for example). Setting up a new review meeting burns two weeks on scheduling alone.

Frequently asked questions

Where can I find Thailand manufacturing IoT case studies?

There are three main public sources: case studies published by vendors and system integrators (often with the company unnamed), reporting and research from organisations such as JETRO and NNA, and seminar material from industrial estates and industry associations.

That said, how you read matters more than where you look. A case study that does not supply the four-part set from this article — problem, what you measure, the decision it feeds, the number that changed — may be interesting reading, but it is not material for your own plan. Very few case studies state “the decision it feeds,” so when it is absent, read while asking yourself “who at this company looks at this number and decides what?” That makes it far easier to map onto your own situation.

How much does IoT implementation cost in Thailand?

It varies enormously with scale and scope, so there is no single answer. As a guideline, figures cited include JPY 500,000–1,000,000 for a PoC (sensors on one or two machines, 1–2 months) and JPY 3–10 million as the SME investment guideline for Level 1 (visualisation) under the METI guidelines. It is standard to plan ROI on a 3–5 year payback.

How to break the cost down for estimation (hardware, connectivity, cloud, development, operations and maintenance) is covered in detail across five layers in the Factory IoT implementation guide 2026. This article deliberately does not go into the cost breakdown.

Can we get results like these case studies with only old equipment?

Yes. In fact, in plants with a lot of old equipment, the impact of utilisation visualisation is often easier to explain, because newer machines frequently keep their own logs and part of the picture is already visible.

For older machines, reading the stack-light illumination state with an optical sensor captures run/stop without touching the machine’s control system at all. That method barely depends on the machine’s vintage. For the range of capture methods and their respective accuracy, cost and installation burden, see Retrofitting IoT onto legacy equipment.

Can we monitor our Thai plant’s operating status from Japan?

Technically, yes. As covered under pattern E, nothing new needs to be measured — you simply make the data already captured in Thailand viewable from headquarters.

Two practical cautions, though. First, keep the HQ screen and the shop-floor screen separate. The granularity and time window they need are different, and sharing one screen makes it awkward for both. Second, settle the operating rule that these numbers will not be used in evaluation, before you start. Once they are used as surveillance, the floor starts manufacturing the numbers and the data itself loses reliability.

On top of that, the network route and security policy usually fall under headquarters’ IT department. Bringing HQ in during the early planning stage shortens the time to kick-off.

Can BOI incentives be used for IoT investment?

Possibly. The most relevant are the additional 3 years of corporate income tax exemption under technology upgrading (measure 10.1), the 200% deduction of training costs, and import duty exemption on IoT sensors, industrial robots, edge devices, GPUs and similar. It is also worth checking the surrounding framework: corporate income tax exemption of up to 8 years (up to 15 years combined with EEC), and a 50% reduction for 5 years after the exemption period.

Eligibility, however, varies with each company’s business activities and existing promotion certificates. And import duty exemption requires advance application — you cannot apply after importing. The practical approach is to consult your BOI contact early in the project to settle eligibility, and, separately, to hold a plan that stands without any incentives.

What should we settle so the PoC does not stall?

Three things.

First, write the decision it feeds in one sentence. “When this number does X, this person decides Y, at this time.” A PoC without that sentence ends with a chart.

Second, actually execute that decision at least once during the PoC. Evaluate on whether the process you defined ran, not on whether data was captured.

Third, write the proceed/stop criteria before the PoC starts. Decide the criteria after it ends and you get “let’s watch it a bit longer,” which quietly turns into nothing. Write the criteria as numbers — data gap rate, entry rate, count of countermeasures assigned.

All three fit on a single sheet of paper before the PoC begins. If you cannot write them, you are not yet at the PoC stage — that is the position this article takes throughout.

Summary

The points to hold onto when reading Thailand manufacturing IoT case studies:

• Behind the increase in 2026 sit a 4.64% wage increase at Japanese-affiliated companies with 5–8% annual rises for engineers, the BOI’s digital tilt (649 approvals worth 330,132 million baht in Q1 2026), and an expanding smart-factory market (roughly JPY 54 billion, up more than 10% year on year, per press reports)
• Case studies cannot be reproduced when read as “what did they install.” Read them as a four-part set: problem → what you measure → the decision it feeds → the number that changed
• There are five practical patterns: A equipment utilisation visualisation, B failure precursors, C in-process defect traceability, D energy by process, E remote monitoring from headquarters. If you have not decided where to start, A is the answer
• Five boundaries separate what sticks from what stalls: was the decision settled first, is the viewer Thai staff, can granularity be refined later, is the scope of intervention in existing equipment agreed, and does it survive expatriate rotation
• The Thailand-specific issues are in-plant connectivity, rainy-season lightning and outages, advance application for BOI incentives, Thai-language UI and duty rosters, and who provides local first-line maintenance
• The first 90 days: days 0–30 problem inventory and one KPI, days 31–60 PoC (1–2 months, JPY 500,000–1,000,000, 1–2 machines), days 61–90 the decision. Write the decision criteria back in the 0–30 day block

One last time: what separates a successful IoT project from a failed one is neither technology nor budget. It is which decision you decided the measured data would feed. With that one point settled, the equipment configuration can be adjusted freely afterwards. Without it, no amount of good hardware prevents the outcome from being one nice chart and nothing else.

TOMAS TECH supports Japanese-affiliated manufacturers in Thailand on the ground, from equipment utilisation visualisation through to quality and energy data use. “We have not decided where to start” or “we ran a PoC but it has not gone anywhere” is a perfectly fine place to be — in fact, sorting things out at that stage tends to save rework later. We can begin simply by walking your floor and working out together what to measure and which decision it should feed. If you are still at the exploratory stage, you are welcome to get in touch through our contact page.