How to Compare ISO Consultants Before You Sign

Ask what exactly gets delivered, who owns it after handover, which decisions stay human, and what happens if you want to leave — before you sign, not after. Most ISO 9001 contract disputes in Thai manufacturing trace back to one of those four questions never being asked out loud. If you are trying to compare ISO consultants in Thailand side by side, these are the questions that actually separate them, not the glossy parts of the pitch deck.

This is not a list of "gotcha" questions designed to trip up a salesperson. It is the minimum due diligence for a contract that will shape how your document control runs for years, and that most buyers only think to ask after something has already gone wrong.

Why comparing ISO consultants in Thailand takes more than the sales deck

A proposal document tells you what a vendor wants to emphasize. A signed contract tells you what you are actually entitled to. The gap between those two documents is where most disappointment lives — a demo that showed automated registers, a contract that turns out to cover only a discovery workshop; a pitch about "AI-powered ISO," a deliverable that is a slide deck and a recommendation.

Asking direct questions before signing forces the gap to close in writing, while you can still negotiate it. Once the contract is signed, the scope in that document is what you get, regardless of what the sales conversation implied.

The questions, grouped by what they actually protect

Scope and deliverable

• What is the exact, named deliverable — a report, a set of procedures, a configured platform, or a running system? Ask for this in writing, not as a category.
• Which parts of our document control process does this cover, and which parts are explicitly out of scope?
• If the deliverable is software or an automated workflow, can I see it running against a scenario close to my own process before I sign, not just a generic demo?
• What does "done" look like, and who signs off that it is done? Vague completion criteria are how projects run indefinitely on additional invoices.

Human decision gates

• Which review and approval steps in our current process stay in human hands, explicitly, in the contract — not just in the sales conversation?
• Does anything in this system make a content-adequacy judgment on a document, or does it only execute after a human has already decided?
• Can you show me, concretely, how a reviewer's and an approver's decisions are preserved in the workflow, rather than replaced by a rule or a script?

Any vendor who cannot answer the second question plainly, or who describes their system as "reviewing" or "approving" documents, is describing something ISO 9001 does not actually permit. Clause 7.5 requires competent human review of document adequacy — a system that quietly makes that call itself is not compliant, whatever the pitch says.

Ownership and lock-in

• Who owns the system, the workflow logic, and the underlying data once the engagement ends — us, or the vendor?
• If we stop paying a subscription or support fee, does the system keep running, or does it stop functioning?
• Is our data stored in infrastructure we control (our own Google Workspace, our own server), or in the vendor's proprietary environment?
• What does an exit look like — can we export our registers, our logic, and our history in a usable format if we ever switch providers?

Acceptance and verification

• How will we know the system actually works before we are asked to sign off on final payment? Is there a defined set of acceptance criteria, or is "looks good" the standard?
• Will anything outside the scope of this project — our other spreadsheets, our other automated workflows, our existing documents — be touched or altered? How will that be verified?
• Is there a written test or checklist we both agree to before go-live, so "it works" is not a matter of opinion after the invoice is sent?

Cost structure

• What is included in the quoted price, and what is billed separately — support, changes after go-live, additional document types, training?
• Is the certification-body audit fee separate from this engagement, and has anyone explained how the two relate?
• What triggers additional cost during the project — scope changes, extra revision cycles, integration with systems we did not originally mention?

Timeline and support after go-live

• What happens in the weeks after go-live — is there a defined support window, or does the relationship end the moment the invoice clears?
• If we find a bug or an edge case the system did not handle three months in, is fixing it covered, or is it a new line item?
• Who do we call if the system stops working on a Monday morning and a document is stuck mid-approval? Is there a named contact, or a generic support inbox?
• Does the vendor expect our process to stay exactly as it is, or is there a path to extend the system if our document types or SOPs change later?

These questions matter because a system that works perfectly on day one and is unmaintainable by month six has the same practical effect as a system that never worked at all. The contract should say, specifically, what support looks like after handover — not just what happens during the build.

A shortlist comparison table

Use this as a scoring sheet across the vendors you are evaluating — fill in each vendor's actual answer, not their marketing language.

A row full of vague or evasive answers is more informative than any single answer on its own.

What the answers should sound like from a builder, not a consultant

A vendor who builds systems rather than writes reports should be able to point to something concrete when you ask these questions — a workflow you can watch run, an activity log you can inspect, acceptance criteria stated as a number, not an adjective. The difference between a QMS software vendor, an implementation consultancy, and a certification body matters here too, because the right questions depend partly on which category you are actually talking to — a certification body should never be answering the "who owns the system" question at all, because they are not permitted to build one for you.

If you are still deciding whether to build in-house, buy an off-the-shelf platform, or commission a custom build, the build-versus-buy-versus-commission comparison is worth reading before you start collecting proposals — it changes which of these questions matter most for your situation. And if two vendors are both pitching "software," comparing what each type of QMS software actually solves will help you tell whether they are even offering the same thing.