AI Agents for Distributors: Answer Stock and Delivery Queries Safely

Give the agent read-only access to a timestamped stock export and an approved price list, and require it to cite the exact SKU and source time in each answer. It may answer routine trade enquiries within defined limits. Route uncertain quantities, customer-specific prices and delivery promises to the sales desk, then test at least 30 real enquiries before release.

“In stock” is an operational claim, not merely a database value. Ten units on hand may include eight already allocated to orders, two damaged units or a carton that cannot be split. Likewise, a delivery date depends on pick capacity, carrier cut-offs and the customer's account terms. An agent should expose which of those facts it actually knows and refuse to fill the rest with fluent guesses.

Follow me on Instagram@sagnikteaches

Define the answer the agent is allowed to give

Start with a written scope for three question types: product availability, approved price and delivery status. Split each into facts the system can confirm and facts that need a human. For availability, decide whether the answer is a precise available-to-promise quantity, a broad “available for enquiry” label or only an invitation to request a quote. Available-to-promise means on-hand stock less allocations, holds and other commitments, under your own inventory rules. If the export contains only on-hand stock, do not call it available-to-promise.

Connect on LinkedInSagnik Bhattacharya

For price, decide whether the agent can display a public catalogue price or authenticated contract pricing. A price list needs a version, effective date, unit of measure, currency and any minimum quantity rule. If a customer's agreement has an exception, a generic list price can mislead them. The safest first pilot often uses public prices or avoids numeric prices entirely, then routes contract enquiries to a named person. If you later add private pricing, test identity and access separately from answer quality.

Subscribe on YouTube@sagnikteaches

For delivery, distinguish order status from a prediction. “Your order was despatched yesterday, according to the order system” is supported by a recorded event. “It will arrive tomorrow” requires current carrier information and a rule for uncertainty. Never let the model turn a target service level into a guarantee. The same distinction applies to a buyer asking whether twelve units can be supplied by Friday: that is a commitment, not a stock lookup. Hand it to the sales desk unless a human-approved fulfilment rule covers it.

A read-only design matters. The first agent should not amend stock, reserve items, change prices, accept orders or trigger carrier bookings. Give it a narrow retrieval interface or a controlled export. Log the source record used for each answer. If the data connection fails, the reply should say that availability cannot be confirmed and offer a human route. A graceful failure is a correct outcome. For wider agent risks and action controls, see what can go wrong when agents act.

Prepare a stock file that represents trade reality

Export a small set of fields the agent needs: SKU, approved product name, unit of measure, active status, on-hand quantity, allocated quantity if reliable, sellable quantity, warehouse or fulfilment node if relevant, last updated time, and an availability rule. Keep obsolete SKUs out or mark them clearly. The file should also say whether a substitute is approved, merely compatible for certain uses or unverified. A model may match similar product names, but only the approved catalogue should authorise a cross-reference.

Choose a refresh interval from actual stock movement. A distributor with frequent pick activity may need updates throughout the day; a slower catalogue may tolerate a daily export. That is an operational decision to test, not a universal setting. Add a “stale after” rule. For example, if the pilot export is more than two hours old, the agent can still describe the product but must say “live availability needs confirmation”. If the business cannot reliably timestamp the export, do not publish a numeric stock answer.

Allocations are where a naive answer goes wrong first. In an illustrative enquiry, a buyer asks for “twenty 20 mm couplers”. The file shows SKU C20, 28 on hand, 12 allocated and four quarantined after a quality check. Sellable unallocated stock is 12. A naive agent says 28 available. A correct response states that 12 are shown as currently available in the latest approved export and asks the desk to confirm the remaining eight or an alternative. It never suggests releasing quarantined units to meet the order.

Pack sizes cause the next error. Suppose a catalogue contains “Box of 100 fixings” and “Single fixing” with nearly identical names. A buyer asks for 50 units. The agent retrieves the box record and quotes five boxes because it divides by ten from a stale note. The test should fail on unit of measure before price is considered. A reply must name the SKU, pack size and quantity basis. If the buyer's words leave the pack unclear, the agent asks whether they mean singles or boxes.

Keep a data owner. Someone in inventory operations should certify the fields and investigate source errors. An AI vendor cannot infer physical stock from a stale export. Record the time the file was generated, the time the agent indexed it and the time the answer was sent. Those three times can differ. When a query exposes an incorrect record, fix the source system and rerun the export; adding a special instruction to the chatbot may hide the issue for only one wording.

Before connecting the data, sample ten SKUs that regularly cause questions. Compare their export rows with what a desk colleague sees in the inventory system and with the last physical count or adjustment. The aim is not to audit the whole warehouse in one afternoon; it is to establish whether the fields mean what the proposed answer says they mean. If the “available” field includes stock in another warehouse that cannot serve the buyer's address, either add the correct fulfilment rule or remove the numeric answer. Record the decision in a small data dictionary.

Another illustrative case is a product with 40 units in the main depot and 20 in a satellite depot. The buyer requests 50 for one delivery. The export's total of 60 looks sufficient, but the two depots have different cut-off times and one cannot deliver to the customer. The agent must use a node-specific availability figure or escalate. A sum across locations is useful for planning; it is not proof that a single order can ship on the requested terms. Include a multi-depot case in the 30-query test if the distributor has more than one stock location.

Use a price source with identity boundaries

Set a separate approved price file with SKU, price, unit, currency, effective dates and audience. If an item is quotation-only, mark it that way. For customer contracts, map an authenticated account ID to its approved schedule and prevent retrieval of any other schedule. Test access with two accounts that have different rates for the same SKU. A model should not decide entitlement from a customer's name typed into chat. It needs verified session information supplied by your own system. Microsoft's documentation on retrieval-augmented generation in its Foundry platform makes the same point in general terms: apply access control at retrieval time, because a grounded answer can leak whatever the index can reach.

Consider an illustrative distributor with catalogue price $42 per carton and a negotiated $38 for one trade account. The buyer writes, “We normally pay 38; can you confirm?” An unauthenticated agent should not agree merely because the buyer supplied a number. It can state the public catalogue price or route the enquiry for account verification. After authenticated access, it may show $38 only if the current approved schedule includes that SKU and quantity. A screenshot of an old quote is evidence to investigate, not authority to change the list.

Superseded files cause a quieter price error. In this illustration, a customer asks whether 30 cartons qualify for a bulk discount. The approved list has a $40 rate for 25 or more, but an old PDF in the knowledge base says $39 for 20 or more. If both are indexed, a model may choose the older cheaper figure. Give current price rows precedence, remove superseded files from retrieval and make the effective date visible. The test answer should calculate 30 times $40 equals $1,200 before any other charges, while saying that final quotation terms remain subject to desk confirmation if applicable.

Never ask the model to negotiate autonomously in the pilot. If a trade buyer challenges price, the agent can collect the SKU, requested quantity and account reference, then open a sales-desk task. It should not invent a discount to keep the conversation moving. Track these escalations; they may reveal a price-list maintenance problem or a recurring competitive objection. For a different distributor workflow, order entry buy-or-build choices address the separate decision about converting enquiries into orders.

Write the handover rule before writing the greeting

The agent needs a compact decision tree. If the product is found, the source is fresh, the unit is unambiguous and the requested quantity is below the approved threshold, answer with the SKU, quantity basis and source time. If any condition fails, gather the minimum context and hand over. For an order already placed, use the order system's status only when the customer is authenticated and the status is fresh. If the carrier's tracking information is unavailable, do not extrapolate from the despatch date.

Make handover useful. The sales desk should receive the customer's message, SKU candidates, quantity, account ID if authenticated, source timestamp and the reason the agent stopped. Avoid forwarding a speculative answer as if it were fact. Give the customer a case reference and a realistic response window defined by the business. The desk should be able to correct the knowledge source and mark whether the agent's refusal was justified. A high escalation rate may indicate poor data, not a poor model.

Write the message the agent sends to the desk as a filled-in record, not a vague summary. For example: “Case 214; account verified; request 18 cartons of A17 for Monday; latest export 10:05 shows 14 available-to-promise; no delivery commitment given; please check incoming stock and carrier cut-off.” A desk colleague can act on that without reopening the whole chat. The customer-facing reply can be shorter: “I can confirm the item, but I cannot confirm all 18 cartons and the deadline from the current records. I have sent the request for a checked answer.” This pairing is a useful acceptance test.

Set an ownership rule for unanswered handovers. If the desk closes a case, it should record the actual answer and whether the source or agent rule needs repair. If the answer reveals a stock discrepancy, inventory operations owns the correction. If it reveals a contract price exception, the pricing owner updates the approved list. Without this feedback loop, the agent keeps escalating the same question and the desk's workload merely changes shape. Measure time from handover to checked answer, not only the proportion of chats the agent handled alone.

Deadline questions need the same restraint. Take an illustrative message from a customer: “Can I have 80 of SKU A17 delivered before opening on Monday?” The file shows 95 on hand but no allocation field and no live carrier cut-off. The agent can confirm the product identity and say the request has gone to the desk for stock allocation and delivery confirmation. It must not say “yes, 95 are in stock” as though that resolves the deadline. The desk might find only 60 unallocated or a route that cannot meet the time.

Order statuses carry their own trap. Suppose an order page says “label created” but the carrier has not scanned the parcel. An agent that replies “despatched” may create a false delivery expectation. The safer wording is “a label has been created; carrier collection is not yet confirmed in the available status”. That distinction is small in text and large in customer impact. Include this exact case in testing if the order system exposes intermediate states.

Test 30 genuine enquiries, including awkward ones

Collect 30 anonymised trade enquiries from a recent period; Microsoft's RAG design guide likewise starts by gathering representative test queries before tuning anything. Keep the original wording, including abbreviations, misspellings and vague quantities. Assign an experienced desk member to write the expected action and the source evidence. Cover at least six stock requests, six price requests, six delivery-status questions, six ambiguous or cross-reference cases and six high-risk cases such as stale data, quantity above stock or unauthenticated contract pricing. This mix is a proposed pilot design; adapt it to what your customers actually ask.

Score each answer on product identity, numerical accuracy, unit, freshness statement, entitlement, promise control and handover. A wrong SKU, leaked contract rate or unsupported delivery guarantee is a critical failure even if the rest of the wording is polite. Record whether the agent cited the right record. A safe “I cannot confirm” can pass when the data is missing. Re-run all 30 after each change to retrieval, instructions or source format. Add newly discovered failures to the set rather than replacing uncomfortable cases.

A useful test prompt for the agent's own instruction is short and restrictive. It should say which fields are authoritative, how to calculate available quantity, what freshness limit applies, and the exact escalation conditions. Do not rely on a broad request to “be accurate”. Give examples of forbidden inferences such as treating on-hand as available and label-created as despatched. Keep the instruction version with the test record so a regression can be traced.

Answer only from the current approved stock, price and order-status records.
Name the SKU, unit, source timestamp and whether the quantity is on-hand
or available-to-promise. Never infer contract entitlement from chat text.
Never promise delivery from stock alone. If source data is missing, stale,
ambiguous or below the requested quantity, create a sales-desk handover.
Do not change stock, price, order or shipping records.

A passing answer from the pilot might read (illustrative): “SKU A17: 14 cartons available-to-promise at 10:05. Your request is for 18, so the desk will confirm the balance and delivery.” The evaluator should verify that the export really showed 14 sellable unallocated cartons at 10:05 and that the handover contains the request for 18. If the agent says “18 should be fine” in a later retest, fail it even if the customer-facing tone is better. This is a safety test, not a writing competition.

Launch with monitoring and a way to stop

Begin with internal desk use or a small customer group. Review every transcript for the first set of live conversations and sample later ones once errors are rare. Compare answers against the source version available at the time, not the current stock value. Track critical failures, false refusals, handover completeness and the age of exported data. A rise in unsupported answers or missing timestamps should pause automated replies. Keep a manual route visible even when the agent is online.

At the end of each week, ask why the agent escalated. A cluster of “SKU not found” cases may mean catalogue aliases are missing. Many “price expired” cases may mean the list is not being published on time. Repeated delivery questions may indicate customers lack a clear status page. Fix the upstream process where possible. The broader distributor automation guide can help prioritise that work, but this stock agent succeeds only when its own source, answer and handover remain traceable. A sales desk that can explain every promise is the standard to aim for.

Review the first failure after launch in the same way as a test failure. Save the customer wording, source version, retrieved rows, agent answer and desk correction. Decide whether the fault was an incorrect source, a retrieval miss, an instruction failure or an unsupported promise. Each calls for a different repair. A source fix may require a new export; a retrieval miss may need better SKU aliases; a promise failure may need a stricter response rule and another test case. Do not simply tell the agent to “be more careful”. Re-run the 30-query set after repair and note the version that returned to service.

Stock-agent questions from trade teams

Can the agent promise that stock is available?

Only if the stock source, allocation rules and refresh interval justify that wording. A safer answer distinguishes on-hand, available-to-promise and unconfirmed quantities, states when the data was last refreshed, and sends larger or urgent requests to the sales desk. The agent should never reserve stock merely by answering a question.

Should the agent show every customer the same price?

No. Use an approved public price list for unauthenticated enquiries. Customer-specific rates require verified identity, the correct contract version and access controls. If any of those are missing, the agent should ask the sales desk to confirm a quote rather than expose another customer's terms.

How do we test a stock chatbot before launch?

Use at least 30 real, anonymised enquiries covering stock, substitutions, prices, delivery windows and ambiguous product codes. Compare every answer with the source and an experienced sales-desk response. Record incorrect promises and leakage as failures, not merely low confidence, then retest after changing the data or instruction.

Further reads

• Credit Control Software for Small Distributors: AI Features to Compare — Keep account and payment questions in their own workflow.
• Best AI Tools for B2B Marketing at a Small Manufacturer or Distributor — Ten AI tools matched to industrial marketing jobs: case studies from job notes, datasheet copy, trade emails and follow-ups, with prices and examples.
• Best AI for Ecommerce Operations: Orders, Stock, Returns, Suppliers — Back-office AI for an online store: Sidekick for orders, Gorgias or Tidio Lyro for returns, and an assistant for supplier emails and reorder checks.
• Builders Merchant Software: Trade Accounts, Quotes and Where AI Fits — Buy trade-counter software for accounts, stock and pricing; use AI on the edges: emailed materials lists, statement chasing and stock queries.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Microsoft Learn, Retrieval augmented generation (RAG) and indexes in Microsoft Foundry; Microsoft Learn (Azure Architecture), Design and Develop a RAG Solution on Azure. The operational thresholds and examples are illustrative recommendations, not vendor claims.