How to add an AI chatbot to Sage 100
Short answer
Add an AI chatbot to Sage 100 by grounding it in your own data: read-only queries over ODBC or SQL Server plus an index of your documents, wrapped in role-based tools. It can run in a web page, a portal or Teams, and with open-weight models it can run entirely on your own server.
A chatbot for Sage 100 usually has two audiences. Internally, it answers the questions that interrupt your best people: what is the status of this order, do we have this in stock, what were the terms on that vendor. Externally, it handles the repetitive customer questions that otherwise land in customer service.
Sage 100 has strong transactional screens but a dated interface for casual questions. Many staff avoid it and ask a colleague instead. A chatbot that answers from the same data, with the same permissions, removes that friction without asking anyone to learn the screens.
The test of a good one is not fluency, it is that every number comes from a query and every policy answer comes from a document you provided. Anything it cannot ground, it should decline to answer.
What teams use it for
Internal order status desk
Customer service asks the bot for an order's ship status, tracking number and open backorders instead of drilling through Sales Order Inquiry.
Customer self-service portal bot
Customers ask about their own orders, invoices and statements; the bot is locked to their customer code.
Pricing and availability for sales reps
Reps ask for a customer price and available quantity while on a call, with price visibility controlled by role.
Purchasing assistant
Buyers ask which POs are open for a vendor or what the last cost for an item was.
Policy and procedure questions
Staff ask about return policies, credit procedures or receiving steps, answered from your uploaded documents with citations.
New hire help for Sage itself
A bot explains how to do common tasks, such as entering a return or running a statement, using your own procedure documents.
Sage 100 integration surface
- Sage 100 ODBC driver and, in Premium, SQL Server: the read path for live status, inventory and aging questions.
- Business Object Interface: needed only if the bot may create things like a return request or a quote; keep this as a drafted proposal.
- Documents: Paperless Office archives, shared drive PDFs and policy documents can be indexed for retrieval, separate from transactional data.
- Sage 100 security roles: use them as the model for chatbot roles, so a customer service rep and a warehouse clerk see different answers.
- Customer portal or eBusiness style web front ends and Teams or a web widget as chat surfaces; what is available depends on your version and add-ons.
How it works
- 1
Define the audience and scope
Pick one: internal staff or customers. Write the 20 most common questions and mark which need live data and which need documents.
- 2
Build the data tools
Create parameterized tools for order status, item availability, invoice lookup and aging, returning only permitted fields.
- 3
Index documents
Chunk policy PDFs and procedures, store embeddings in a local vector store, and attach document titles for citation.
- 4
Add identity and roles
Authenticate users through your directory or portal login and pass role and customer scope to every tool call.
- 5
Set answer rules
Instruct the bot to answer only from tool results or retrieved text, show the source, and say when it does not know.
- 6
Add handoff
When confidence is low or the user asks for a person, create a ticket or email with the conversation attached.
- 7
Review transcripts weekly
Read a sample, fix wrong tool choices, and add missing documents.
Example flows
Where is my order
Trigger: A customer types an order number into the portal chat.
- The bot verifies the order belongs to the logged-in customer code.
- It queries order header and shipment lines, read-only.
- It replies with status, ship date and carrier tracking if present.
- If lines are backordered, it offers to notify customer service.
Result: A routine call or email is answered in seconds, without exposing other customers' data.
Rep price check
Trigger: A sales rep asks for the price and availability of an item for a named customer.
- Bot calls a pricing tool that applies the customer's price level or contract.
- It calls an availability tool for on-hand and due-in.
- It answers with both, flagging if quantities are tight.
- Cost is withheld unless the role permits it.
Result: Faster quoting with consistent pricing.
Keeping data on-prem
A Sage 100 chatbot can be fully private. Run an open-weight chat model with vLLM or Ollama on a GPU server inside your network, a local vector store for documents, and the tool service next to Sage 100. The chat front end lives on your intranet or your existing customer portal, with TLS and authentication. A mid-size model is generally capable for status lookups and document question answering. Nothing about customers, prices or policies is sent to a third party, which also simplifies answers to customer security questionnaires.
Security checklist
- Enforce customer and role scoping in the tool layer, never only in the prompt.
- Authenticate every session; anonymous bots should not answer account-specific questions.
- Hide cost and margin fields unless the user's role explicitly allows them.
- Log conversations and tool calls, and set retention and access rules for those logs.
- Add prompt-injection defenses: treat document text and user text as untrusted, and keep tools narrow.
Ways to get it done
Vendor add-on or Sage assistant features
Effort: Low.
Reasonable for generic help if your version and subscription include it.
Build with an open-source chat framework
Effort: Four to eight weeks for a polished version.
Good if you have a developer and want control over data and cost.
Partner build with Netray
Effort: A scoped pilot, then widen scope.
Good when you need a private model, role-aware tools and a portal embed.
Pitfalls
- !Putting customer data in the chatbot before role scoping works; test with adversarial questions first.
- !Indexing outdated procedures, so the bot confidently quotes retired policy.
- !Letting the bot answer pricing without applying customer price levels.
- !No handoff path, which frustrates customers when the bot reaches its limits.
- !Underestimating ODBC load when many chat sessions run queries at once; cache common lookups.
Frequently asked questions
Can the chatbot run entirely on our own server?
Yes. Using an open-weight model served with Ollama or vLLM, a local vector store and a tool service next to Sage 100, all components can run inside your network. You will need a GPU server sized to your concurrent users, and the answers are only as good as your data.
Will it show customers only their own data?
It can, if scoping is enforced in the tool layer using the authenticated customer identity. Do not rely on instructions in the prompt alone. Test with attempts to ask about other customers' orders before going live.
Can it create orders or returns?
It can prepare them, ideally as drafts that staff review before posting through the Business Object Interface. Fully unattended order entry is risky because a misread quantity or item becomes a real transaction.
How is this different from Sage's own assistant?
Vendor assistants are convenient but limited to what the vendor builds and hosts, and availability depends on product and version. A custom chatbot lets you choose the data, roles, documents and hosting, at the price of building and maintaining it.
How do we keep it accurate?
Ground every answer in a tool result or a cited document, review transcripts weekly, and keep documents current. Where the bot has no source, it should say so and hand off to a person.
Want AI chatbot working on your Sage 100?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment