How to add an AI chatbot to MRPeasy
Short answer
An AI chatbot for MRPeasy is a chat front end whose answers come from live lookups against the MRPeasy REST API, not from the model's memory. Build one for staff first, then a narrow customer-facing version limited to the orders that customer owns.
MRPeasy has a customer portal-style set of features and a good deal of reporting, but people still interrupt each other all day with the same questions. Where is my order? Do we have this in stock? When can we ship a hundred of these? A chatbot removes the interruption without removing the planner.
The key idea is grounding. The bot should never answer from general knowledge about your business. It should translate a question into one or two API lookups, read the result, and respond with the numbers and the record references it used.
Two audiences need different bots. Staff can ask broad questions with broad access. Customers should only see their own orders and a limited set of fields, enforced by your code and not by instructions to the model.
What teams use it for
Customer order tracking
A customer enters an order reference and email, and the bot returns status, expected ship date and tracking if recorded.
Stock and availability questions
Sales asks if an item is available and gets on-hand, reserved and expected receipts, with the date of the next supply.
Lead time estimates
Based on the BOM and current purchase lead times, the bot gives a first estimate and marks it as indicative.
Shop floor questions
A supervisor asks which jobs are queued on a work center today and which are waiting on material.
Procedure help
Staff ask how to receive a partial shipment or create a rework order, answered from your internal procedures with pointers to the right screen.
After-hours first line
Out-of-hours questions are answered or logged as a request that the team sees in the morning.
MRPeasy integration surface
- REST API with key and secret authentication for read lookups of orders, items, stock, purchase orders and manufacturing orders. Confirm paths and fields in your account documentation.
- MRPeasy user accounts and roles govern what staff can see in the app. The bot needs its own mapping of staff identity to allowed data, since the API key itself is a service credential.
- Customer identity is not the same as an API user. Use your own login, a signed link or an email verification flow to bind a customer to their customer ID.
- Hosted product, no database access. For fast chat responses, sync key tables to a local store on a short schedule.
- Export options for documents and reports can feed the procedure knowledge base.
How it works
- 1
Pick the audience and scope
Start with an internal bot on read-only tools, and delay the customer-facing version until the answers are consistently right.
- 2
Build the lookup layer
Create functions for order status, stock, purchase orders and BOM. The model chooses a function, your code runs it, and the model phrases the result.
- 3
Add a document index
Load SOPs, work instructions and FAQs into a retrieval index so how-to questions are answered from approved text.
- 4
Enforce identity and row-level access
For customers, filter every query by the verified customer ID in code. Never rely on a prompt to keep data separate.
- 5
Design the chat surface
Embed in an intranet page, a Teams tab, or a web widget on your site, with a clear human handoff button.
- 6
Review transcripts
Read a sample of conversations weekly, tag wrong answers and fix tools or content, not just the prompt.
Example flows
Customer asks where their order is
Trigger: A customer opens the chat widget and gives an order number and verified email.
- The service verifies the email against the customer record.
- It fetches the order and linked manufacturing and shipment records.
- The bot reports the stage and expected ship date in one short message.
- If the date has passed, it offers to notify the account manager.
Result: A routine status call is closed without staff involvement, and exceptions are routed with context.
Sales availability check
Trigger: A salesperson types: can we ship 200 of product X by the 30th.
- The bot resolves the product and fetches stock and BOM components.
- It checks open purchase orders and manufacturing orders against the date.
- It returns yes, no or at risk with the limiting component.
- It offers to draft a note to the planner.
Result: Sales has a grounded first answer to give the customer while the planner confirms.
Keeping data on-prem
A fully private chatbot for MRPeasy is realistic even though the ERP is hosted. Keep the chat service, the retrieval index and the model on your own server or private cloud, and let only the service call the MRPeasy API. Staff conversations, prompts and any cached order data stay within your network. An open-weight model of moderate size is enough for lookups and phrasing when the tools do the real work. For a public customer widget, put the chat service in a DMZ or private cloud region, with the model behind it, and keep the verified customer scope enforced in code. Air-gapped sites can run on a nightly synchronised copy of MRPeasy data, with the limitation that answers are as fresh as the last sync.
Security checklist
- Enforce customer and role scoping in code on every query, never in the prompt.
- Use verified identity for customers, such as email verification or signed links.
- Keep the API key server-side and out of the browser entirely.
- Rate limit and bot-protect the public widget to prevent scraping of order numbers.
- Log conversations with a retention policy and mask personal data in analytics.
Ways to get it done
No-code chatbot platform with a webhook to your lookup service
Effort: Days
Quick staff pilots and simple FAQ flows.
Build in-house with an LLM, retrieval and the REST API
Effort: 3-6 weeks
Teams with a developer who will own the service and review transcripts.
Partner build with Netray
Effort: Typically a few weeks for a scoped pilot
When you need a private model, customer-scoped access and a measured accuracy process.
Pitfalls
- !Letting the model answer from memory when a lookup fails. Return a clear could not find that message instead.
- !Showing customers internal statuses that confuse them. Map internal states to plain language.
- !Exposing order lookup by number alone, which invites guessing. Require a second factor.
- !Ignoring handoff. Always offer a person for anything the bot cannot resolve.
- !Launching to customers before staff have used it for a month.
Frequently asked questions
Does MRPeasy have a built-in chatbot?
Not that we can confirm. Check the current feature list and the vendor's own AI announcements, as these change. If a native assistant covers your needs, use it. A custom bot is justified when you need your own data sources, branding or private hosting.
Can customers use the bot safely?
Yes, if scoping is enforced in your service. Verify the customer's identity, filter every query by their customer ID, expose only chosen fields, and rate limit. Do not rely on instructions to the model to protect other customers' data.
What model do we need?
For tool-based lookups a small to mid-size model is often enough, since the API returns the facts. Larger models help with messy questions and long documents. Test candidates on a set of your real questions before committing.
How accurate will it be?
Lookup answers can be very accurate because they quote the system. Errors come from ambiguous questions and bad master data. Measure on real transcripts and track wrong or unanswered rates instead of trusting a demo.
Can it also take orders?
It can capture order requests into a draft or an email for review, but we recommend a human confirming before anything is committed in MRPeasy, especially for pricing and delivery promises.
Want AI chatbot working on your MRPeasy?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment