How to add an AI chatbot to ECI E2 Shop System
Short answer
An AI chatbot for E2 Shop System answers questions about jobs, orders, inventory and procedures by retrieving from curated read-only views of the E2 database and your documents. It can serve office staff, the shop floor or customers, and can run entirely on-prem on an open-weight model.
In a job shop, the same questions interrupt the office all day. Where is my order? Do we have this material? What did we charge last time for this part? What is our procedure for first article? A chatbot grounded in E2 and your documents takes most of that load without anyone opening three screens.
The difference between a useful chatbot and a risky one is grounding. It should answer only from records it retrieved, show where the answer came from, and say it does not know otherwise. It should also respect who is asking, because a customer should not see cost and a floor operator should not see quotes.
E2 has no built-in chat interface for this, so you add one beside it: a small web page or a Teams or messaging front end that talks to a service you control.
What teams use it for
Customer order status portal chat
Customers ask about their own orders and shipments. The bot returns status and ship dates from E2 views filtered to that customer only.
Internal sales and CSR assistant
Staff ask about inventory, lead times and last price for a part and get an answer with the source record.
Shop floor procedures helper
Operators ask for inspection steps, setup notes or safety procedures from approved documents, on a kiosk tablet.
Estimator history assistant
Ask for similar parts quoted in the last two years with actual hours and material to ground a new quote.
New hire onboarding
New office staff ask how to do common tasks in E2, answered from your own written procedures rather than generic guesses.
ECI E2 Shop System integration surface
- SQL Server: curated read-only views for jobs, orders, shipments, inventory and part history, filtered by customer or role in the service layer.
- Document sources: SOPs, work instructions, certs and quote PDFs on file shares, indexed for retrieval with access tags.
- Customer identity: E2 customer contacts are not an authentication system, so use a separate login for portal users mapped to a customer ID.
- Front ends: a simple web page, an embedded widget on your site, Teams or a messaging channel, all calling the same chat service.
- Export fallback: scheduled exports can feed a bot where live database access is not allowed, with the staleness stated in answers.
How it works
- 1
Define audiences
Separate staff, floor and customer bots, or one bot with strict roles. Decide what each may see before building anything.
- 2
Build the data views
Create views that already apply filters, for example orders for a given customer ID, so the bot cannot widen scope by mistake.
- 3
Set up retrieval for documents
Chunk and index SOPs and quotes with metadata for audience and revision; retire superseded revisions.
- 4
Create the chat service
Orchestrate: classify the question, call the data tools or retrieve documents, and generate an answer that cites sources.
- 5
Add guardrails
Refuse out-of-scope questions, never reveal cost to unauthorised roles, and hand off to a person when confidence is low.
- 6
Pilot and measure
Track resolved questions, handoffs and wrong answers for a few weeks with a small group before widening.
Example flows
Customer asks where their order is
Trigger: Customer types a PO number into the portal chat.
- Service authenticates the user and finds their customer ID.
- It queries the order view filtered to that ID and PO number.
- It reads status, last completed operation and ship date.
- It replies and offers a link to the packing document if available.
Result: Status calls to the office drop, and customers get answers outside business hours.
Operator looks up a procedure
Trigger: Operator at a kiosk asks about the first article inspection for a part.
- Bot identifies the part and active revision.
- It retrieves the approved inspection instruction.
- It displays the steps and the document revision.
Result: The operator uses current documentation instead of a printed, possibly outdated, copy.
Keeping data on-prem
A chatbot over E2 can run entirely inside your network. Serve an open-weight model on a local GPU with vLLM or Ollama, keep the vector index and chat logs on your own server, and place the service behind your existing authentication. A customer-facing bot is the one case that needs an externally reachable component: put only the thin web front end in a DMZ, have it call the internal service through a tightly restricted rule, and never expose SQL Server. Smaller models handle lookups and procedure questions well; reserve larger ones for long-document comparison.
Security checklist
- Row-level scoping in views so customers can only reach their own records.
- Cost, margin and pricing hidden from customer and floor roles by design, not by prompt.
- Chat logs retained on your infrastructure with a defined retention period.
- Rate limits and bot-abuse protections on any public endpoint.
- Prompt-injection hygiene: treat retrieved text as data and keep write tools out of the bot.
Ways to get it done
Generic website chatbot with uploaded FAQs
Effort: Days; no E2 connection.
Enough for static questions like hours, capabilities and certifications; no live order data.
Build in-house over SQL views and a document index
Effort: Several weeks for a staff bot; longer for a customer bot.
Teams with development capacity who want full control.
Netray private chatbot
Effort: Scoped pilot, then extend audiences.
Shops wanting on-prem models, role-aware answers and an E2 schema map delivered together.
Pitfalls
- !Launching to customers before role scoping is tested with deliberate attempts to see other accounts.
- !Indexing superseded procedure revisions so the bot cites old instructions.
- !No handoff path, leaving users stuck when the bot is unsure.
- !Relying on the prompt, not the data layer, to hide cost fields.
- !Underestimating how much cleanup your documents need before retrieval is useful.
Frequently asked questions
Can a chatbot read live E2 data?
Yes, through a read-only service over curated SQL Server views. If live access is not permitted, scheduled exports can feed it, but answers will be only as fresh as the last export.
Is it safe to let customers use it?
It can be, if records are filtered by customer in the data layer, the front end is isolated from your database, and you test for cross-account leakage. Start with staff use before going external.
Does it need the cloud?
No. With a local open-weight model and a local index it can run fully inside your network. Cloud models are optional and should be used only where policy allows.
How accurate will it be?
Lookups from structured views are usually reliable because the facts come from tools, not memory. Free-text document answers depend on document quality, so test with your real questions and measure.
Can it create orders or change jobs?
It should not at first. Keep it read-only and let it prepare requests for staff to review. Direct writes need strict controls and approval.
More for ECI E2 Shop System
Want AI chatbot working on your ECI E2 Shop System?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment