Skip to content
eQMS buyer's guide

How to evaluate any eQMS

Eight questions worth asking every vendor, including us.

A feature list can tell you what a platform claims to do. It rarely tells you what your team will need to configure, validate, maintain, pay for or do if you leave. Use these questions in every vendor conversation.

Start with the 8 questions See qmsWrapper live

Published by qmsWrapper. Designed to be used with every eQMS vendor you evaluate.

Look past the feature list

What matters is how the system works after the demo.

Most serious eQMS platforms can show document control, training, CAPA and audit trails. The decision often turns on the work around those features: how your records connect, who configures the system, how changes are handled, and what your organisation owns.

There is no single eQMS that fits every organisation. A startup setting up its first controlled processes may need a different balance of structure, flexibility and support than a multi-site manufacturer with established systems and integrations.

Your demo checklist

Eight questions to take into the room.

Jump to a question, note the answer, then ask the vendor to show you the workflow in the product.

Ask. Listen. Ask to see it.

A confident answer is useful. A concrete demonstration, a named owner and supporting documentation are better.

Question 01

What will implementation actually require from our team?

Ask for a realistic plan that names your team's work, vendor work, decision points and go-live criteria. “Fast implementation” has little meaning without a clear scope.

Implementation is a joint project. Your team may need to define processes, select and clean records, assign owners, make configuration decisions, review migrated data, complete assurance activities and train users. The effort depends on what you bring forward and how much you change.

What a strong answer sounds like

  • A phased plan with activities, owners, dependencies and acceptance criteria.
  • A realistic estimate of customer time by role, not just a calendar duration.
  • Clear scope for document migration, process setup, training and validation support.
  • A distinction between the vendor's standard onboarding and paid services.

Red flags

  • A fixed go-live promise before anyone has scoped your records or processes.
  • “We do it all for you” without explaining what your quality team must review and approve.
  • No plan for user adoption, migrated-record checks or post-launch support.
  • The project depends on a single internal person with no backup owner.

Ask the vendor to show you

  • A sample implementation plan for an organisation similar to yours.
  • A responsibility matrix and an example weekly workload for your team.
  • What is included in onboarding, what is optional and what changes the quote.

Try this scenario

“We have 40 current SOPs, 12 forms and several spreadsheet logs. Which of these would you bring over first, who does each step, and what would a realistic first release look like?”

Question 02

What can our team configure and maintain without vendor help?

Find out which changes administrators can make themselves, which need vendor services or custom code, and how those changes are controlled.

Your QMS will change as products, responsibilities and processes change. A platform can be configurable yet still leave routine changes dependent on a vendor or specialist. More flexibility is not automatically better either: changes need permissions, review, testing and a clear history.

What a strong answer sounds like

  • Specific examples of customer-managed forms, roles, workflows, fields and notifications.
  • Clear boundaries between supported configuration, vendor services and custom development.
  • Role-based permissions and a record of who changed what and when.
  • A way to test or review a change before it affects controlled work.

Red flags

  • “Fully configurable” with no live example or explanation of limits.
  • Routine changes require a support ticket or paid professional services.
  • Configuration changes are hard to review, test or reverse.
  • The vendor cannot explain how custom code affects future upgrades.

Ask the vendor to show you

  • Build or modify a simple approval workflow and form in a demo tenant.
  • Show the permission controls, change history and review process.
  • Explain how a configured process is promoted from test to production.

Try this scenario

“Our supplier change process now needs an additional quality review. Can our administrator make that change, test it, approve it and see who changed it?”

Question 03

Can the system connect a quality signal to its decisions and evidence?

Ask the vendor to follow one real event through triage, investigation, risk or design impact, action, training and closure, showing the records linked along the way.

A list of modules does not show whether records work together. If people have to re-enter information or manually rebuild links, a platform may still leave important work fragmented. The right depth depends on your products and obligations, so test the workflows you actually use.

What a strong answer sounds like

  • The vendor explains which links are native, configurable, integrated or manual.
  • A record's history, approvals, electronic signatures and related evidence can be followed in context.
  • Changes to a document or process can be assessed for affected training, risks, design evidence or technical documentation where relevant.
  • The vendor is clear about which capabilities are in the proposed scope and which are not.

Red flags

  • The demo jumps between modules but does not show how records relate.
  • “Traceability” means only a hyperlink or a manually maintained spreadsheet.
  • Important records must be duplicated, or links break when records change.
  • A capability is described as included but is only available in another tier or add-on.

Ask the vendor to show you

  • A complete complaint, nonconformity or change workflow from intake to closure.
  • How the system connects a record to CAPA, risk controls, requirements, training and approvals as applicable.
  • Which records are included in the quote and which require another module, tier or service.

Try this scenario

“A supplier changes a material specification. Show us how we would assess the impact on incoming inspection, device risk, design evidence, affected procedures and employee training.”

Question 04

What does “validated” mean for our intended use, including after updates?

Ask what the vendor tests and documents, what your organisation must assess and approve, and how you handle configuration and future software changes.

A vendor's validation package can support your assurance work, but it cannot define your intended use or make your organisation's decisions for you. FDA's current Computer Software Assurance guidance describes a risk-based approach for software used in medical-device production or the quality management system. Your quality system and applicable requirements determine what evidence is appropriate for your use.

What a strong answer sounds like

  • The vendor distinguishes its software testing and release evidence from your assessment of intended use and configured processes.
  • It provides current, reviewable evidence such as test summaries, release notes and relevant validation documentation.
  • It explains how customers assess updates and configuration changes, including who owns each step.
  • It can discuss electronic records, signatures and audit trails in the context of the product's intended use.

Red flags

  • “We are validated, so you do not need to do anything.”
  • No accessible evidence, unclear scope or no explanation of your responsibilities.
  • Updates are made without useful change information or an impact-review path.
  • A generic certificate is presented as proof that your configured system is suitable for your use.

Ask the vendor to show you

  • The validation or assurance package available to customers, with a list of contents.
  • A recent release note and an example of how a customer evaluates its impact.
  • How configuration, user roles, audit trails and e-signatures are covered in the available evidence.

Try this scenario

“A release changes the approval workflow we use for document control. What information do you provide, what do you test, and what would you expect our quality team to assess?”

Question 05

How are our data and records protected, backed up and returned if we leave?

Ask where your data is hosted, who can access it, how continuity is managed and what a complete, usable export looks like at contract end.

The system will hold controlled records your organisation may need for audits, product history and business continuity. Evaluate security and exit together: a platform is not portable just because a contract says data can be exported, and a backup is not the same thing as an export you can use independently.

What a strong answer sounds like

  • Clear answers on hosting regions, subprocessors, access controls, encryption, incident response and continuity.
  • Backup and recovery arrangements with defined responsibilities and service expectations.
  • A documented export process covering records, attachments, metadata, relationships, signatures and audit history as applicable.
  • Contract terms explain timing, format, assistance, fees and deletion after exit.

Red flags

  • “Your data is secure” with no current documentation or specifics.
  • Unknown hosting location or no usable subprocessors and incident information.
  • An export is a collection of PDFs that omits key metadata, links or history you need.
  • Exit assistance, retrieval windows or deletion terms are left unclear.

Ask the vendor to show you

  • Its security and continuity documentation, plus the current hosting and subprocessor details.
  • A sample export, preferably from a test environment, and the included file types and metadata.
  • The contract clauses that govern access, exit, assistance, fees and deletion.

Try this scenario

“If we gave notice next month, how would we retrieve our approved SOPs, training records, CAPA history, attachments, signatures and audit trails in a form we can retain and search?”

Question 06

What is included in the price, and what will change as we grow?

Compare the total cost of the scope you need today and the likely cost of adding users, sites, products, modules, integrations, services and support.

A headline subscription price is only one part of the cost. Commercial models vary: some price by user, some by product, entity, scope or service level, and some charge separately for setup or add-ons. Compare like-for-like scope over the contract term rather than assuming one model is cheaper.

What a strong answer sounds like

  • A written quote maps each requested capability to a plan, module, add-on or service.
  • It spells out implementation, migration, training, support, storage, integrations and renewal assumptions.
  • It explains what happens to price when you add users, products, legal entities, sites or functionality.
  • There is a clear renewal, price-change and cancellation policy.

Red flags

  • A demo includes capabilities that are absent from the quote.
  • Important limits or add-on fees appear only after selection.
  • The vendor will not model a realistic second-year scenario.
  • “Unlimited” is used without defining what remains limited or separately priced.

Ask the vendor to show you

  • A written quote for your current scope and an example of a plausible growth scenario.
  • Which costs are one-time, recurring, usage-based or optional.
  • Any included seat, site, storage, API or support limits, and the cost to exceed them.

Try this scenario

“We expect to add a second product, more users and one additional site within two years. Please show how the annual and one-time costs would change.”

Question 07

Which API and MCP connection options can we use, and what can each access or change?

Ask the vendor to show how its API connections and MCP server work in practice, which QMS records and actions are in scope, and how access is authenticated, limited, monitored and revoked.

APIs can connect the eQMS with other business systems; an MCP server can make selected QMS tools and records available to AI assistants. Ask about both, even if you expect to use only one. A protocol name or integrations list does not tell you what data moves, whether the connection is read-only or can write, or who controls access.

What a strong answer sounds like

  • The vendor identifies which API connections, endpoints, webhooks or MCP tools and resources are available, and what data each can read or change.
  • It explains data direction, sync frequency, authentication, permissions and limits, including whether access follows the user's own role.
  • If one method is unavailable, the vendor says so plainly and explains the supported alternative for your use case.
  • Connections can be monitored, errors can be investigated, and access can be revoked or credentials rotated.
  • Changes made through an integration or AI assistant are traceable in the relevant records; human approvals remain controlled by authorised people.

Red flags

  • “We have an API” or “we support MCP” without showing available operations, data scope or limitations.
  • It is unclear whether a connection is read-only, one-way, or able to create or update controlled records.
  • Connections use broad shared credentials, have unclear permission boundaries, or cannot be promptly disabled.
  • Failures, integration costs, support ownership or records of automated changes are left unexplained.

Ask the vendor to show you

  • Current API documentation and, if applicable, the MCP tool/resource list and supported clients.
  • A relevant connection in a test environment: show a read, a permitted write if available, and the resulting audit history.
  • How permissions are granted and revoked, how errors are surfaced, and which integrations or API/MCP features cost extra.

Try this scenario

“We track design tasks in Jira and want an AI assistant to find approved SOPs and related open change controls. Show which connection method or methods you would use, what data moves, the access controls, and how any proposed change is reviewed and recorded.”

Question 08

What does AI do with our QMS data, and who remains accountable?

Ask which AI tasks are available in your plan, what data they use or send, how outputs are checked, and what the system records about AI-assisted work.

AI can help search, summarise, draft or suggest links, but the useful details are in the boundaries. Understand whether AI is optional or included, which provider processes data, whether your information is used to train models, how users can inspect sources and how human review is recorded.

What a strong answer sounds like

  • AI use cases and plan availability are specific, with clear limits on what the system can do.
  • The vendor explains data flow, model providers, retention and whether customer data is used for training.
  • Users can inspect, edit and reject outputs; authorised people retain approval and decision responsibility.
  • AI-generated or AI-assisted changes are identifiable and traceable in the record history.

Red flags

  • AI is described only as “secure” or “compliant” without explaining data handling.
  • Outputs are inserted into controlled records without a review step.
  • It is unclear whether AI features cost extra or send records to a third-party model.
  • The vendor cannot explain how incorrect or unsupported outputs are caught.

Ask the vendor to show you

  • A live AI workflow using a representative, non-confidential example.
  • The source records behind a generated answer and the review/approval steps.
  • AI data-flow documentation, feature-tier details and the audit trail for AI-assisted changes.

Try this scenario

“Ask the system to identify which procedures, risks and training records may be affected by a supplier change. Show us the sources, how a user checks the suggestions and what is recorded when they accept or reject them.”

Use it across vendors

A simple eQMS evaluation scorecard

Score each vendor after the demo, using the evidence you saw. “Not shown” is useful information. Add a short note so your team remembers why you gave the score.

Evaluation questionVendor AVendor BVendor CNotes / evidence to follow up
01 · Implementation effort
02 · Configuration and control
03 · Connected workflows
04 · Validation and updates
05 · Security and data exit
06 · Total cost and growth
07 · API / MCP access and controls
08 · AI governance

Score from 1 (not demonstrated or does not meet your need) to 5 (clear evidence and a good fit). Weight the questions that matter most to your organisation. The scorecard supports discussion; it does not choose a vendor for you.

Put these questions to us

Use the same questions on qmsWrapper.

We published this guide, so bring it to a walkthrough. Ask us to show the workflows, scope, implementation responsibilities and evidence that matter to your team. If another platform fits your needs better, that is a useful outcome too.

See it live
Sources and methodology

Method: reviewed current qmsWrapper pages and public vendor/regulator material, then selected eight buyer questions that cover project effort, operating control, workflow fit, assurance, data risk, commercial scope, interoperability and AI governance. Vendor feature and pricing pages describe each vendor's own offer; this guide does not rank vendors or treat marketing claims as independent proof. Reconfirm contracts, security documents and regulatory expectations with the vendor and your own quality team before purchase.