How to add an AI chatbot to Epicor Vantage and Epicor 9
Short answer
Put a chat front end on an internal service that answers from Epicor data read via ODBC or business objects, filters results by the asking user's role, and cites the records it used. It can run fully on-prem with an open-weight model, which suits older Epicor sites with sensitive part and customer data.
Epicor 9 screens are powerful but dense. A new buyer needs weeks to learn where to find due dates, receipts and supplier history. A chatbot that answers 'when is PO 4412 due and what job needs it' removes much of that friction, if it is grounded in the real data.
A chatbot is not the same as an agent or an MCP server, though it may use the same plumbing. Its job is conversation: understand the question, retrieve the right records, answer in plain language, and show where the answer came from. The quality bar is trust, not cleverness.
On older Epicor installs the most valuable bots are narrow and role-based: one for the shop floor and supervisors, one for purchasing, one for customer service. Starting there keeps scope small and answers verifiable.
What teams use it for
Customer service order lookups
CSRs ask where a customer order stands and get lines, promise dates, shipments and tracking in one reply, with the underlying order numbers shown.
Shop floor supervisor questions
Supervisors ask what is queued at a work center, which jobs are late and what material is missing, with answers drawn from JobOper and JobMtl data.
Buyer helper
Buyers ask about open releases for a vendor, last purchase price and lead time history, then ask for a draft email to the supplier.
Policy and procedure answers
Using a document index of work instructions and quality procedures, the bot answers 'what is our process for a rejected receipt' alongside live ERP data.
Customer portal assistant
External customers ask about their own orders and shipments only, with strict customer-scoped queries and no access to internal cost data.
Epicor Vantage / Epicor 9 integration surface
- OpenEdge database via ODBC or JDBC, read-only, best on a replica; the main source for grounding answers.
- Business objects for validated reads when you prefer Epicor's own logic, or when row-level rules are enforced there. Style and availability vary by version.
- Epicor security groups and user accounts, which should drive what each chatbot user is allowed to see. These do not automatically carry into a custom chatbot, so you map them explicitly.
- Attachments, drawings and procedure documents on file shares, which a retrieval index can cover for non-transactional questions.
- Epicor Web Access or a customer portal front end, if you want to embed the chat in an existing page. Embedding options depend on your deployment.
How it works
- 1
Choose the first audience
Pick one role with frequent repeated questions, such as customer service. A single role keeps permissions and evaluation simple.
- 2
Collect the real questions
Gather 50 to 100 questions people actually ask and the Epicor screens they use to answer them. This becomes both design input and your test set.
- 3
Build the retrieval and tool layer
Create parameterised queries for the common lookups, and a document index for procedures. The bot should call these, not improvise SQL.
- 4
Map identity to scope
Authenticate with your directory, map each user to their Epicor role and, for customers, to their customer ID. Every query filters accordingly.
- 5
Design the answer format
Answers lead with the fact, then show source records. If data is missing or ambiguous, the bot asks a clarifying question instead of guessing.
- 6
Deploy the front end
A simple web chat on the intranet, a Teams tab, or an embedded widget in your portal. Start internal.
- 7
Review conversations weekly
Read failed and thumbs-down chats, fix tools and prompts, and extend the question set.
Example flows
CSR checks an order
Trigger: Message: 'Status of order 88123 for Delta Tools?'
- Bot resolves the customer and order, confirming the user may see them.
- It retrieves lines, promised dates and shipments.
- It identifies line 3 as late and checks the feeding job.
- It answers with the delay reason and a suggested customer message.
Result: The CSR replies in a minute without switching between order, job and shipping screens.
Supervisor asks about a cell
Trigger: Message: 'What is behind at the lathe cell today?'
- Bot lists jobs with operations at those work centers, ordered by due date.
- It highlights ones with missing material.
- It suggests which job to sequence first based on due date and setup family if that data exists.
Result: A shift briefing that supervisors can verify against the dispatch list.
Keeping data on-prem
A chatbot on Epicor 9 is an easy case for fully on-prem deployment. Host an open-weight model on a GPU server in your network, use a local embedding model for the document index, and keep the Epicor replica and bot service on the same segment. Users reach the chat through the intranet or VPN, so prompts, part numbers and customer details never leave your environment. Plan for model updates, GPU capacity at peak hours and a refresh schedule for the replica so answers are timely enough for the audience.
Security checklist
- Enforce role and customer scoping in the data layer, not in the prompt.
- Block cost, margin and supplier pricing tools for roles that should not see them.
- For external users, authenticate separately and restrict to their own customer records.
- Store conversation logs securely and decide retention; they may contain commercial details.
- Add a refusal path and a handoff to a human for anything the bot cannot ground in data.
Ways to get it done
Build on a generic chatbot platform with a custom data connector
Effort: Several weeks, mostly connector and permission work.
Works if the platform can call your internal API and keep data in your environment.
Use Epicor's own AI features after upgrading to Kinetic
Effort: Driven by the upgrade project.
Reasonable if an upgrade is already planned; avoids custom plumbing.
Netray on-prem chatbot grounded in Epicor
Effort: A pilot with one role is typically weeks.
When you need open models, role-aware answers and visible sources without cloud exposure.
Pitfalls
- !Letting the bot answer from general knowledge when ERP data is missing, producing plausible but false dates.
- !Reading from a stale replica and not telling users how fresh the data is.
- !Skipping customer scoping on a portal bot, which is a data exposure risk.
- !Launching to everyone at once, then drowning in edge cases.
- !Not showing sources, so users cannot verify and eventually stop trusting it.
Frequently asked questions
Can a chatbot see live Epicor 9 data?
Yes, via ODBC to the Progress database or through business objects. Most teams use a read replica refreshed frequently, and the bot states the data timestamp. True real-time is possible but adds load and risk on the production database.
Can customers use it?
Yes, with strict scoping. Authenticate each customer, restrict every query to their customer ID, and expose only order, shipment and document tools. Do not expose costs, other customers or internal notes.
Does it need the internet?
No. With an open-weight model and local embeddings on your own GPU server, it can run entirely inside your network. You trade some model quality for control, and you manage updates and hardware yourself.
How accurate is it?
Accuracy depends on grounding. When answers come from specific queries and show the records used, it can be checked against Epicor. Measure it on your own question set before rollout, and review live conversations afterwards.
Is a chatbot better than just training users?
They complement each other. Training is still needed for transactions. A chatbot cuts time spent finding information and helps occasional users, but it should not replace knowing the system.
More for Epicor Vantage / Epicor 9
Want AI chatbot working on your Epicor Vantage / Epicor 9?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment