AI Meeting Minutes for Thai Plants – the Four Fault Lines Behind Transcription Accuracy

Search for “AI meeting minutes” and the first thing you find is a comparison of recognition accuracy. But accuracy is not why automatic meeting minutes stop being usable at a Japanese-owned factory in Thailand. Meetings that switch between Japanese, Thai and English. Part numbers and process names that are not in any dictionary. Decisions that were never actually spoken aloud. And Thailand’s PDPA. These four fault lines break your minutes behind the accuracy figures. This article uses a three-layer model, four product archetypes and a five-layer cost model to show you exactly how to close them.

Start with where you actually stand – minutes rank high among generative AI use cases, but your meetings are not monolingual

The Japanese numbers say minutes have become a mainstream use case

How far has generative AI actually gone inside Japanese companies? According to news coverage of the White Paper on Information and Communications 2026, published by Japan’s Ministry of Internal Affairs and Communications on 24 July 2026, 86.4% of Japanese companies with 10 or more employees that have begun digitalisation use generative AI somewhere in their own operations. The survey ran from January to February 2026 and covered 515 respondents in Japan.

The qualifier matters here, and it must not be dropped. That 86.4% is not “86.4% of Japanese companies”. It is the share within a population of companies that have already begun digitalisation and that have 10 or more employees. Companies that have not started digitalising, and businesses with fewer than 10 employees, are not in that denominator. If you quote the figure internally without the qualifier, you manufacture a false sense of urgency — “nine out of ten companies are already using this” — and the discussion stalls the moment someone answers, “our suppliers certainly are not.”

For the breakdown by use case, the previous edition offers a clue. In the Communications Usage Trend Survey behind the White Paper on Information and Communications 2025, 47.3% of Japanese companies using generative AI cited “assistance with email, meeting minutes, document preparation and similar tasks” as a use case. Alongside text generation and translation, minutes sit closer to day-to-day operations than almost any other application.

In other words, automating meeting minutes is not an emerging frontier use case. It is already one of the leading applications, which is precisely why the products and the marketing material are abundant — and why a bad selection decision is easy to wave away as “well, that’s AI for you”.

The Thai numbers say adoption has happened but has not matured

What about Thailand? According to coverage of the AWS report “Unlocking Thailand’s AI Potential 2026”, 43% of Thai companies now use AI on a regular basis, up sharply from 32% the year before. Judged on growth alone, that looks like rapid diffusion.

The same research, however, adds a second finding. 74% of the companies that have adopted AI remain at an early stage, relying mainly on off-the-shelf tools. Three quarters of adopters, in other words, have not moved beyond using a purchased tool exactly as it came out of the box.

Put those two numbers side by side and you get an accurate description of a scene you see constantly at Thai subsidiaries.

• Someone has switched on the transcription feature that came bundled with the meeting app, on their own initiative
• The Japanese expatriate reads the transcript that comes out and then rewrites the minutes anyway
• The Thai staff do not use the transcript at all, because it comes out in a language they cannot read
• Nobody believes anything has been “adopted”, so neither the cost nor the benefit appears in any ledger

This is not even a failure. It is a state of being stuck before adoption has begun. And the reason it is stuck is usually not the tool’s capability. It is one of the four fault lines that are the subject of this article.

Meetings at a Japanese-owned Thai plant are not monolingual to begin with

The single biggest reason you cannot transplant Japanese survey findings straight into a Thai operation is the language composition of the meetings themselves. At a typical Japanese-owned factory in Thailand, the reality looks roughly like this.

On top of that, it is far from unusual for the person actually writing the minutes to be a Thai staff member writing in Japanese. A conversation heard in Thai is converted into Japanese and reshaped into a format a Japanese reader expects — a double conversion performed inside one person’s head, every single time. Introducing an AI minute-taker here means asking a machine to take over that double conversion. The capability required is nothing like transcribing a monolingual meeting.

This is why “just pick the product with the highest transcription accuracy” does not work as a selection criterion on this shop floor. Accuracy figures are measured on a single language under good capture conditions, and reproduce none of the conditions just described.

AI meeting minutes are built from three layers – capture, conversion and distribution

Without the three layers, you cannot locate the cause of a problem

As long as you look at an AI minute-taker as a single black box, the only vocabulary available to you is “the accuracy is bad”. In reality the processing splits into three layers, and both the failure points and the remedies differ by layer.

• Capture layer — whose voice is picked up, with what equipment, at what quality. Microphone placement in the meeting room, individual microphones in web meetings, how the interpreter’s audio is handled
• Conversion layer — automatic speech recognition (ASR) that turns audio into text, and the large language model (LLM) that turns text into a summary and extracted decisions. Custom dictionaries and speaker diarisation belong here
• Distribution layer — who receives the minutes, when, in what format, where they are stored and when they are deleted. Approval flow, searchability and retention periods live here

Of these three, product marketing addresses mainly the conversion layer. Accuracy, number of supported languages, summary quality. Yet the reasons minutes fall out of use on the shop floor cluster in the capture and distribution layers.

Typical symptoms by layer

Using this table is simple. When your minutes are not being used, first determine which row the symptom falls into. No amount of higher-accuracy modelling will fix a capture-layer problem, and no amount of dictionary registration will fix a distribution-layer problem.

Design the capture layer around separating utterances, not around counting microphones

The most common failure in face-to-face meetings is placing a single smartphone in the middle of the conference table to record. Sound intensity falls off in inverse proportion to the square of the distance, so remarks from the person seated at the end of the table drop below the recognisable floor. If the holes in your transcript are concentrated on specific individuals, this is the cause.

There are only two remedies. Install omnidirectional conference microphones sized to the room, or stop meeting face to face and have everyone join a web meeting from their own PC. The latter costs nothing, but audio in the same room feeds back, so in practice it requires everyone to wear earphones. Enforcing that at every meeting in a factory conference room is not realistic, so the pragmatic split — put equipment into the rooms where minute-taking meetings are held — tends to stick better.

Recognise that the conversion layer has two stages

The conversion layer places two processes of quite different character in series — speech recognition and a language model. Unless you separate them, you cannot isolate a cause.

Speech recognition errors are visible in the raw transcript. Language model errors show up in a different form — the source text is correct but the summary is wrong. The latter is the more troublesome of the two. Because the source text is correct, anyone reading only the summary has no way of noticing the error.

For that reason, make sure the raw transcript is retained during the early phase of operation. If your configuration saves only the summary, you have no material left to verify against once an error surfaces.

Five items to decide in the distribution layer

The distribution layer is the most neglected, yet it is what determines whether the minutes become a document that gets used or a document that merely gets generated. Decide these five items before going live.

• Who receives them (attendees only, related departments, escalation to management)
• By when they are distributed (target time after the meeting ends. The next business day is already late enough to cause rework)
• In what language they are distributed (Japanese only, Japanese and Thai side by side, varying by department)
• Where they are stored (shared folder, intranet portal, business system)
• When they are deleted (retention period, which connects directly to PDPA compliance)

Of these, “when they are deleted” is undecided in the large majority of organisations. The retention period for minutes that include audio data is something you will end up deciding under fault line 4 below.

The four fault lines that break your minutes – what happens behind speech recognition

Once the three-layer model has told you where the problem sits, the next question is what kind of cause it is. At Japanese-owned Thai factories, the reasons minutes become unusable organise into four categories. This article calls them fault lines, because like a geological fault the assumptions on the upper layer and the lower layer are displaced against each other, and the displacement never shows on the surface.

What the four have in common is that none of them can be judged from the figures on a product specification sheet. The number of supported languages tells you nothing about fault line 1. The CER tells you nothing about fault line 2. Summary quality evaluations tell you nothing about fault line 3. And no product material touches fault line 4 at all.

The next four sections deal with each of them in turn.

Fault line 1 Language – what unit do you cut a mixed Japanese, Thai and English meeting into

Speech recognition is built on the assumption of one language per meeting

Most AI minute-takers make you choose a single language when the meeting starts. That is a technical convenience. Speech recognition models differ by language in phoneme inventory and vocabulary distribution, so handling several languages simultaneously at high accuracy is harder than handling one. Even products that advertise multilingual support in practice either detect the language automatically and settle on one, or switch by segment — and in the latter case errors cluster at the switching boundaries.

Apply a tool built on that assumption to a meeting mixing Japanese, Thai and English, and one of the following happens.

• Utterances in languages other than the selected one are dropped entirely, treated as silence
• They are forcibly interpreted as sounds of the selected language and come out as meaningless strings
• Automatic detection wavers utterance by utterance, so one person’s remarks are fragmented across languages

All of these get reported as “the accuracy is bad”, but the cause is not accuracy. It is a mismatch of assumptions.

The summary is dragged along by the meeting language

There is a deeper problem one level down. Even when transcription goes well, the summary is dragged along by the language of the source text. Transcribe a Japanese meeting and then have it summarised directly in Thai, and the summary quality drops noticeably. It shows up as proper nouns left in the source language, quantitative expressions shifted, and inconsistent registers mixed together.

This bites precisely when you want to distribute the minutes to both Japanese and Thai staff. If you meet in Japanese and issue Japanese minutes, the problem never surfaces — but the minutes never reach Thai staff either. Meet in Thai and issue Thai minutes, and the Japanese expatriates and head office cannot read them.

Choose one of three patterns

There are three realistic options. Decide which one applies before each meeting type, not after.

At Japanese-owned Thai factories the most workable option is usually the two-pass pattern. You do not have to force meetings into a single language, and the source text remains available for verification. Note, however, that if you choose two-pass, the quality of your minutes is rate-limited by the quality of the translation stage. You need a glossary, a review flow for translation output and a clear line on how far machine translation can be trusted — which is less an AI minute-taking project than translation operations design in its own right. The thinking here maps directly onto what we covered in our article on corporate translation automation for 2026, so if you are going two-pass, we recommend settling that design first.

Capture for interpreted meetings has to be designed, or everything gets recorded twice

One caution if you choose the interpreter-consolidated pattern. When consecutive interpretation happens in a meeting room, the microphone picks up both the original remark and the interpretation. Transcribe that as it comes and the same content is recorded twice in two languages, after which the AI treats both as independent utterances at summarisation time and the discussion inflates into a duplicate.

The remedy is to separate the channels at the point of capture. Use one microphone for the original speakers and another for the interpreter, or route the interpretation into a separate web meeting channel. If the equipment cannot be separated, make it an operational rule to give the summarisation step an explicit instruction to exclude interpreter repetitions. Skip this design step and your minutes come out one and a half to two times longer than the actual meeting, after which nobody reads them.

Fault line 2 Vocabulary – what words, and how many, go into the custom dictionary

Even with a good CER, it is the proper nouns in the decisions that break

The metric most often used for speech recognition accuracy is the character error rate (CER). For Thai speech recognition, there are evaluation results from Typhoon ASR Real-time, published on 19 January 2026. CER on the FLEURS benchmark is 5.69%, on the TVSpeech robustness track it improved from 10.36% to 6.32%, and the model is a compact 115M-parameter model running at one forty-fifth of the compute cost of Whisper Large-v3.

There is one reinterpretation you must absolutely avoid here. 5.69% is a character error rate on the FLEURS benchmark, not the accuracy you will see in a real meeting. Restating it as “Thai recognition accuracy is 94%” is simply wrong. FLEURS is an evaluation dataset built mainly on read speech, and contains none of the conditions of a real meeting — room reverberation, overlapping speakers, technical terminology, self-corrections. Benchmark figures are a relative measure for comparing models on the same footing. They are not a prediction of the accuracy you will obtain in your own meetings.

And even if your CER genuinely were in the 5% range, that would not mean fault line 2 was solved. CER is the proportion of errors across all characters. If a one-hour meeting transcribes to 20,000 characters, a CER of 5% means 1,000 characters are wrong. The question is where those 1,000 characters fall. Everyday vocabulary appears in vast quantities in the training data and comes out correctly, so the errors concentrate on words that are absent from the training data. Which means they concentrate on part numbers, process names, jig names, internal abbreviations and personal names — the parts of the minutes that matter most.

Concretely, it looks like this.

• “Somchai, the Thai line leader, will handle the centring on TCP-4520”
• “Somchoi, the Thai line leader, will handle the centring on TCP 45 20”

The overall meaning of the sentence still comes through. Measured by CER it is a few per cent. But these minutes are unusable, because the part number cannot be identified and the named owner is now a different person.

A custom dictionary holds the words that are spoken aloud in meetings

The remedy is the custom dictionary — a feature that lets you pre-register proper nouns you want recognised, available in almost every commercial product.

For Microsoft 365 Copilot, admin message MC1221925 announced that the custom dictionary is expanding to Thai and four other languages, with the registration cap per language rising from 500 to 1,000 words. Rollout was scheduled worldwide from mid to late January 2026. The important detail is that the cap is counted per language, so you are working with a frame of 1,000 words for Japanese, 1,000 for Thai and 1,000 for English.

What goes into the dictionary? This is where many sites get it wrong. The common mistake is bulk-loading part numbers out of the bill of materials or the drawing system. The 1,000-word frame fills up immediately, and most of what filled it is never spoken aloud in a meeting.

There is exactly one correct selection criterion. Register only words that are actually spoken aloud in meetings. Specifically, words like these.

• Names of the main lines and equipment (not the formal names, the names people actually use on the floor)
• The way frequent part numbers are pronounced (if “TCP-4520” is read as “T-C-P forty-five twenty”, register that reading too)
• Process names and process abbreviations (the more internal-only the abbreviation, the more important it is)
• Attendees’ names (Thai names are especially error-prone, and if someone goes by a nickname, register the nickname as well)
• Customer and supplier company names (including the short forms people use)
• Defect classification names (internal defect codes and their colloquial equivalents)

What goes into a 600-word starting dictionary

As a model, here is how to allocate a 600-word starting dictionary. The cost estimate below allows 20 hours to build these 600 words.

Because those 600 words are spread across three languages, there is comfortable headroom against the per-language cap. That headroom is deliberate. It is the space you keep for adding entries every time a misrecognition surfaces after go-live.

A dictionary is not finished when you build it

Dictionary effectiveness decays within three to six months if it is not maintained. The reason is simple — new products launch, people change roles, and new abbreviations get invented. The cost estimate builds in four hours per quarter, four times a year. Leave that effort out of the first-year budget and the dictionary goes stale in year two, producing the false conclusion that “the AI has got less accurate”.

To keep maintenance turning, build exactly one mechanism into the operation. Whoever reviews the minutes writes down every misrecognition they find in a designated place. The quarterly update then consists only of reflecting that list into the dictionary. Without this mechanism, every update starts with hunting for misrecognitions, and four hours will not be enough.

Fault line 3 Decisions – which utterances AI can extract and which it cannot

AI cannot create information that does not exist

The most frequent complaint about AI minute-takers is that “the decisions do not come out properly”. And most of the time the cause does not lie with the AI. It is that the decision was never spoken aloud.

In a Japanese-language meeting, decisions tend to close like this.

• “Right, let’s go with that.”
• “Is that all right?” “Yes.”
• “About that item from earlier, over to you.”

No human being could reconstruct who, what and by when from those three utterances either. The information lives in the meeting context and in the participants’ shared unspoken understanding. It is not in the audio. AI cannot create information that is not in the audio, so the summary comes out as a generality — “the matter was discussed”.

When a Thai staff member writes the minutes, that reconstruction is being performed by a person. They know the context of the meeting, they know the history, they know the conventions for assigning ownership, and so they can write it. Which is exactly why introducing an AI minute-taker makes the tacit knowledge that person was carrying visible by its absence. When minutes appear to get worse after AI is introduced, this gap is usually what happened.

Change how the meeting ends

The remedy exists only on the operational side. Add a step where the decisions are read aloud at the end of the meeting. Fix the content of that reading to three points.

• What was decided (a one-sentence conclusion)
• Who will do it (a name. Not “the quality department” but an individual)
• By when (a date. Not “sometime next week” but a specific day)

Spending the final three minutes on this reading changes the quality of AI-extracted decisions dramatically. The three points now exist in the audio, so extraction becomes a straightforward task.

There is a secondary benefit as well. At the moment of the reading, agenda items with no owner assigned become visible. Items that previously drifted onward until the next meeting asked “what happened with that?” are now detected during the meeting itself. That is an improvement in meeting management rather than an effect of the AI, but in practice it is the more valuable of the two.

Utterances that can and cannot be extracted

You can reuse this table verbatim when explaining meeting conduct rules internally. It embeds far better as a procedure — “read decisions out in this form” — than as an instruction to “please speak in a way the AI can understand”.

Hold decisions as a register outside the minutes

One further point, this one belonging to the distribution layer. When decisions are buried inside the body text of the minutes, three months later you cannot find when something was decided. Full-text searching the minutes does not help, because decisions and discussion are mixed together in the same prose and the search results cannot be judged.

So structure it so that decisions are held separately from the body of the minutes, as a register. There are minutes per meeting, and separately a list that extracts only the decisions. Whether an AI minute-taker’s output can be fed straight into that register is a practical criterion in product selection.

The idea of “hold it as a list and make it searchable” is the same thinking that applies when you systematise internal enquiry handling. We covered the design of accumulating questions and answers into a searchable store in detail in our article on internal helpdesk automation for 2026, which is useful reference material when you build a decisions register.

Fault line 4 Regulation – Thailand’s PDPA, recordings, voice data and retention

A recording is personal data

This is the most overlooked point of all. A meeting recording contains the voices of the attendees. Voice qualifies as personal data, as information capable of identifying a specific individual. Under Thailand’s Personal Data Protection Act (PDPA), collecting, using and disclosing personal data requires a legal basis, and there are requirements covering retention periods and processing entrusted to third parties.

“It is an internal meeting, so it is fine” does not hold. Employees are data subjects too. If anything, the existence of an employment relationship makes the voluntariness of consent something to watch. Consent obtained in a situation where refusal might bring disadvantage can have its validity questioned.

And if you record meetings with customers and suppliers, you are collecting personal data belonging to the counterparty’s employees. That cannot be handled by internal policy alone.

Enforcement in Thailand is genuinely active

Enforcement of the PDPA was slow for a while after it took effect, but the situation has changed. According to Chambers’ “Data Protection & Privacy 2026 — Thailand”, Thailand’s Personal Data Protection Committee (PDPC) announced five administrative fines on 1 August 2025, totalling THB 21,500,000. Furthermore, on 24 November 2025 an order was issued to halt and delete biometric data collected by iris scanning, affecting 1,200,000 people.

The biometric case is a different category from voice, but the direction it indicates is unambiguous. The regulator is prepared to order the cessation of collection and the deletion of data when highly sensitive data is collected at scale. Recording meeting audio company-wide and accumulating it in the cloud with no defined expiry is not, viewed from that direction, a safe design.

The regulatory items you must settle before deploying

Before deployment, settle the following items in writing. This is legal work, and it cannot be completed by the IT department or a tool owner alone.

Three rows in that table deserve particular attention.

Retention period. Audio, transcript and minutes need three different retention periods. The minutes may need to be kept for several years as a business record, but the audio should not need anything like that. In practice, use a three-tier structure — audio short-term (for example, 30 days after the minutes are finalised), transcript medium-term, and the minutes themselves for as long as the business requires. Without those deadlines, audio accumulates indefinitely.

Processor management. Use a cloud-based minute-taking service and your audio data goes to the provider’s servers. That constitutes entrusting the processing of personal data and requires a processing agreement with the provider. Using a free plan or a personally contracted tool for internal meetings means personal data is leaving the company with no contractual basis at all.

Cross-border transfer. If the servers sit outside Thailand, you must satisfy the cross-border transfer requirements. At the selection stage, ask the provider where the data is stored and keep the answer on record. This confirmation can itself become the reason you choose archetype C below.

Prepare the statement read at the start of the meeting

In practice, the single most effective step is to prepare a short notification statement to be read at the start of the meeting. Prepare it in Japanese, Thai and English, and have the meeting host read it aloud, or embed it in the meeting invitation template.

The content should cover these elements. That recording is taking place, that the purpose is minute-taking, the retention period, and where to raise an objection if someone does not wish to be recorded. Standardise it once it has been through legal review, and you no longer need to make a judgement call meeting by meeting. The cost of outsourcing the review of this document, the retention policy and the processor agreement is what appears as layer 5, regulation in the five-layer cost model below.

The four archetypes of AI meeting minutes and how to choose

The four archetypes

There are a great many products, but organised from the perspective of a Japanese-owned Thai factory, they fall into four archetypes.

Archetype A – built into the meeting app

For companies already contracted with Microsoft 365 or Zoom, this is the first option. No additional procurement process is required and it can be handled inside the existing licence structure, which is a real practical advantage when it comes to internal approval.

Microsoft Teams has a feature that generates meeting notes, and the custom dictionary expansion to Thai and other languages was announced in MC1221925 as described above. If you choose this archetype, you get better return by positioning it as part of your overall Microsoft 365 usage design rather than deploying the minutes feature in isolation. Licence allocation policy, data residency and combination with other features are all covered in our article on how to approach a Microsoft Copilot rollout in 2026, which is worth reading alongside this one.

The weakness is clear. Because it presumes a web meeting, it cannot capture face-to-face meetings held in a conference room. Meetings held standing up on the shop floor, like the daily production meeting, fall outside its scope. And because the summary is bound to the meeting language, choosing the two-pass pattern from fault line 1 means arranging the translation stage separately.

Archetype B – dedicated SaaS

A cloud service specialised in meeting minutes, with speaker diarisation, dictionaries and decision extraction built in properly. Many products let you upload a recording of a face-to-face meeting for processing, so you can cover both web and in-person meetings.

The weakness is that audio data goes to an external provider. The processor management and cross-border transfer questions from fault line 4 arrive head-on. At selection time, always confirm where data is stored, whether retention periods can be configured, how deletion requests are handled and whether a DPA can be concluded. A provider that cannot answer these should be dropped from the shortlist regardless of how good the features are.

Archetype C – in-house ASR plus LLM

An option where circumstances prevent audio from leaving the company, or where you process a large volume of meetings and want to drive down unit cost. It has become more realistic than it used to be, now that compact Thai-specialised ASR models have entered practical territory. That Typhoon ASR Real-time is a 115M-parameter compact model is meaningful in this context as an indication of compute cost.

The weakness is manpower. Model selection, dictionary management, accuracy evaluation and model updates all become yours to own. A factory with 420 employees cannot realistically sustain that capability on its own. This is an archetype to consider when the group has an information systems function and the premise of sharing it across multiple sites holds.

Archetype D – human hybrid

AI produces a draft and an owner confirms and finalises only the decisions. For meetings where responsibility for the decision is heavy — agreements with customers, resolutions at management meetings — nothing else should be chosen.

The weakness is that the reduction is small, but that is design rather than weakness. It is the judgement that in meetings where an error in the minutes is a direct loss, accuracy beats savings. In a real deployment you end up applying different archetypes to different meeting types.

Which archetype for which meeting

Applied to the model company’s meetings, it comes out like this.

This allocation is the basis for the figure of “5 seats” in the cost estimate that follows. You do not distribute company-wide. You narrow it to the people who attend the meetings where minutes are produced.

Estimating cost across five layers – a model calculation for a mid-sized Japanese-owned plant in Thailand

The model company

Everything that follows assumes the model company below. It is not a real company.

• A Japanese-owned automotive parts plant in Chonburi province, Thailand
• 420 employees
• 4 Japanese expatriates
• 35 managers and office staff

39 minute-taking meetings per month

First, count the meetings for which minutes are actually produced.

22 + 8 + 1 + 8 = 39 meetings per month. What you count here is only “meetings for which minutes are produced”. Meetings with no minutes offer nothing for AI to reduce.

Effort and cost as things stand (Before)

Break the effort per set of minutes into production and review.

• Producing the minutes — a Thai staff member spends 45 minutes each. 39 × 45 min = 1,755 min = 29.25 hours per month
• Expatriate review and correction — 15 minutes each. 39 × 15 min = 585 min = 9.75 hours per month

Multiply by hourly cost.

• Staff hourly rate — monthly salary of THB 45,000 ÷ 21 days ÷ 8 hours = THB 268
• Expatriate hourly rate — monthly cost of THB 300,000 ÷ 21 days ÷ 8 hours = THB 1,786

The expatriate figure uses total monthly cost including housing, home-leave travel and social insurance, not salary. Calculate it on salary alone and you will understate the saving.

• Production — 29.25 hours × THB 268 = THB 7,839 per month
• Review — 9.75 hours × THB 1,786 = THB 17,414 per month
• Total — 7,839 + 17,414 = THB 25,253 per month

The breakdown is what deserves attention. The staff spend three times as many hours, yet in money terms the expatriate review effort accounts for roughly 69% of the total. When you think about return on an AI minute-taker, the conclusion is already visible at this point — what you should be cutting is review time, not production time.

Effort and cost after deployment (After)

Now place the post-AI effort. It does not go to zero. Checking the transcript and summary, correcting proper nouns and finalising decisions all remain.

• Producing the minutes — 45 min each falls to 18 min. 39 × 18 min = 702 min = 11.7 hours per month → 11.7 × 268 = THB 3,136
• Expatriate review — 15 min each falls to 8 min. 39 × 8 min = 312 min = 5.2 hours per month → 5.2 × 1,786 = THB 9,287
• Total — 3,136 + 9,287 = THB 12,423 per month

The saving is 25,253 − 12,423 = THB 12,830 per month. Annualised, 12,830 × 12 = THB 153,960.

Setting production at 45 minutes down to 18, and review at 15 minutes down to 8, assumes all four fault lines have been closed. Deploy without a dictionary and without reading decisions aloud, and review time actually increases, because the work of reading while hunting for misrecognitions gets added.

Split the cost into five layers

This is the core of the section. Estimate the cost of an AI minute-taker on licence fees alone and your figure will be off by an order of magnitude from actual spend. Split it into five layers.

Check the arithmetic.

• Layer 1 — 5 seats × THB 900 × 12 months = THB 54,000
• Layer 2 — THB 12,000 × 2 rooms = THB 24,000
• Layer 3 — 20 hours × THB 268 = THB 5,360
• Dictionary maintenance — 4 hours × 4 times × THB 268 = THB 4,288
• Year 1 total — 54,000 + 24,000 + 5,360 + 80,000 + 48,000 + 4,288 = THB 215,648
• Year 2 onward — 54,000 + 4,288 = THB 58,288

This table makes one point. The tool layer is only 25% of the first-year cost (54,000 ÷ 215,648). Look at the licence fee alone, conclude that “THB 900 a month is cheap”, and the remaining 75% arrives later. Layers 4 and 5 in particular are frequently not even recognised as existing at the approval stage, which is how you end up with “nobody told us about those costs” after deployment.

The payback calculation

• Year 1 — 153,960 − 215,648 = THB 61,688 net outlay
• Year 2 onward — 153,960 − 58,288 = THB 95,672 per year in surplus

Year 1 runs at a loss. The cumulative position crosses zero when the year-2 surplus of THB 95,672, spread across the months at THB 7,973 per month, fills the THB 61,688 hole — that is, month 7.7 of year 2, or 19.7 months from deployment on a cumulative basis.

Over three years it looks like this.

• Three-year total cost — 215,648 + 58,288 × 2 = THB 332,224
• Three-year total saving — 153,960 × 3 = THB 461,880
• Three-year net — 461,880 − 332,224 = THB +129,656

Three years to get to a positive THB 129,656. That is not a large sum by any measure. The honest conclusion of this estimate is that an AI minute-taker is a weak investment if cost reduction alone is the objective.

Distribute to every seat and it never pays back

This is the most important number in the article. What happens if you give licences to all 35 managers and office staff?

35 people × THB 900 × 12 months = THB 378,000 per year

The annual saving is THB 153,960. The tool layer alone comes to roughly 2.5 times the saving, and it fails to pay back without adding a single baht from layers 2 through 5. Company-wide distribution does not turn positive under any variation of this estimate’s assumptions.

So the 5-seat premise is not a convenience to make the cost look small. It is the condition on which the whole thing stands. The criterion for who gets a seat is unambiguous — only people who attend meetings where minutes are produced and who either write or review those minutes. At the model company that works out to 5 people, made up of 2 of the 4 expatriates who review minutes, 2 Thai staff who produce them, and 1 manager who chairs meetings.

When deployment is under consideration, internal dynamics always push toward “let’s give it to everybody”. The arguments are “it is unfair if only some people can use it” and “while we are at it, let’s do it company-wide”. Answer that argument with the multiplication above. 378,000 against 153,960 — those two numbers end the discussion on their own.

Payback does not come from production hours multiplied by hourly rate alone – a breakdown of three effects

There are three kinds of effect, and they differ in character

The estimate in the previous section dealt with only one of three kinds of effect.

• Effect 1, direct effort reduction — the time to produce and review minutes. Calculable in money, and this is what the estimate above covers
• Effect 2, removing delay in decisions — the delay in starting work caused by minutes arriving the next day or later. Monetisable under conditions
• Effect 3, preventing rework caused by mismatched understanding — resolving “you said, I said” disputes. Not monetised

Blend these three together and talk about “the effect of an AI minute-taker” as a single number, and the number is guaranteed to be inflated. Effect 1 is calculable, so put it in the estimate. Effect 2 goes in only when the condition is met. Effect 3 is never converted into money. We recommend stating this line explicitly at the approval stage.

Effect 2 counts only when the minutes are a precondition for starting work

If minutes appear the next business day, work based on the instructions in them starts a day late. Conversely, if they appear on the day of the meeting, work can start the same day.

But this only holds as an effect when the minutes are a precondition for starting. On a shop floor where people take verbal instructions in the meeting and move without waiting for the minutes, faster minutes do not make anything start sooner. Skip that check and calculate “one day earlier × number of items × unit rate”, and you are booking an effect that does not exist.

You can determine whether effect 2 applies in your own case with a single question. Of the work items decided in your recent meetings, what proportion were started before the minutes were circulated? If that exceeds 80%, effect 2 should not be counted.

Treat effect 3 as risk, not as money

Resolving “you said, I said” is, in terms of felt experience, the largest effect of all. In customer meetings especially, the rework triggered by a mismatch in what both sides believed was agreed easily exceeds the value of the minute-taking hours saved.

Even so, we do not recommend putting it in the estimate. The reason is that you cannot estimate the probability of occurrence for your own operation. If you could derive an annual frequency from historical records that would be one thing, but in most cases all you have is a feeling that “it happens occasionally”. A number produced by multiplying a feeling by a unit rate will be challenged in the approval meeting, and it will take the credibility of the whole estimate down with it.

Instead, write effect 3 as a risk-reduction item in prose rather than in money. Something like “for matters agreed with customers, retaining a record of the original wording provides a means of verification should a difference in understanding arise”. That is consistent with the fault line 4 regulatory work as well, because a record is also a means of proof if a dispute occurs.

Decide in advance what the freed-up time will be used for

Finally, one assumption behind the estimate that is often overlooked. Time you free up disappears if you do nothing with it.

If expatriate review time falls from 9.75 hours a month to 5.2, the 4.55 hours released have to be redirected to some other value-adding activity, or the saving is never realised in money. You are not reducing headcount.

So write into the deployment proposal what the freed-up time will be used for. For expatriates, that might be time on the shop floor, better-quality reporting to head office, or developing Thai managers. For staff, document preparation other than minutes, or data compilation work. Only once you have written this far does the saving become a number that can actually be realised.

A 90-day approach

Design the rollout in three-month units. Narrow it to one meeting type, get it working there, then expand.

Month 1 – selecting the target meetings and preparing the regulatory groundwork

In the first month you do not touch the tool. There are three things to decide.

• Which meeting to start with. Pick one with high volume and relatively light decision responsibility, such as the daily production meeting
• Who gets a licence. Fix the headcount using the criterion from the previous section
• Prepare the regulation-layer documents. Consent notification statement, retention periods, confirmation of the processor agreement

Expect the regulatory preparation to take time. If you outsource legal review, two to four weeks is normal. Skip this and start operating, and you will be redoing everything later.

Month 2 – capture and dictionary preparation, then a pilot

• Install omnidirectional microphones in the room where the target meetings are held
• Build the 600-word starting dictionary. Select only words spoken aloud in meetings
• Introduce the procedure of reading decisions aloud at the end of the meeting
• Start the pilot in real meetings. At this stage, continue producing the conventional minutes in parallel

Parallel operation is mandatory. Switch to AI output alone, then discover the quality is insufficient, and you have lost the minutes for that whole period. Run in parallel for a minimum of four weeks, and judge only after passing at least 15 meetings of the same type through the process.

Month 3 – evaluation, and the decision on whether to expand

Evaluate in month 3. There are four evaluation criteria, each mapped to one of the fault lines.

If all four meet their standard, expand to the next meeting type. If any fall short, go back to the work that addresses the corresponding fault line. Do not expand while a standard is unmet. Add more target meetings and the same problem multiplies by the number of meetings.

The order of expansion

Decide the expansion order too. The recommendation is highest volume first, and lightest decision responsibility first.

• Daily production meeting (22 per month, light responsibility)
• Quality meeting (8 per month, mixed languages)
• Management meeting (1 per month, single language but sensitive content)
• Customer and supplier meetings (8 per month, counterparty consent required)

Customer and supplier meetings come last because they involve an element you cannot complete on your own — the counterparty’s consent. Explain it to the other side only after your internal operation has settled and the notification and retention procedures have taken hold.

Common failure patterns

Failure 1 – selecting on the basis of an accuracy comparison table

Build a table comparing recognition accuracy across products and pick the one with the best numbers. It looks rational, but the numbers in that table are benchmark figures supplied by vendors. As described above, benchmark numbers do not predict accuracy in your own meetings.

What you should build instead is a comparison of the results of running one real recording of your own meeting through every candidate product. One recording is enough. Pick one quality meeting that mixes Japanese, Thai and English, run the same audio through each product, and count the errors in proper nouns. That gives you direct measurement of two of the four fault lines — language and vocabulary.

Failure 2 – starting on a free plan, which then becomes the internal standard

Someone tries it on a free plan under a personal account, finds it useful and starts using it across the department. The regulation layer is entirely absent, and internal meeting audio keeps flowing outside the company.

Free plans frequently have different data handling terms from paid plans. Trialling is not a problem in itself, but restrict the audio you use for trials to material that contains no personal data. The moment a real meeting recording goes into a free plan, you have a fault line 4 problem.

Failure 3 – distributing company-wide, then cancelling en masse the following year

Licences go to every seat in year 1, the costs do not add up, and everything is cancelled the following year. This is the 378,000 against 153,960 figure from the previous section becoming reality.

The awkward part is that the cancellation persists internally as a conclusion that “AI minute-taking did not work”. In fact only the seat-count design was wrong — at 5 seats it turns positive over three years — but the opportunity to reconsider is lost for several years.

Failure 4 – minutes now get produced, but nobody reads them

This happens when the distribution layer design is skipped. Minutes are generated automatically and pile up in a shared folder, but the decisions are buried in the body text and cannot be searched, so in the end the people who attended work from memory.

The remedy is the register separation described under fault line 3. Hold the full minutes and the list of decisions separately. Then make it a practice to review the list at the start of the next meeting. Unless you build a mechanism for the output to be read, automating the output is not an improvement to the business.

Failure 5 – it lands as a story about taking work away from Thai staff

This is when the intent of the deployment is not correctly communicated to the Thai staff who had been producing the minutes. If it is received as “we are being replaced by AI”, you will get cooperation on neither dictionary building nor misrecognition reporting. Fault line 2 maintenance stops turning, accuracy falls, and the deployment fails.

When explaining the deployment, lead with what the freed-up time will be used for. The reason the previous section said to decide the use of freed-up time in advance is partly the return-on-investment argument, and partly this conversation.

Frequently asked questions

Does AI meeting minutes software support Thai

The number of products that do is increasing. For Microsoft 365 Copilot, admin message MC1221925 announced that the custom dictionary expands to five languages including Thai, with the registration cap per language rising from 500 to 1,000 words. Thai-specialised speech recognition models have also entered practical territory, with Typhoon ASR Real-time reporting a CER of 5.69% on the FLEURS benchmark.

Do not, however, reinterpret that 5.69% as “Thai recognition accuracy is 94%”. FLEURS is a benchmark dataset, and its conditions differ from a real meeting with room reverberation, overlapping speakers and technical terminology. Whether a product supports Thai and whether it is usable in your meetings are two different questions. The answer comes only from running one real recording of your own meeting through it.

Do we need employee consent to record

Under Thailand’s PDPA, the voices contained in a meeting recording constitute personal data. Collection and use require a legal basis, and consent is one of the options. But consent within an employment relationship raises questions of voluntariness, so a design relying on consent alone is not always optimal.

In practical terms, start by putting three things in place. A procedure for announcing at the start of the meeting that recording is taking place, an explicit statement that the purpose is limited to minute-taking and that the data will not be used for performance appraisal or similar, and a defined retention period for the audio. Then confirm the legal basis that fits your situation with Thai legal counsel. Asking the tool vendor will not produce an answer to this question.

Can we record meetings with customers

Because you would be collecting personal data belonging to the counterparty’s employees, this cannot be handled by internal policy alone. Explanation to and acceptance from the other side are required. In practice, confirm at the start of the meeting whether recording is acceptable, and do not record if the answer is no.

This is why the 90-day approach places customer and supplier meetings last. Raising it with the counterparty after your internal operation has settled and you can explain it clearly is far more likely to succeed. And because decision responsibility is heavy in customer meetings, we recommend applying archetype D, the human hybrid.

How accurate does transcription need to be to be usable

We do not recommend setting a numerical threshold. Character error rate is the proportion of errors across all characters, but what determines whether minutes are usable is the location of the errors, not the proportion. An error in everyday vocabulary is obvious on reading. An error in a part number or a personal name is not.

There is one usable standard instead. Three or fewer proper nouns requiring correction per set of minutes. Meet that, and the review work finishes in a realistic amount of time. Since this standard is determined by the state of your dictionary, when accuracy feels insufficient, revisit the dictionary before you change the model.

Will AI solve the situation where Thai staff are writing minutes in Japanese

Partly, but not as it comes. Turning a Thai-language meeting into Japanese minutes is two processes, transcription and translation. Most AI minute-takers handle the former, and the latter is a separate mechanism. You need to choose the two-pass pattern from fault line 1 and design the translation stage in.

Note that this structure leaves the source text in Thai as a record. Previously the translation happened inside a person’s head and no source text survived, so this is a quality improvement in itself. When a question arises about the Japanese minutes, you can go back to the source and check.

Is the feature built into the meeting app enough on its own

If web meetings dominate, the meeting language is a single language, and you do not need minutes for face-to-face meetings, then yes. The advantage of requiring no additional procurement is substantial in practice, and starting here is a rational sequence.

Where it stops being enough is when you need minutes for face-to-face meetings. Daily production meetings and quality meetings held in a conference room cannot be captured by the built-in feature. At the model company, 30 of the 39 monthly meetings are held face to face — 22 daily production meetings plus 8 quality meetings — so the built-in feature alone does not reach most of the reduction target. Count the composition of your own meetings and decide from that.

How many months until it pays for itself

In the model company’s estimate, the cumulative position turns positive at month 19.7 on a cumulative basis. Year 1 is a net outlay of THB 61,688, and from year 2 onward there is a surplus of THB 95,672 per year. Over three years the total is THB +129,656.

Those numbers hold on the premise of 5 seats. Give licences to all 35 managers and office staff and the tool layer alone comes to THB 378,000 per year, far exceeding the annual saving of THB 153,960 and never paying back. The most reliable way to shorten the payback period is to restrict the number of seats.

Summary

You cannot choose AI meeting minutes software on transcription accuracy. The reason minutes become unusable at Japanese-owned Thai factories lies in the four fault lines behind speech recognition.

• Fault line 1, language — meetings mix Japanese, Thai and English while speech recognition assumes one language per meeting. Decide in advance, per meeting type, whether you use language-separated meetings, interpreter consolidation or the two-pass pattern
• Fault line 2, vocabulary — even with a good CER, errors gather in part numbers, process names and personal names, the parts of the minutes that matter most. Put only words spoken aloud in meetings into the dictionary, and maintain it quarterly
• Fault line 3, decisions — if who and by when do not exist in the audio, AI cannot invent them in a summary. Build the reading aloud of decisions at the end of the meeting into your operating procedure
• Fault line 4, regulation — a recording is personal data. Settle consent, purpose, retention period, processor agreement and cross-border transfer in writing before deployment

With those closed, the cost cannot be estimated from the tool layer alone. Split across the five layers of tool, capture, dictionary, operations design and regulation, the model company’s first year is THB 215,648 and each year from the second is THB 58,288. The tool layer within that is THB 54,000, only 25% of the first-year cost.

Payback runs to a cumulative 19.7 months against an annual saving of THB 153,960, with a three-year total of THB +129,656. These are not large numbers. And this estimate holds only on the premise of 5 seats. Distribute to all 35 managers and office staff and the tool layer alone reaches THB 378,000 per year, far exceeding the saving and never paying back.

An AI minute-taker is not the kind of tool that produces results by being handed to everyone at once. Give it only to the people who attend meetings where minutes are produced, close the four fault lines, and decide what the freed-up time will be used for. Only when those three are in place does it stand up as an investment.

Talking to us while you are still deciding

TOMAS TECH is based in Bangkok, Thailand, and supports Japanese-owned manufacturers with systems for production and quality management and with the wider IT-enablement of their operations. On meeting-minute automation, we are happy to talk at the stage of “which meeting should we start with” or even “are we allowed to record this at all”.

This is an area where a lot has to be decided before tool selection. Counting the composition of your meetings, designing the seat count, choosing the words for the dictionary, deciding whether capture equipment is needed, listing the regulatory items to cover. It is perfectly fine to come to us stuck at that stage. Tell us the number and language composition of your current meetings and we will give you our reading of which archetype fits and which fault line to tackle first.

You do not need to have decided to deploy anything. We also welcome conversations at the stage of wanting to organise what should be checked before an internal review begins. Please get in touch through our contact page.

References

• Japan Ministry of Internal Affairs and Communications, White Paper on Information and Communications 2026, news coverage on 86.4% generative AI use among companies — read the article
• Japan Ministry of Internal Affairs and Communications, White Paper on Information and Communications 2025, current state of AI use in companies — view the white paper page
• AWS “Unlocking Thailand’s AI Potential 2026”, news coverage on 43% AI use among Thai companies — read the article
• Typhoon ASR Real-time, CER benchmark for Thai speech recognition, 19 January 2026 — read the review
• Microsoft 365 Copilot custom dictionary language expansion, MC1221925 — read the announcement
• Chambers “Data Protection & Privacy 2026 — Thailand: Trends and Developments” — view the guide
• Generate meeting notes in Microsoft Teams, Microsoft Support — view the support article