# How to add an AI chatbot to ECI M1 > Source: https://netray.co/integrations/eci-m1-ai-chatbot > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Integrations ## 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. ## System ECI M1 ## Capability ai-chatbot ## Intro 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. ## Use Cases ### Internal shop-floor helper **Description:** 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 **Description:** On a portal, customers ask about their own orders and shipments, with answers limited to their account. ### Purchasing assistant **Description:** Buyers ask for vendor performance, last price paid and open lines, then have the bot draft a follow-up. ### New-hire M1 guide **Description:** 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 **Description:** Quality staff search procedures, corrective action records and certificates in plain language with links to originals. ## System 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 ### Pick the audience and the top 30 questions **Detail:** Collect real questions from email, phone logs and chat. Rank them and cover the head of that list first. ### Split questions into data versus knowledge **Detail:** Status questions need live M1 tools. How-to questions need document retrieval. Route each correctly instead of asking the model to remember. ### Build read-only tools and an index **Detail:** Create a handful of SQL-view-backed tools plus a vector or hybrid search index over documents, with access metadata on each chunk. ### Add identity and filtering **Detail:** Identify the user, apply their M1 role or customer scope, and filter both data and documents accordingly. ### Design the answer format **Detail:** Show the answer, the source records or document links, and a clear I do not know when evidence is missing. ### Pilot with a small group and review logs **Detail:** 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? **Steps:** - 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. **Steps:** - 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. ## 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 - 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. ## Options ### Vendor or reseller portal features, if available for your version **Fit:** Enough when you only need fixed self-service status pages. **Effort:** Configuration, depending on the module. ### Open-source chat front end plus your own tools and index **Fit:** Good for internal-only bots with a capable developer. **Effort:** Several weeks for a pilot. ### Partner-built grounded chatbot, on-prem if needed **Fit:** When you need role scoping, evaluation and private hosting. **Effort:** A scoped pilot, often weeks. ## 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. ## Faq ### Can the chatbot see all of our M1 data? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms eci m1 chatbot, ai chatbot for eci m1, eci m1 ai assistant, chat with eci m1 data, eci m1 customer portal chatbot, on-prem erp chatbot, eci m1 natural language query, eci m1 virtual assistant, private chatbot manufacturing erp --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json