Most AI connected to an ERP is either a demo or a liability. This one works from a fixed, published list of lookups, verifies the customer before anything account specific is released, and can raise only three kinds of document. Every request is checked against two levels of permission at the moment it runs, and recorded either way.
What your customers can find out
Ten lookups, written in advance and published here in full. If a question is not on this list, the agent cannot ask it.
Stock availability
On-hand and available quantity, optionally by warehouse, resolved with B1's own committed and on-order logic.
Order status
The status and detail of a sales order, plus every outstanding order for that customer.
Delivery estimate
Estimated delivery date and current status, so nobody has to promise a date they cannot see.
Service call status
Where an open service call or support request has actually got to.
And what waits until they prove who they are
Anything touching money, pricing or an account balance is released only after the customer verifies their identity. That requirement cannot be switched off, by you or by us.
Account and credit
Account summary, balance and credit detail for the customer on the line.
Their price, not list price
Customer-specific pricing, drawn from their price list and special prices rather than the number everybody else sees.
Invoices
Invoice detail, and a list of anything unpaid or partially paid.
Three things it can create, for a verified customer
Each one is confirmed with the customer before it is raised, and each one can be reversed by a person afterwards.
Quotation
Raise a sales quotation from the conversation. Cancelled the same way any other quotation is.
Sales order
Place the order they just confirmed, with the total and delivery detail read back first.
Credit request
Log a credit or return against the right document, with the reference given back before the conversation ends.
Why your IT team will sign this off
Most of the following is not a policy we apply. It is a thing the system cannot do.
Nothing opens at your site
A small Windows service inside your network makes one outgoing encrypted connection. No inbound firewall rule is opened on your side.
Credentials never leave
The SAP database password is entered and encrypted on your own machine. It does not reach the cloud, and we never handle it.
It never invents a query
Every lookup is pre-written with parameters filled in. The whole class of problem where an agent improvises a damaging query does not exist here.
Revoked in a second
Revoke the connector certificate and the live connection closes within a second. Permissions are re-checked on every request, not just at setup.
Payments, credit memos against the ledger, master data changes and deletions are deliberately out of reach. Raising a quotation is recoverable and posting money is not, so the two are not treated as the same kind of permission.
Getting connected
Company and database
We create the company record and point it at the Business One database it will read.
Connect the on-premise machine
One command with a single-use pairing code. The certificate is generated on your machine and the database password is entered there, both by design.
Set the tool policy
Which of the lookups this company may use at all, before any agent is granted a subset of them.
Handover to your administrator
Your admin takes ownership and decides which agent gets which capabilities.
What your IT team will ask
The questions that come up in every security review, answered here rather than in a follow-up call.
- What actually gets installed inside our network?
- One small Windows service, built on .NET 8, on a machine that can reach the Business One database. It does not have to be the SAP server itself. Nothing is installed on a domain controller or on user workstations, and your SAP installation is not modified.
- Does this require opening a port or an inbound firewall rule?
- No. The on-premise service makes one outgoing TLS connection to our platform and keeps it open, authenticated with mutual TLS. Requests travel down that existing connection, so no inbound rule, port forward or public endpoint is created on your side.
- Where does the SAP database password live?
- It is entered on your machine by your administrator and encrypted there. It is not transmitted to our platform, not stored in our database, and not visible to our staff, including support. The client certificate is generated on your machine during pairing and its private key never leaves it.
- Can the agent write its own database queries?
- No. Every read is a parameterised query written in advance and published. The agent selects one and supplies parameters; it cannot compose or submit a statement of its own. If a customer asks something no published lookup covers, there is no path by which the agent can improvise one.
- What can it never do, regardless of configuration?
- It cannot post payments, raise credit memos against the ledger, alter master data, or delete anything. These operations are absent from the tool set rather than withheld by policy, so no configuration, permission level or instruction to an agent reaches them.
- How quickly can we cut off access?
- Revoke the connector certificate and the live connection closes within about a second. No coordination with us is required, and no request in flight completes afterwards. Permissions are also re-checked on every request rather than cached from setup.
- What is recorded, and can we see it?
- Every request, approved or refused, with the operation, the parameters, the outcome, the duration, the agent that made it and the permission decision behind it. Refusals are recorded with the reason, so an attempt to reach something out of scope is visible to you rather than silent. The record is queryable and exportable.