AI That Reaches Production, Not Just the Demo
We take Vietnamese businesses from an AI idea to a system that runs every day: readiness assessment, data foundation, a working pilot, then rollout and monitoring.
Most AI projects in Vietnam do not fail because the model is wrong. They fail because the demo impressed everyone in the meeting room and then nobody could answer the next question: where does this data come from every morning, who fixes it when it breaks, and which existing process does it replace.
iGlobal approaches AI from the operations side first. We look at where your data actually lives today, which decisions are made by hand and repeated hundreds of times a month, and what would measurably change if those decisions were made faster or more consistently. Only then do we talk about models.
Why AI stalls inside most companies
The raw material for AI is data, and in most mid-sized Vietnamese companies that data is scattered across Excel files on individual laptops, Zalo conversations, paper delivery notes, and two or three systems that were never designed to talk to each other. A model trained on that foundation produces answers nobody trusts.
The second obstacle is ownership. A pilot built by an outside vendor and handed over as a zip file has no owner inside the company. When the data format changes in month four, nobody notices until the output has been wrong for weeks.
- Data living in files rather than in a system of record
- No measurable baseline, so nobody can prove the AI helped
- Pilots that never connect back to the tools staff use daily
- Vietnamese text, accents and local document formats handled badly by generic tools
What we actually build
AI readiness assessment
A two to three week review of your data sources, process maturity and realistic opportunities, ending in a ranked shortlist with estimated effort and expected return for each item. You can act on it with us or without us.
Data foundation and pipelines
Before any model, we consolidate the sources that matter into one place, usually your Odoo database, with scheduled jobs that keep it current and alerts when a feed stops arriving.
Document and invoice automation
Reading supplier invoices, customs documents, delivery notes and contracts, including Vietnamese diacritics and stamped scans, then posting the extracted values straight into accounting or inventory for a human to confirm.
Conversational assistants
Assistants on your website, on Zalo, or inside the back office that answer from your own documents and your own stock and price data, not from the open internet.
Forecasting and planning
Demand forecasts, reorder suggestions and capacity planning that take seasonality, Tet, and promotion calendars into account rather than a flat moving average.
Monitoring and handover
Every model we put into production ships with accuracy monitoring, a documented retraining procedure, and training for the person on your team who will own it.
How we deliver it
-
1
Discovery 2-3 weeks
We interview the people doing the work, map the data sources, and agree the number that will tell us whether this worked.
-
2
Proof of value 4-6 weeks
One narrow use case built on real data, measured against the baseline. If it does not beat the baseline, we say so.
-
3
Production rollout 8-12 weeks
Integration into the systems staff already use, access control, fallback behaviour, and training for the team.
-
4
Operate and improve Ongoing
Monthly accuracy review, retraining when drift appears, and a quarterly look at what to automate next.
Who this is for
- Manufacturers with repetitive quality, planning or procurement decisions
- Logistics and freight companies drowning in paper documents
- Retail and distribution chains that need demand forecasting
- Service firms answering the same customer questions all day
Why iGlobal
We start from your system of record
Because we implement Odoo as well, the AI work writes back into the same database your accountants and warehouse staff already use. There is no second system to reconcile.
Vietnamese language and local documents
Diacritics, mixed Vietnamese and English fields, stamped and scanned paperwork, VNACCS declarations and local invoice layouts are handled as first class cases, not edge cases.
You own what we build
Source code, documentation and the retraining procedure are yours. We are not interested in keeping you dependent.
The best balance of cost, quality, and service
A local senior team, transparent effort estimates, and no licence margin hidden in the quote. You see what the work costs and what it is expected to return.
Three ways to do this, compared
| What you are comparing | By hand, on spreadsheets | Off-the-shelf software | With iGlobal |
|---|---|---|---|
| Where the AI idea comes from | A demo that impressed someone at a conference | Whatever capability the product already happens to have | A process we measured inside your company before proposing it |
| Proof that it actually works | An opinion formed after a few weeks of use | A case study from a company in another industry | A pilot on your own data with a pass mark agreed in advance |
| When the model starts getting things wrong | Nobody notices until a decision has already been made | A support ticket, with no explanation of the cause | Accuracy tracked monthly, with retraining written into the contract |
| Cost across three years | Hidden inside salaries, so it never appears in a budget | A predictable licence per user, plus the work it cannot do | Quoted per phase and reviewed with you before each one starts |
| Who holds your data | Scattered across files, inboxes and personal phones | On the vendor platform, exported on the vendor's terms | Your own database, exportable in full whenever you ask |
| When something breaks | The person who built the file, if they still work here | A ticket queue, often in another language and time zone | A named engineer in Hanoi you can reach the same working day |
The two middle columns describe approaches that genuinely work for some companies. Where they win, they win, and we have tried to say so.
What changes after go live
The first change is usually not the model, it is that the argument about which number is correct stops. Once the data foundation is in place, finance, operations and sales are reading the same figure, and meetings move from verifying numbers to deciding what to do about them.
The second change is in where your experienced people spend their day. Document automation does not make an accountant redundant; it moves that accountant off three hours of typing and onto exception handling, which is the part that actually needs judgement. Teams consistently report this as the benefit they underestimated most at the start.
The third change is cumulative. Once one process is instrumented and measured, the next candidate becomes obvious, and the second project is always cheaper than the first because the data foundation is already paid for.
- Invoice and document processing time cut by half or more
- Forecast error measured and tracked instead of guessed at
- Repetitive customer questions answered without a human
- A named owner inside your team for every model in production
Frequently asked questions
How much data do we need before AI is worth trying?
Less than most vendors imply. For document automation a few hundred representative samples is usually enough. For forecasting we want eighteen to twenty four months of history so seasonality and Tet are visible. If you do not have that, the honest first project is building the data foundation, and we will tell you so rather than sell you a model.
Will our data be sent to a foreign provider?
Only if you choose that. We design for three options: fully on-premise models running on your own hardware, a private cloud instance in a region you nominate, or a commercial API where only non-sensitive fields are sent. The decision is made in the discovery phase and written into the contract.
What happens if the pilot does not work?
We agree the success measure before we start, so the answer is a number rather than an opinion. If the pilot does not beat the baseline we stop and report why. That outcome is far cheaper than discovering it after a full rollout, and you keep the data foundation, which has value on its own.
Do we need to replace our current software first?
No. We regularly connect to systems that are staying, including MISA accounting, legacy ERP and warehouse software, through scheduled exchanges or APIs. Replacing a working system is a separate decision with its own business case.
Who maintains the system after handover?
You can take it in house, keep us on a support agreement, or mix the two. Whichever you pick, the documentation and retraining procedure are written for a competent engineer who was not on the original project, because that is who will eventually read them.
Related solutions
Talk to a senior consultant, not a call centre
Tell us what you are trying to fix and we will tell you honestly whether we are the right team for it.