Excel AI Automation — How Far It Goes and Why Re-Keying Survives

“We rolled out Copilot, but the amount of Excel work on the shop floor hasn’t moved.” It is one of the most common things you hear from Japanese-owned factories in Thailand. Excel AI automation genuinely moved forward through 2026, but what it actually improves is the processing side of the work — the aggregating, the formulas, the report formatting. The hours people spend re-keying numbers from a daily production report into a stock sheet, and from the stock sheet into a management sheet, barely move at all. This article breaks factory Excel work into three layers and five job types, and lays out a boundary you can apply to your own site: where AI alone is enough, and where you need to connect systems to each other.

What Excel AI automation actually means — a three-layer model of input, processing, and distribution

“We want to automate our Excel work” is a sentence that reliably falls apart the moment a meeting starts. The administration manager is picturing the monthly close and the reporting pack. The plant manager is picturing the block of time his shop-floor staff spend typing every morning. The person who handles IT alongside another job is picturing the sprawl of files and the mismatched versions. The same phrase — “Excel work” — is pointing at three separate problems.

The fastest way out of that confusion is to split Excel work into layers. In a factory, the work done in and around Excel sorts cleanly into three.

Defining the three layers

Once you see the three layers side by side, the usual confusion makes sense. The processing and distribution layers look like white-collar work, so they are visible to management. The input layer is buried inside shop-floor routine, so almost nobody counts it as hours. Yet when a factory actually inventories its total Excel hours, the input layer is usually the thickest of the three. The time per person is short, but the number of people and the number of repetitions are an order of magnitude larger.

Each layer jams for a different reason

The three layers get stuck for three different reasons, and that distinction is the whole point of the model.

The processing layer jams because only a few people can build anything. In most factories, the number of people who can combine VLOOKUP, pivot tables, and a macro is very small — sometimes one. When that person is on leave, the monthly close stops. When a formula breaks, nobody can repair it. This is a skills problem and a key-person-dependency problem.

The distribution layer jams because there are too many formats. The table used inside the factory, the table sent to head office, the table produced for audit, and the table sent to the customer are all different, so the same numbers get reshaped four times. This is a requirements problem and a coordination problem.

The input layer jams because the source data does not exist in machine-readable form. What actually happened on the line lives on paper, on a whiteboard, or in somebody’s head, and a step in which a human types it on a keyboard is therefore unavoidable. This is neither a skills problem nor a coordination problem. It is a problem with how the data comes into existence.

That distinction is decisive. Skills problems and coordination problems sit close to what AI is genuinely good at. Problems with how data comes into existence do not change just because you put an AI assistant inside Excel.

Sorting “Excel is painful” complaints by layer

If you take the complaints that come up from the floor and assign each one to a layer, the appropriate response changes. The table below maps the phrases you hear most often.

If you listen only to the words and conclude “let’s buy an AI that automates Excel,” you end up buying a processing-layer tool to answer an input-layer complaint. That is by far the most common route to “we rolled out Copilot and the shop floor still does the same amount of Excel.”

What AI can actually do in Excel in 2026 — where Copilot in Excel and Claude for Excel stand

Before drawing any boundaries, it is worth confirming where the tools actually are. Excel plus AI in 2026 is a different thing from the “chatbot that explains formulas” of a few years ago.

Copilot in Excel: repetitive work can now be held as a reusable pattern

In June 2026, Microsoft 365 Copilot rolled out a set of new capabilities for Copilot in Excel. Three of them matter in day-to-day factory practice.

The first is Skills, which lets you package a repeated workflow as a reusable instruction. For a factory that runs the same aggregation through the same steps every month, that means the procedure itself can be registered once and then called.

The second is personalisation, which applies guidance on formatting, naming conventions, formulas, pivot tables, and report style consistently across an entire workbook.

The third is the workbook rules sheet: you record that workbook’s own rules for structure, formatting, naming, and formulas in a dedicated .Rules sheet, and every editor then works to the same guidance.

The third one looks unglamorous, but it is the one that tends to pay off in a factory where several people touch the same management workbook. Until now, a workbook’s local rules — this column is always plain ASCII, dates are YYYY-MM-DD, part numbers carry leading zeros, and all the other unwritten conventions — existed only in the head of whoever built it, and degraded a little at every handover. Those rules can now live inside the workbook itself.

On top of that, Copilot in Excel draws relevant context automatically from email, meeting records, chat, and files through Work IQ while you edit, and it supports Plan mode and Python. Microsoft 365 Copilot as a whole has, since early 2026, moved forward with integration of Anthropic’s Claude and with the practical rollout of specialist agents such as Researcher, Analyst, and the Word, Excel, and PowerPoint Agents — a shift, as it is generally described, from using a chatbot to working alongside AI.

Claude for Excel: reading the dependency structure of the whole workbook

Anthropic’s Claude for Excel entered beta in October 2025 and reached general availability in May 2026. It sits in the Excel sidebar, builds an understanding of the workbook as a whole, maps formula dependencies and cell-reference structures that span multiple tabs, and then analyses, manipulates, and proposes changes at the cell level. It is positioned to let you build financial models, run data analysis, and produce reports without leaving Excel, and it is available on the Pro plan as well.

The part that lands hardest in factory practice is “maps formula dependencies that span multiple tabs.” A production-control workbook that has been in service for years almost always consists of many sheets referencing each other. Workbooks that nobody dares touch — because nobody knows which cells break when you change one — are not unusual; they are effectively frozen. Simply having something that can read the dependency graph makes that freeze far easier to break.

How the two tools are positioned differently

Arguing about which one is better is not a very useful exercise. What matters far more is a fact that applies to both: their strengths are concentrated in the processing and distribution layers. Turning workflows into patterns, applying rules across a workbook, mapping dependencies — in every case the object being worked on is data that is already inside Excel.

The limit they share

The limit common to Excel-plus-AI in 2026 comes down to a single sentence. AI can only read what is inside the workbook, and it cannot create what is not there.

As long as what happened on the line is written on a paper check sheet and that sheet is sitting in a cabinet, no amount of intelligence resident inside Excel will produce that data. As long as equipment run data sits inside a PLC and never reaches the network, Excel will never see it. This wall is not a performance problem; it is a path problem. Better models do not grow new paths.

Breaking factory Excel work into five job types: re-keying, aggregating, decision support, reporting, sharing

The three-layer model is useful for thinking, but it is too coarse for measuring. When you actually inventory your own Excel hours, five job types are easier to count.

Defining the five types

The five types map onto the three layers straightforwardly: type 1 is the input layer, types 2 and 3 are the processing layer, and types 4 and 5 are the distribution layer.

How to inventory your own Excel hours

To move the discussion from opinion to evidence, it is worth running a one-off inventory. It requires no special tooling and takes little time to get started.

1. List, department by department, the Excel files actually used day to day. Writing down the file name and where it is stored is enough to begin.
2. For each file, ask the people who use it who touches it, when, and for how many minutes.
3. Classify each piece of that work into one of the five types. Where one file spans several types, count them separately.
4. Total up “number of people × number of repetitions × minutes” for each type.
5. Finally, for every piece of work classified as type 1 (re-keying), add one line describing where the source data lives.

Step 5 is the heart of this article. Any line where that answer reads “on paper,” “verbally,” “on a whiteboard,” or “on another system’s screen” is work that will not disappear when you put AI inside Excel.

When factories run this inventory, the same pattern tends to emerge. By number of tasks, aggregating and reporting stand out. By total elapsed hours, re-keying is the largest by some distance. The reason is simple: aggregation and reporting happen a few times a month and involve a limited number of people, while re-keying happens every day, across multiple people, and often across multiple sites.

The double-entry loops the inventory always finds

One thing an inventory always surfaces is places where the same number gets typed twice or more. In Japanese-owned factories in Thailand, the following loops come up repeatedly.

Systemisation is generally understood to pay off most in areas that are used every day, where mistakes translate directly into loss, and where double entry is common — which in manufacturing tends to put inventory, process control, and billing at the top of the list. The table above overlaps with exactly those areas.

The four types AI removes, and the one it doesn’t

So what happens when you apply the state of Excel-plus-AI in 2026 to those five types? The short answer: types 2 through 5 have substantial room to shrink, and type 1 barely moves.

Types 2 and 3, aggregating and decision support: the processing layer responds well

Aggregation is where AI works most reliably. The data is already inside the workbook, and the job is arithmetic. Register your monthly aggregation procedure as a Copilot in Excel Skill and next month becomes a matter of calling the same instruction. With Claude for Excel, you can have it read the formula dependencies of an existing aggregation workbook and surface broken references and duplicated calculations.

The gain here is not only time. In practice, the bigger benefit is likely to be the removal of key-person dependency. If the aggregation procedure is recorded as a rule inside the workbook, the monthly close is much less likely to stall when someone changes role. In an organisation like a Thai subsidiary, where expatriate assignments rotate on a cycle, that effect is not something to dismiss.

Decision support sits close to what AI does well, but it needs care. Extracting outliers and flagging delayed processes are easy things to delegate; judging whether that outlier is actually a problem requires shop-floor context. Hand that judgement over wholesale and the warnings AI produces start being ignored on the floor, and eventually nobody looks at them at all.

Realistically, the more stable design is to have AI produce a list of candidates and keep the judgement with people. Mechanisms such as Work IQ, which can pick up context from internal email and meeting records, are likely to compensate for part of this weakness — but only part.

Types 4 and 5, reporting and sharing: the output side shrinks as a block

Reporting sits between the processing and distribution layers. It is the work of taking already-aggregated numbers, shaping them into a fixed format, and adding narrative and charts. AI cuts a lot of this. It cuts especially hard at factories that reshape the same numbers three times — once for internal use, once for head office, once for the customer.

At sites where multiple languages are involved, the effect is larger still. Turning shop-floor records written in Thai into a Japanese head-office report and an English customer report is squarely within what AI does well.

Sharing is less about AI and more about mechanism. “Which version is current?” and “someone overwrote it” are not problems AI solves. What it can take off your hands is the surrounding work: drafting the covering report, summarising what changed since the last version.

Type 1, re-keying: barely moves

And then there is re-keying. This is the subject of the article, and the area where putting AI inside Excel changes the least. The next section deals with why in detail.

The map by type

There is one way to read this table. The preconditions for types 2 through 5 can all be arranged inside Excel. The precondition for type 1 is the only one that sits outside it.

Why re-keying is the one thing AI can’t remove — the “no source data” problem

Boiled down, the reason re-keying survives fits in one sentence. The data that re-keying starts from either does not exist digitally at all, or exists but is locked inside a different system.

AI cannot create data that isn’t there. That obvious fact gets overlooked with surprising regularity in discussions about Excel automation.

Pattern 1: the point of origin is paper, speech, or memory

This is the most common case. Production results, equipment downtime reasons, visual inspection outcomes on incoming goods — the first recording medium for all of it is a paper check sheet, a whiteboard, or the supervisor’s memory.

In that state, getting the data into Excel necessarily means a human striking a keyboard. Putting AI on the Excel side does nothing, because paper does not appear in that AI’s field of view.

The available response is AI-OCR: scan the paper, read it, and turn it into structured data. Combinations in which generative AI or OCR reads images and PDFs and RPA handles the registration downstream are indeed spreading. But AI-OCR has preconditions of its own — the form layout has to be stable, handwriting quality has to clear a threshold, and there has to be a path for verifying misreads. We have covered how to choose in this area in our comparison of AI-OCR tools, so if paper is your primary cause, that is the faster place to start.

The more fundamental response is to digitise the point of origin itself. Put a tablet or terminal on the floor and have people enter directly instead of writing on paper. Or capture results straight from the equipment. If nothing passes through paper, there is nothing to scan and nothing to re-key.

Pattern 2: digital, but locked inside another system

This is the second most common case. The data does exist digitally — inside the accounting system, inside the production control system, inside the attendance system, or inside an equipment controller. But those systems are not connected to each other, so a person reads one screen and retypes the numbers into Excel.

From the outside this state looks “already digitised,” which is exactly why it is hard for management to see the problem. On the floor, though, the daily routine is still: open system A’s screen, read the numbers, type them into Excel, then type them into system B as well.

The response here is connection. There are several routes — APIs, automated CSV interchange, an intermediate database, RPA driving the screens. The total market for RPA solution services continues to grow: JPY 99.9 billion in FY2024 actuals, a forecast JPY 111.4 billion for FY2025, and a projected JPY 124.2 billion for FY2026. In combination with generative AI, a division of labour has spread in which generative AI handles the flexible work — summarising, classifying, drafting text — while RPA handles the routine work on either side of it: acquiring data, registering it, sending notifications, transferring it between systems. In other words RPA was not replaced by generative AI; it has survived by changing role, becoming generative AI’s hands and feet.

Pattern 3: digital, but not structured

The third pattern is the one most often missed. The data is inside Excel. But as a table it is broken. Merged cells everywhere, several meanings packed into one row, two-tier headers, and the same part number appearing as “A-100,” “A100,” and “a-100.”

In this state, asking AI to aggregate will not return a correct answer. And because the reason it fails lies in the structure of the input rather than the capability of the model, switching models changes nothing. What settles in on the floor instead is a verdict: “AI doesn’t work here.”

The response is normalisation: one record per row, one value per cell, a single header row, and a unified coding scheme. It is unglamorous work, but skip it and every downstream investment stops paying.

Telling the three patterns apart, and judging whether AI alone is enough

To let you make the call for your own site, here is the boundary as a table. The more of these you answer on the left-hand side, the more likely it is that Excel plus AI alone will be enough.

If three or more items fall on the right-hand side, it is likely that deploying an AI tool alone will not change how the work feels. That profile matches the symptom set long identified as the classic limits of running a factory on Excel: mistakes from manual entry, broken formulas, the difficulty of simultaneous editing by several people, the inability to see inventory in real time, key-person dependency created by files tied to one specific PC, information lost through overwrite-saves during concurrent editing along with the version confusion that follows, and files that bloat as record counts grow.

The important thing is not to read this as “stop using Excel.” In the processing and distribution layers, Excel remains genuinely powerful and pairs well with AI. The problem is continuing to use Excel as the container for the input layer.

Three additional constraints that apply at Thai sites — multiple languages, information control and PDPA, and staff retention

Everything so far applies equally to a factory in Japan. At sites in Thailand — and across ASEAN — three further constraints sit on top.

Constraint 1: multiple languages multiply re-keying

In Thai factories, records on the floor are commonly in Thai, internal management sheets are in Japanese or English, and customer submissions are in English or Japanese. That three-language split generates re-keying by itself. Reading a daily report written in Thai and re-entering it into a Japanese management sheet is translation and re-keying happening at the same time.

There is a good side and a bad side to this. The good side is that the translation part is something AI is exceptionally good at. The bad side is that the presence of translation makes the “a person reads it and retypes it” step feel justified, which tends to postpone any discussion of systemisation.

The sound response is to make the entry interface multilingual, so that the record is captured once and the display switches by language. Holding the same data in separate files per language means every update happens two or three times, and before long nobody knows which one is right.

Constraint 2: information control and PDPA

Letting AI touch your Excel means the contents of those workbooks become material processed by an AI service. Factory workbooks frequently contain costs, customer names, unit prices, yields — and personal data such as employee names and attendance records.

Thailand has a Personal Data Protection Act (PDPA), under which handling personal data requires a stated purpose and a lawful basis. Layered on top of that are the Japanese parent company’s information management rules, non-disclosure agreements with customers, and the site’s own operating rules. Unless you decide in advance which data may be given to which AI service, people on the ground will start using tools on individual judgement, and control becomes very hard to reassert afterwards.

In practice, three things are worth settling as a minimum. First, the classification of the data you handle (public, internal only, confidential, personal data). Second, which AI services and which plans are permitted for each classification. Third, what happens when a rule is broken, and who to ask when in doubt. We have covered this down to the level of specific clause structure in our article on drafting a generative AI usage policy, so a site without a policy in place is safer arranging that first.

One note of balance: control that is too tight means nobody uses the tools, and control that is too loose means incidents. Sites where this is genuinely working tend to run a two-tier arrangement — workbooks containing costs and personal data only inside a designated environment, everything else free to use in normal work.

Constraint 3: retaining local staff and securing talent

Labour costs in Thailand are on an upward trend, and securing capable local staff is becoming harder. For Excel-based operations, that situation cuts two ways.

One is that key-person risk rises. When the staff member who built out the management workbook leaves, that workbook becomes a black box nobody will touch. The other is that the cost of an operating model premised on manual re-keying keeps climbing. Adding people to keep up stops being a viable assumption.

On the environmental side, though, there is a tailwind. Investment applications for Thailand’s digital industries in the first quarter of 2026 were 2.4 times the same quarter a year earlier, and the BOI is actively courting investment in data centres, cloud, and AI development, with corporate income tax exemptions of up to 13 years available. The investment environment for the digital domain is, in other words, coming together.

Cost and sequencing — three steps and the right investment order

With all of that laid out, the sequence becomes visible. The important thing is not to get the order of investment wrong.

Step 1: hand the processing layer to AI (you can start immediately)

The first move is to hand types 2, 3, and 4 — aggregating, decision support, and reporting — to AI. Because the source data is already inside the workbook, you can start without any additional system investment.

Concretely, that means registering the aggregation procedure you repeat every month as a Copilot in Excel Skill, recording the workbook’s naming and formatting conventions in a .Rules sheet, and having Claude for Excel read and untangle the formula dependencies of an existing workbook that has grown complicated.

The value of this step is less the time saved than the fact that the organisation gains a concrete sense of what can reasonably be delegated to AI. Without that, the investment decision at the next step is very hard to get approved.

Step 2: digitise the point of origin

Next, make the source data behind type 1 machine-readable. The targets are the lines in your inventory where you wrote “paper” or “verbal.”

The method depends on the situation. If the forms are stable, read them with AI-OCR. If entry can move to the floor, put a terminal there. If results can be taken from the equipment, capture them directly over the network. Which one to pick is best decided by how often the work occurs and whether mistakes translate directly into loss. If you need to prioritise, the usual top candidates in manufacturing are inventory, process control, and billing.

Because this step changes how the floor actually works, trying to do all of it at once is a reliable way to fail. Starting with one process on one line, showing that it works, and then expanding is the realistic path. We have covered how to run that approach in practice in our article on starting small with system implementation.

Step 3: connect system to system

Last, connect the data that is locked inside separate systems — through API integration, an intermediate database, or RPA acting as a bridge. Once you get here, the situations in which the same number is typed twice disappear structurally.

Having AI process data on the far side of those connections is when the benefit you first tasted in Step 1 starts working at its real scale. If you have ambitions to let processing run autonomously across that scope, our article on implementing AI agents sets out how to think about permission design and scope of application.

Investment order, and how to think about cost

The third row is the classic failure named at the top of this article. The fourth is more common than you would expect: a site accepts a proposal to “connect the systems together,” but the production data that mattered was still on paper, so nothing flows through the connection that was built.

How to think about cost. The amount varies enormously with tool mix and scale, so no single figure is meaningful. But breaking the cost structure into three parts makes it easier to see clearly.

Step 1 is mostly licence cost with little implementation cost. Steps 2 and 3 shift the weight towards implementation cost. That is precisely why the realistic order is to produce visible proof of benefit in Step 1, and then go after budget for Steps 2 and 3.

A decision checklist. You can work out which step you are currently at with the following questions.

The first row where the answer is no is the place to start next.

Frequently asked questions

How far can Excel AI automation actually go?

Aggregation, analysis, formula authoring, and report formatting applied to data that is already inside an Excel workbook are areas where, as of 2026, a great deal can be cut. Re-keying — the work of getting data that lives outside the workbook into it, whether that is a paper daily report, a verbal handover, or another system’s screen — does not change when you put AI on the Excel side. The clearest way to think about the boundary is that it falls on whether the source data is inside the workbook or not.

Should we choose Copilot in Excel or Claude for Excel?

They serve different purposes, so ranking one above the other is not very meaningful. If Microsoft 365 is already deployed across the company and you want context from internal email and meeting records to be part of the picture, Copilot in Excel is the natural fit. If your need is to read and understand the structure of an existing workbook that has grown complicated, and to map formula dependencies spanning multiple tabs, Claude for Excel suits that better. It is also worth noting that Microsoft 365 Copilot itself has been progressing with integration of Anthropic’s Claude, so the either-or framing is likely to loosen further. If the decision is genuinely close, decide based on whether your Excel hours lean more towards analysis or more towards formatting and distribution.

Is RPA still necessary for automating re-keying?

There are still cases where it is. The total market for RPA solution services is projected to grow from JPY 99.9 billion in FY2024 actuals to JPY 111.4 billion forecast in FY2025 and JPY 124.2 billion forecast in FY2026, so it has not been displaced by generative AI and disappeared. The accurate reading is that its role has changed: generative AI handles the flexible work such as summarising, classifying, and drafting text, while RPA handles the routine work on either side of it — acquiring, registering, notifying, and transferring data. With generative AI or OCR reading images and PDFs and RPA writing the results into business systems, the range of processes that can be automated has widened to include work that was previously hard to reach. At sites still running older business systems with no integration interface, RPA is likely to remain a realistic option for some time.

How do we judge when Excel has reached its limit?

You can judge by symptoms. Frequent mistakes from manual entry; broken formulas that nobody can repair; the inability of several people to edit at once; no real-time inventory visibility; key-person dependency created by files tied to one specific PC; information lost through overwrite-saves during concurrent editing, with version control in disarray; files that bloat as record counts grow until they take minutes just to open. These have long been identified as the classic warning signs.

When several of them appear at the same time, it is likely you have entered a stage that clever use of Excel will not reverse. In particular, when “no real-time inventory visibility” and “information lost during concurrent editing” are both present, it is probably time to start considering moving the container for the input layer off Excel altogether.

Is there an information-security risk in letting AI touch our Excel files at a Thai site?

We would suggest settling your own rules before evaluating any tool’s specifications. Factory workbooks frequently contain costs, customers, unit prices, and personal data such as employee names and attendance records, and Thailand’s PDPA, the Japanese parent company’s information management rules, and non-disclosure agreements with customers all apply at once.

In practice, the arrangement that runs most smoothly is to divide data into classifications (public, internal only, confidential, personal data), define which services and plans are permitted for each classification, and designate someone to consult when unsure. If people start using tools individually before any rules exist, reasserting control afterwards is difficult. Our article on generative AI usage policies covers how to draft one.

How much does it cost?

The figure varies greatly with configuration and scale, so no single number can be quoted, but estimates are easier to compare if you split cost into licence cost, implementation and setup cost, and running cost. The stage of handing the processing layer to AI (Step 1) is mostly licence cost and involves almost no additional system investment. Claude for Excel is available on the Pro plan as well, so trying it at small scale first is not difficult.

Steps 2 and 3 — digitising the point of origin and connecting systems to each other — shift the weight towards implementation cost in proportion to the number of target processes, the complexity of the forms, and the number of sites. Producing visible proof of benefit in Step 1 and then going after budget for Steps 2 and 3 is the realistic order, not least because it makes internal approval easier.

Summary

When you set out to evaluate Excel AI automation, the first thing worth doing is breaking Excel work into the three layers — input, processing, distribution — and the five job types: re-keying, aggregating, decision support, reporting, sharing. Copilot in Excel and Claude for Excel as they stand in 2026 deliver real, dependable benefit in the processing and distribution layers: aggregation, analysis, formulas, report formatting. You can start there without additional system investment, and the side effect of removing key-person dependency is substantial in its own right.

The input layer — re-keying, and the thickest block of Excel hours in a factory — does not disappear when you put AI on the Excel side. AI can only read what is inside the workbook, and it cannot create data that isn’t there. The reasons re-keying survives sort into three: the source data is on paper or in speech; it is locked inside another system; or it is inside Excel but structurally broken. The response therefore follows an order: hand the processing layer to AI, digitise the point of origin, then connect system to system. Skip that order and the likely conclusion is the familiar one — “we brought in AI and the shop floor still does the same amount of Excel.”

At Thai sites, three further constraints sit on top: multiple languages, information control including PDPA, and the difficulty of securing staff. None of them determines whether AI can be adopted; they are things to settle in advance as design assumptions.

Working out how much of your own Excel work AI tools alone can cover, and where system-side integration becomes necessary, is a call you can make internally once the inventory is done. Having examples of how other sites drew that line simply makes the call faster. TOMAS TECH builds production management and energy management systems for Japanese-owned manufacturers across Thailand and ASEAN, and we are happy to talk through the boundary question on its own. If it would help — even at the stage of just wanting to make sense of your current Excel practice — you are welcome to get in touch through our contact page.

References

• What’s new in Microsoft 365 Copilot: June 2026 (Windows Blog)
• Where Microsoft 365 Copilot stands today (Business+IT)
• What Claude for Excel is (notAI)
• An explanation of Claude in Excel (INNOTEX)
• The limits of Excel-based management and seamless workflows (Totec Sangyo)
• The limits of process control in Excel (SMART GO)
• The limits of Excel management and when to move on (mactism)
• RPA solution services market research (MIC Research Institute)
• RPA and generative AI in combination (Hitachi Solutions)
• Thailand investment incentives and the BOI (JETRO)
• Digital industry investment trends in Thailand (Bangkok Shuho)