Getting Started with AI: A Practical Roadmap for Thai SMEs

For most Thai SMEs the barrier to AI is not technology and not budget. It is knowing where to start without spending six months and a large sum discovering that the chosen use case was never viable.

The answer is not a transformation programme. It is one well-chosen pilot with a measurable outcome, run cheaply enough that failing is affordable. This is a roadmap built around that principle.

How should a small business start with AI?

Start with an expensive, repetitive problem you already have — not with a technology you want to use. Pick something measurable, run a contained pilot with a defined success metric and a deadline, and only scale what demonstrably moved the number.

The single most reliable predictor of a failed AI project is that it began with the sentence "we should be using AI". Projects that begin with "quoting takes three days and we lose deals because of it" succeed far more often, because they have a definition of success that existed before the technology was chosen.

Start with a problem, not a tool

Look for work that is high-volume, repetitive, rule-based or language-heavy, and currently costs real money in staff time or lost revenue. Quoting, data entry, document processing, support triage and Thai-language document search are the categories where Thai SMEs most consistently find value.

Write down what the problem costs before you evaluate any solution. Hours per week, multiplied by loaded staff cost, plus any revenue lost to slowness. If you cannot produce that number, you will not be able to tell whether the pilot worked — and you will end up judging it on how impressive it felt, which is how organisations end up maintaining systems nobody uses.

Check your data before you commit

Most failed AI projects fail on data, not models. Before committing, confirm the data exists, is accessible, is consistent enough to be usable, and that you are permitted to use it — which under the PDPA is a genuine question when personal data is involved.

You do not need perfect data, and waiting for it is its own failure mode. You need to know honestly what state it is in. A realistic assessment often reveals that a data-cleanup project should precede the AI project, and that is a legitimate and valuable outcome of the assessment.

On PDPA: using customer data to train or tune a system is processing, and it needs a lawful basis. If you collected the data for order fulfilment, using it for something else may require fresh consent. Establish this at the start — retrofitting a lawful basis after building the system is expensive and sometimes impossible.

Prove it with a small pilot

Run a contained pilot with one metric, one owner, and a hard deadline — six to twelve weeks is usually right. Keep the scope small enough that failure costs weeks rather than a year and a budget. Define what success looks like in writing before starting.

Agree the kill criteria up front, in the same document as the success criteria. Knowing in advance what result would cause you to stop is what prevents a pilot from quietly becoming a permanent project that nobody can cancel because too much has been invested.

Involve the people who do the work today from the first week. They know the edge cases that will break the system, and if the tool arrives as something imposed on them, adoption fails regardless of how well it performs.

Scale only what works

Once a pilot moves the metric, invest in making it reliable, integrated and supported — then find the next use case. Compounding several small proven wins is a far better strategy for an SME than one ambitious system that may never ship.

Budget for the unglamorous half. A working pilot is perhaps 40% of the effort of a production system; the rest is error handling, monitoring, integration with what people already use, and someone owning it when it misbehaves. Organisations that skip this end up with a demo that gradually stops being used.

For some Thai organisations — particularly government agencies and regulated sectors — the scaling question includes where the model runs. If data cannot leave your infrastructure, an on-premise deployment is not a preference but a requirement, and it is better to know that before the pilot than after.