# How to add an AI chatbot to Made2Manage > Source: https://netray.co/integrations/made2manage-ai-chatbot > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Integrations ## Short answer A Made2Manage chatbot is a web chat page backed by retrieval over your ERP data and documents. It answers status and how-to questions in plain language, respects who is asking, and can run entirely on your own server with an open-weight model. ## System Made2Manage ## Capability ai-chatbot ## Intro Most of the traffic to a small manufacturer's office is repetitive: where is my order, when does this part arrive, what is the price, how do I enter this transaction. Each answer needs someone to open the ERP. A chatbot removes the middle step for the easy questions and leaves people for the hard ones. Made2Manage has no built-in conversational interface, so the chatbot sits beside it: a web page or an embedded widget in your intranet or customer portal, with a service behind it that looks up the facts. The design question is audience. An internal assistant for planners can see a lot. A customer-facing bot should see almost nothing beyond that customer's own orders. ## Use Cases ### Customer order status **Description:** Authenticated customers ask about their own orders and get status, ship dates and tracking, with no one on your team involved. ### Internal 'how do I' help **Description:** Staff ask how to receive against a PO or handle a scrap transaction and get an answer drawn from your own procedure documents. ### Sales quick facts **Description:** A salesperson asks for last price paid, last ship date and lead time for a customer part before a call. ### Shop floor questions **Description:** A supervisor asks what is queued at a work center and which jobs are overdue, from a tablet. ### Supplier portal queries **Description:** Vendors ask which POs are open and what dates the buyer expects, limited to their own supplier record. ## System Surface - The chatbot reads from SQL Server through a read-only service, usually a replica; exact tables depend on your version and customisations. - Structured questions (status, stock, dates) are answered by tool calls to parameterised queries, not by the model guessing. - Unstructured knowledge (procedures, quality manuals, product notes) goes into a document index for retrieval, kept separate from transactional data. - Identity must map outside the ERP: customers and suppliers need their own login and a mapping to customer or vendor IDs. - Aptean may offer portal or API capabilities in some releases; check before building your own front end. ## How It Works ### Decide audience and scope **Detail:** Start with one audience, usually internal staff. List the questions it must answer and the ones it must refuse. ### Build the lookup layer **Detail:** Create read-only endpoints or an MCP-style tool set for order, job, stock and PO status with role filters. ### Index documents **Detail:** Chunk your procedure and product documents into a vector store, keeping source links for citations. ### Pick the model and host it **Detail:** Serve an open-weight model on a local GPU with vLLM or Ollama, or use a hosted model if policy allows. ### Build the chat front end **Detail:** A simple web page behind single sign-on works well. Add a clear 'talk to a person' route. ### Pilot and tune **Detail:** Run with a small group, review every conversation for a few weeks, and update tools, documents and refusals. ## Example Flows ### Customer asks about an order **Trigger:** Logged-in customer types 'where is PO 4411?' **Steps:** - The bot resolves the customer ID from the login. - It looks up matching sales order lines for that customer only. - It replies with status and expected ship date and offers a human contact. **Result:** The CSR is not interrupted for a routine status check. ### Receiving how-to **Trigger:** Dock worker asks how to receive a partial shipment. **Steps:** - The bot retrieves the receiving procedure from the document index. - It answers in short steps and links the source document. - If nothing relevant is found it says so and routes to the supervisor. **Result:** Fewer wrong transactions from guesswork. ## On Prem A chatbot is a good fit for on-prem because the entire stack is small: a web app, a retrieval index, a lookup service, and one GPU server. Host the open-weight model with vLLM or Ollama, keep the vector store local, and let the chat page live on your intranet. Customers who need access can reach a narrow portal through your DMZ, where it only exposes their own data. Expect to size hardware for concurrent users, and accept that a local model may need more careful prompts and a tighter scope than the largest hosted models. ## Security - Enforce row-level scope in the lookup service, not in the prompt. - Authenticate every user and map them to a role and, for external users, a customer or vendor ID. - Never let the bot reveal cost, margin or other customers' data to an external audience. - Log conversations with retention rules and review them for leakage. - Defend against prompt injection from notes and uploaded text by treating retrieved content as data. ## Options ### Generic chatbot platform plus a data connector **Fit:** You want a quick internal pilot and accept hosted processing. **Effort:** Weeks, plus the connector work against your database. ### Build in-house on open models **Fit:** Technical team and a need to keep everything local. **Effort:** 2 to 3 months for a robust version. ### Partner build such as Netray **Fit:** You want an on-prem assistant with role scoping and review tooling. **Effort:** A scoped pilot of several weeks. ## Pitfalls - Launching to customers before the data scoping has been tested adversarially. - No fallback path to a human, which frustrates users on unsupported questions. - Letting the model answer quantities and dates from memory rather than from a tool. - Indexing outdated procedures and getting confident, wrong how-to answers. - Underestimating concurrent GPU needs during shift starts. ## Faq ### Can the chatbot run completely offline? **Answer:** Yes. With a local open-weight model, a local vector index and a read-only lookup service, nothing needs internet access. You will manage model updates and hardware yourself, and should test answer quality on your own questions before relying on it. ### Is a customer-facing bot a good idea? **Answer:** Often yes for order status, but it needs strict scoping. Authenticate the customer, enforce their ID in the lookup layer, and expose only fields you are comfortable sharing. Start internal, then open a narrow external version once it behaves. ### How does it avoid making things up? **Answer:** Facts come from tool calls to your database, and procedure answers come from retrieved documents with citations. The bot is instructed to say it does not know when neither returns anything, and you review conversations to catch failures. ### Does it need changes inside Made2Manage? **Answer:** Usually none. It reads from a replica or read-only account, so the ERP and its customisations stay untouched. You may add database views, and you will need an identity mapping outside the ERP for customers and suppliers. ### Can the bot enter transactions? **Answer:** It can, but we recommend delaying that. Let it draft requests, such as a receipt or a change, and have a person confirm in the normal application so validation and costing rules still run. ## Search terms made2manage chatbot, ai chatbot for made2manage, made2manage customer portal ai, made2manage order status bot, on-prem erp chatbot, made2manage virtual assistant, add chatbot to made2manage, made2manage natural language --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json