How to add an AI chatbot to Fishbowl
Short answer
Build a chat assistant that sits beside Fishbowl, answers from live inventory, order and part data through read-only tools, and respects who is asking. Staff use it for lookups and procedures; customers get a narrower version limited to their own orders. It can run entirely on your own hardware.
Fishbowl users spend a surprising amount of time answering the same questions for each other: is it in stock, where is it, when does the next PO land, did that order ship. The answers sit in Fishbowl but need a trained person to find them. A chatbot turns those lookups into a sentence.
The risk with chatbots is confident wrong answers. The fix is architecture: the bot never guesses stock levels, it calls a tool that reads them, and it shows which record the number came from. Anything it cannot look up, it says so.
There is also a second audience. Customers and reps who want order status without calling the office can use a restricted version of the same assistant, behind your portal or website login.
What teams use it for
Warehouse lookups
A picker asks where a part is stocked and the bot returns locations and quantities, including whether the stock is allocated.
Sales rep stock check
On the road, a rep asks how many units are available and when the next receipt is due, without Fishbowl client access.
Customer order status portal
A customer enters an order number and email and gets status, tracking and expected ship date from their own orders only.
Procedure helper
New staff ask how to receive against a PO with a partial shipment, answered from your written procedures and not from memory.
Buyer questions
A buyer asks which vendor was cheapest for a part last time and the bot cites the PO and date.
After-hours quote questions
The bot checks availability and lead time so a rep can reply to a late inquiry with real information.
Fishbowl integration surface
- Fishbowl REST API: token-based reads for parts, inventory, POs and SOs via an approved integrated app. Coverage and fields vary by version.
- MySQL read replica: powers fast, combined queries such as stock by location with open allocations.
- Legacy JSON API: an alternative for older servers behind the same bot tools.
- Tracking and carrier data: shipment records and carrier tracking numbers stored on shipments can feed customer status answers.
- Document store: SOPs, vendor manuals and part attachments you index for retrieval-augmented answers.
How it works
- 1
Decide the audience and channels
Internal staff in a web chat or Teams is simplest. A customer-facing bot needs identity checks and a tighter scope.
- 2
Build the tool layer
Create read-only functions: find_part, availability, open_po_lines, order_status. Each returns small JSON with record identifiers.
- 3
Add document retrieval
Index SOPs and manuals into a vector store. The bot cites the document and section it used.
- 4
Pick the model
An open-weight model with tool-calling served by vLLM or Ollama is enough for lookups. Use a larger model only if tests show it is needed.
- 5
Enforce identity and roles
Staff sign in with your directory. Customers authenticate through your portal, and tools filter by customer ID in code.
- 6
Design refusals and handoffs
If a tool returns nothing or the question is out of scope, the bot says so and offers to notify a person.
- 7
Review transcripts
Sample conversations weekly, track wrong or missed answers, and fix tools or instructions.
Example flows
Counter staff stock check
Trigger: Someone asks for a part at the counter.
- Staff member types the part or description.
- The bot calls find_part then availability.
- It replies with available quantity, bin and next PO date.
- It includes the part number so staff can confirm.
Result: A grounded answer in seconds without opening Fishbowl.
Customer order status
Trigger: A customer visits the order status page.
- They sign in to the portal.
- The bot calls order_status for orders tied to their account only.
- It shows status, ship date and tracking link.
- It offers to message the account manager if the date slips.
Result: Fewer status calls to the office.
Keeping data on-prem
Because Fishbowl runs on your server, the chatbot can run entirely inside your network: a small service, a vector store for documents, and an open-weight model on a local GPU machine, all reachable only on the LAN or VPN. Customer-facing use is harder because the portal must reach the bot, so place only a thin front end in a DMZ and keep the model and Fishbowl access internal. Do not open Fishbowl itself to the internet for the bot.
Security checklist
- Filter data by user or customer ID inside tools; never rely on the model to hide records.
- Use read-only credentials and strip unit cost for roles that should not see it.
- Rate-limit and authenticate customer-facing endpoints.
- Do not log full conversations containing customer data longer than needed; set retention.
- Make the bot state when it cannot find data rather than estimating.
Ways to get it done
Generic chatbot platform with manual FAQ
Effort: Days.
Static questions, no live stock data needed.
Build in-house on the REST API and a hosted model
Effort: Several weeks with evaluation.
Developer-capable teams with internal-only use.
Partner build with Netray, on-prem model
Effort: Scoped pilot, then extension to portals.
Live data, customer access, and strict data residency.
Pitfalls
- !Letting the bot answer stock questions from a stale cached export.
- !Mixing up available and on-hand quantities, which leads to promised stock that is allocated.
- !Customer-facing bots that can access other customers' orders because filtering was left to the prompt.
- !No fallback path, leaving customers stuck when the bot cannot answer.
- !Skipping transcript reviews, so wrong answers persist unnoticed.
Frequently asked questions
Can the chatbot show real-time stock from Fishbowl?
Yes, if it calls Fishbowl through the API or a database read each time and does not rely on cached exports. Show the timestamp of the data in answers so users know how fresh it is.
Can customers use it safely?
Yes with care. Put it behind portal authentication, filter every query by the customer's ID in code, limit it to order and shipment status, and log access. Do not expose cost, other customers or internal notes.
Does it need the cloud?
No. Lookup and summarization tasks run well on open-weight models hosted locally. Cloud models may be fine for non-sensitive use, but a local model keeps inventory and customer data inside your network.
How is this different from the Fishbowl client search?
The client search needs a licensed user who knows the screens. A chatbot answers in plain language, can combine stock, POs and orders in one reply, and can serve people who do not have client access. For power users, the client remains faster.
How long does a first version take?
A staff-only lookup bot with four or five tools can be piloted in a few weeks, including testing against real questions. A customer-facing version takes longer because of identity, privacy review and portal integration.
Want AI chatbot working on your Fishbowl?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment