How to add an AI chatbot to ECI JobBOSS2
Short answer
An AI chatbot for JobBOSS2 answers questions from job, delivery, inventory and PO data using retrieval over read-only views plus a document index for procedures. It can sit in a web page, Teams or a customer portal, and can run on your own server with an open model.
In a job shop, the same questions repeat all day. Where is my order? When does the material arrive? What is the standard lead time for this process? Who has the latest drawing revision? Each question interrupts someone who is also trying to quote or schedule.
A chatbot that is grounded in the actual JobBOSS2 data can take a good share of these, but only if it answers from the database and your documents, not from general knowledge. A bot that guesses a ship date is worse than none.
There are two audiences with different risk profiles: internal staff, who can see most things, and customers, who must see only their own orders. Design them as separate bots.
What teams use it for
Customer order status portal
Customers authenticate and ask where their jobs are. The bot returns status, next operation and promised date for their orders only.
Internal order desk assistant
Staff query jobs, deliveries and inventory in plain language without opening multiple screens.
Procedure and quality manual Q&A
A retrieval index over work instructions, inspection procedures and certification notes, with citations to the source document.
New hire onboarding
Ask how to process a customer return or what the steps are to close a job, answered from your own written procedures.
After-hours quote intake
The bot collects part, material, quantity and due date from a prospect and creates a structured request for the estimator.
ECI JobBOSS2 integration surface
- SQL Server read views over job status, operations, deliveries and purchasing data. Table names such as Job, Job_Operation and Delivery are typical but verify for your version.
- JobBOSS2 customer and contact tables can drive customer identity matching, though portal login should use a proper identity provider.
- Attachments and documents often live on file shares referenced from jobs. A separate document index handles those.
- If your edition has an API, it can serve status lookups for cloud-hosted setups where direct SQL is not available.
- Application-level roles are not exposed in the database, so the bot layer needs its own mapping of users to customers and sites.
How it works
- 1
Decide internal or customer-facing first
Internal is simpler and lower risk. Customer-facing needs identity, tenancy filtering and a tight scope.
- 2
Define intents the bot supports
Order status, delivery date, material status, document lookup. Anything else should get a polite handoff to a person.
- 3
Build grounded lookups
Structured questions use parameterised queries over views. Document questions use retrieval over an index with source links.
- 4
Constrain the answer
The model must answer from the returned data and say it does not know otherwise. Dates and quantities are quoted from rows, not paraphrased loosely.
- 5
Add identity and tenancy
Customer bots filter by the logged-in customer in the query itself. Staff bots use directory groups to decide visible fields.
- 6
Offer a human handoff
A button or message routes to email or a Teams channel with the conversation attached.
- 7
Review transcripts weekly
Look at unanswered and thumbs-down questions, then add intents or fix data views.
Example flows
Customer asks about a late order
Trigger: A buyer at a customer logs into the portal chat.
- Bot identifies the customer from the login.
- It looks up open jobs for that customer and finds the one named.
- It returns the current operation and the promised ship date.
- If the date moved, it shows the revised date and offers to message the account manager.
Result: The customer gets an answer immediately and the shop avoids a phone call.
Operator asks about a procedure
Trigger: A machinist types a question on a shop floor kiosk.
- Bot searches the work instruction index.
- It returns the relevant steps with a link to the controlled document.
- It notes the document revision and date.
Result: A fast answer from the current controlled document, not memory.
Keeping data on-prem
A chatbot can run entirely inside your network. Host an open-weight model (Qwen, Llama, Mistral, Gemma or gpt-oss class) with vLLM or Ollama on a GPU machine, keep the retrieval index and vector store on a local server, and read JobBOSS2 data through the same read-only views. For a customer-facing bot, only the thin web front end and an authenticated API sit in a DMZ; the model and the database stay inside. Smaller models are enough for status lookups and procedure Q&A, which keeps hardware modest.
Security checklist
- Enforce customer and site filtering in the SQL query, never in the prompt.
- Keep the customer bot restricted to a short list of intents and block free-form data exploration.
- Strip internal fields such as cost, margin and internal notes before they reach the model for customer bots.
- Rate-limit and log all conversations, with retention that matches your policy.
- Treat uploaded files and pasted text as untrusted input to the model.
Ways to get it done
Generic chatbot platform plus export feed
Effort: 1 to 2 weeks
Works for FAQ-style bots. Weak for live order status because exports lag.
Build in-house
Effort: 4 to 8 weeks
Feasible with a developer and a clear scope. Identity and evaluation take the most time.
Partner such as Netray
Effort: A few weeks for an internal pilot
When you want on-prem hosting with open models, grounded lookups and an evaluation set.
Pitfalls
- !Letting the bot answer ship dates from stale cached data.
- !No tenancy filter in the query, risking one customer seeing another's orders.
- !Over-broad scope that tempts the bot to guess at pricing or commitments.
- !Ignoring document versions, so the bot cites an obsolete procedure.
- !Launching to customers before testing with internal staff for a month.
Frequently asked questions
Can the chatbot give customers live order status from JobBOSS2?
Yes, if you expose a read-only status view or API call filtered to the authenticated customer. Avoid nightly exports for this, as customers expect current dates. Keep the returned fields minimal and exclude cost data.
Will it make up ship dates?
It can if it is not constrained. Design it to quote dates directly from returned rows and to decline when no data is found. Test with edge cases such as jobs on hold or split deliveries.
Can this run without internet access?
Yes. With a local open-weight model, a local index and read access to SQL Server, nothing needs to leave your network. A customer portal needs an internet-facing front end, but the data and model can remain internal.
Is ECI's own tooling enough?
If a customer portal or assistant from ECI covers your needs, use it. Custom builds make sense when you need on-prem hosting, your own documents in the same chat, or behaviour tuned to your processes.
How do we measure whether it works?
Track the share of questions answered without handoff, correctness on a sampled set checked against JobBOSS2, and reduction in status calls. Review transcripts weekly in the first months.
Want AI chatbot working on your ECI JobBOSS2?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment