How to add an AI chatbot to QAD Adaptive ERP
Short answer
An AI chatbot for QAD answers questions from live ERP data and your documents, shows the source of each answer and respects user roles. Build it with a retrieval layer over procedures and a read-only tool layer over OpenEdge or QAD services; it can run fully on-prem with an open-weight model.
Staff on QAD ask the same questions over and over. Where is my order? What is the lead time on this item? How do I process a return? Each one interrupts a planner, a customer service rep or a trainer.
A chatbot that handles the common ones frees those people, but only if the answers are right. A chatbot that guesses about stock levels is worse than no chatbot. The design has to ground every number in a tool call and every procedure in a document.
This page covers how to build one for QAD, including two audiences with different risk profiles: internal staff and external customers or suppliers.
What teams use it for
Internal how-do-I help
Staff ask how to process a receipt, a return or a scrap entry in your QAD configuration, and the bot answers from your own procedure documents with the source linked.
Customer order status portal
A customer-facing bot looks up their orders by account and returns ship dates and tracking, restricted to their data only.
Supplier self-service
Suppliers ask which POs are open and what is due, and confirm dates, with confirmations queued for buyer review.
Inventory questions on the floor
A supervisor asks if an item is available at a location and gets the on-hand and the next receipt date.
Quote and lead time questions
Sales asks for a realistic lead time on a configured item and the bot reads routing and material supply to estimate it, flagged as an estimate.
Role-aware finance answers
Finance staff ask about open invoices or receipts not invoiced, while the same question from a planner is declined.
QAD Adaptive ERP integration surface
- OpenEdge SQL on a replica for fast read-only lookups of items, orders, inventory and work orders.
- QAD web services and QXtend for functions that require application logic or for governed write-backs.
- Document stores: procedure documents, work instructions and training notes, indexed for retrieval.
- Identity: your directory or identity provider, mapped to QAD users, domains and roles.
- Customer and supplier portals: if you expose external users, QAD customer and vendor master data defines their allowed records.
How it works
- 1
Pick the audience
Internal first. External users add authentication, abuse handling and legal review.
- 2
Index your documents
Chunk procedures and work instructions, keep their titles and owners, and rebuild the index when they change.
- 3
Build the data tools
Create parameterised read tools for the top twenty questions, each returning small structured results.
- 4
Route questions
The model decides whether a question is a document question, a data question or both, and calls the right source.
- 5
Ground and cite
Every answer shows its source: the document section or the query and timestamp.
- 6
Add escalation
If confidence is low or a request needs a change, hand off to a person with the conversation attached.
- 7
Measure
Track resolved questions, escalations and wrong answers reported by users.
Example flows
Customer asks where an order is
Trigger: A logged-in customer types: where is my order for the housing assembly?
- The bot resolves the customer account from the login.
- It calls the order lookup tool limited to that account.
- It reads line status, promised date and shipment records.
- It replies with the status and offers to notify them of changes.
Result: A routine inquiry is answered without a service rep, and no other customer's data is reachable.
Staff procedure question
Trigger: A receiving clerk asks how to handle an overshipment.
- The bot searches the receiving procedure index.
- It finds the overshipment section.
- It answers with the steps in your wording and links the document.
- It notes the document's revision date.
Result: Consistent answers that follow the controlled procedure, not generic advice.
Keeping data on-prem
Everything required runs inside your network: an open-weight model on local GPUs with vLLM or Ollama, a vector index on your own server, and read access to the OpenEdge replica. This suits QAD customers with defense or customer contract restrictions, and it avoids sending internal procedures to a third party. Internal chat can be served only on the plant network. For external customer chat, place the web tier in a DMZ, keep the model and data tools inside, and pass only authenticated, scoped requests through. A smaller model is often enough for lookup-and-explain tasks; save larger models for the hard reasoning cases.
Security checklist
- Enforce role and account scope inside the data tools, never in the prompt alone.
- Treat any user-submitted text as untrusted and test for prompt injection.
- For external users, show only fields you would show in an existing portal and never cost data.
- Keep chat logs under the same retention rules as other business records.
- Disclose that users are talking to an AI and give a route to a human.
Ways to get it done
Vendor-provided assistant
Effort: Weeks of configuration
Good when QAD's own assistant covers your needs. Ask QAD what exists for your release and cloud status.
General chatbot platform plus API
Effort: 1 to 3 months
Faster to launch but you must solve grounding and role scoping yourself.
Private build with Netray
Effort: Typically a few weeks for a scoped internal pilot
For on-prem data, strict role scoping and open-weight models.
Pitfalls
- !Answering stock or date questions from the model's memory instead of a tool call.
- !Indexing outdated procedures with no revision control.
- !Launching to customers before staff trust it internally.
- !Missing multi-site and multi-domain scoping, so answers mix plants.
- !No escalation path, leaving users stuck.
Frequently asked questions
Can the chatbot update QAD?
It can propose changes, but writes should go through an approval step and QXtend or another supported path. Start read-only and add narrow write actions later.
How does it avoid wrong answers?
By grounding: numbers come from tool calls against QAD data and procedures come from indexed documents, each shown with its source. When it cannot ground an answer it should say so and escalate.
Will it work on QAD Cloud?
Yes, though access paths differ. Without direct database access you rely on QAD APIs, QXtend or approved extracts, which may limit freshness. Confirm options with QAD.
Can customers use it?
Yes, with strict authentication, per-account scoping and a limited tool set. Many teams run it internally first, then open a narrow external scope.
What model size do I need?
For lookup and explanation, a modest open-weight model on a single GPU often suffices. Test with your real questions and measure accuracy before sizing hardware.
Want AI chatbot working on your QAD Adaptive ERP?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment