How to add an AI chatbot to ECI M1
Short answer
Put a chat interface on an internal web page or portal, ground it in M1 data through read-only tools and in your documents through retrieval, and filter answers by the asker's role. It can run entirely on-prem with an open-weight model.
M1 holds the answers staff keep asking each other: where is this job, do we have this part, when did that vendor last ship late. Today those answers live behind screens that only trained users navigate quickly, so a lot of questions go through whoever knows M1 best.
A chatbot reduces that load, but only if it is grounded. A bot that guesses is worse than no bot. The design here is a chat front end whose answers are assembled from live M1 lookups and from your own documents, with sources shown.
There are two audiences with different risk profiles: internal staff, who already have M1 access, and customers or suppliers, who must see only their own records. Treat them as separate projects.
What teams use it for
Internal shop-floor helper
Operators and supervisors ask which job is next on a work center, where a part is stocked, or what the current routing step requires.
Customer order-status bot
On a portal, customers ask about their own orders and shipments, with answers limited to their account.
Purchasing assistant
Buyers ask for vendor performance, last price paid and open lines, then have the bot draft a follow-up.
New-hire M1 guide
Retrieval over your internal procedures and training notes tells new staff which screen or report to use for a task, citing the document.
Quality documentation search
Quality staff search procedures, corrective action records and certificates in plain language with links to originals.
ECI M1 integration surface
- SQL Server data via read-only views for live answers such as status and availability.
- Document sources: SOPs, work instructions, certificates and drawings on file shares or a document system, indexed for retrieval.
- Your identity provider (Active Directory or Entra ID) to identify staff and map them to M1 roles.
- A customer or supplier portal, if you have one, as the host for an external bot.
- Any M1-supported messaging or event hooks, which vary by version; otherwise scheduled polling of views.
How it works
- 1
Pick the audience and the top 30 questions
Collect real questions from email, phone logs and chat. Rank them and cover the head of that list first.
- 2
Split questions into data versus knowledge
Status questions need live M1 tools. How-to questions need document retrieval. Route each correctly instead of asking the model to remember.
- 3
Build read-only tools and an index
Create a handful of SQL-view-backed tools plus a vector or hybrid search index over documents, with access metadata on each chunk.
- 4
Add identity and filtering
Identify the user, apply their M1 role or customer scope, and filter both data and documents accordingly.
- 5
Design the answer format
Show the answer, the source records or document links, and a clear I do not know when evidence is missing.
- 6
Pilot with a small group and review logs
Review wrong or unanswered questions weekly and fix tools, indexes or prompts before widening access.
Example flows
Supervisor asks about a part
Trigger: Supervisor types: do we have enough 6061 bar for job 2240?
- Bot resolves the job and its material requirement from the job view.
- It checks on-hand and open supply for the item.
- It answers with quantities, location and the next receipt date.
- It links to the job record.
Result: The supervisor gets a verified answer without leaving the floor terminal.
Customer asks where their order is
Trigger: Authenticated customer on the portal asks about PO 7781.
- Bot restricts queries to that customer's records.
- It reads order lines, shipments and tracking references.
- It states status and expected ship date.
- Anything unusual hands off to customer service with context.
Result: Routine status calls fall, and service reps spend time on exceptions.
Keeping data on-prem
A chatbot over M1 can be fully on-prem: serve an open-weight chat model (Llama, Qwen, Mistral or gemma class) with vLLM or Ollama on a GPU server, host the embeddings and vector index locally, and keep the chat front end on your intranet. For customer-facing use, publish only the front end through a DMZ and keep the model and data tiers inside, passing authenticated, scoped requests inward. Smaller models handle status lookups well when tools do the heavy lifting; reserve larger models for document-heavy questions. Plan for GPU capacity based on concurrent users, not total employees.
Security checklist
- Enforce user-level data filtering in the tool layer, not just in the prompt.
- For external users, scope every query by customer or vendor identifier derived from authentication, never from the user's message.
- Keep document access control lists with indexed chunks so restricted files do not leak into answers.
- Rate limit and log conversations; define retention rules for chat logs that may contain business data.
- Add prompt-injection defences, since documents and part descriptions can contain hostile text.
Ways to get it done
Vendor or reseller portal features, if available for your version
Effort: Configuration, depending on the module.
Enough when you only need fixed self-service status pages.
Open-source chat front end plus your own tools and index
Effort: Several weeks for a pilot.
Good for internal-only bots with a capable developer.
Partner-built grounded chatbot, on-prem if needed
Effort: A scoped pilot, often weeks.
When you need role scoping, evaluation and private hosting.
Pitfalls
- !Answering from model memory when no record is found instead of saying so.
- !Mixing internal and customer-facing data in one index without access control.
- !Skipping a human handoff path for angry or complex cases.
- !Indexing stale documents so the bot cites superseded procedures.
- !Underestimating GPU concurrency needs at shift change.
Frequently asked questions
Can the chatbot see all of our M1 data?
It should only see what you expose through tools. Start with a few read-only views and apply per-user filtering. Never give a chatbot unrestricted database access.
Can customers use it?
Yes, with strong authentication and queries scoped to their own records by the tool layer. Treat it as a separate, higher-risk deployment from the internal bot and test it adversarially.
Does it need a big GPU?
Not for most M1 use. Tool-grounded answers over short results run well on a single modest GPU server with a mid-sized open model. Size for peak concurrent chats and for any document summarisation.
How do we stop wrong answers?
Ground every answer in tool results or retrieved passages, show sources, require I do not know when evidence is missing, and review logs weekly with a test set of known questions.
Is the vendor's own assistant enough?
If your M1 version ships a suitable one and it covers your questions, use it. A custom bot earns its place when you need your own documents, tighter privacy or a specific workflow.
Want AI chatbot working on your ECI M1?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment