Free Inventory Checker Chatbot Template: Stock Answers

The Inventory Checker template is a four-option service desk for stock. It lets whoever is asking check a stock level, find where an item is stored, report that something is running low, or request a restock -- all from one short menu, in a chat window, without opening the warehouse management system or finding a supervisor.

The people it helps most are the ones furthest from a desk. A shop-floor assistant with a customer waiting, a picker in an aisle, a duty manager covering two departments, a franchise operator checking a central store. These are exactly the people for whom a full inventory system is too heavy: they need one number, or one aisle reference, and they need it in under thirty seconds. It also works as a customer-facing "is it in stock" check on a retail site, which is one of the most common pre-purchase questions there is.

What makes the template useful is not that it is clever, it is that it is short. Four options, one question each, then an answer and an offer to go again. Nothing about it requires training. A seasonal hire can use it on their first shift.

It is built in Conferbot's no-code drag-and-drop builder, so every prompt is an editable sentence, and it is usable on the Free plan. It sits in the ecommerce and retail library. The important caveat, stated plainly here and repeated later: as shipped, the two lookup answers are placeholders. The conversation is complete; connecting it to your real stock data is the work you do after you open it.

Eighteen nodes, with the shipped prompts and options.

1 and 2. Welcome and the main menu

The bot opens with "Welcome to the Inventory Checker! I can help you check stock levels, locate items, and manage inventory. How can I assist you today?" Then a single-choice node presents the whole tool in one question -- "Please select an option:" with Check stock level, Locate item, Report low stock and Request restock. Every path in the flow starts here, and every path eventually returns here.

3 and 7 and 11. Check stock level

Choosing the first option asks "Please enter the item ID or scan the barcode:". Offering the barcode alternative in the prompt matters: on a shop floor or in a warehouse, scanning into a chat field is faster and far less error-prone than typing a SKU. The bot acknowledges -- "Checking stock level for item {item_id}. Please wait..." -- and then returns the answer: "The current stock level for item {item_id} is: [STOCK_LEVEL]". That bracketed placeholder is the point where your real data has to arrive.

4 and 8 and 12. Locate item

The second option asks by name rather than by ID: "Please enter the name of the item you want to locate:". That is the right choice, because someone hunting for an item usually knows what it is called and not what its SKU is. The bot acknowledges with "Locating item: {item_name}. Please wait..." and answers "Item {item_name} is located in: [LOCATION]" -- again a placeholder awaiting a real lookup.

5, 9, 13 and 16. Report low stock

The third option is a reporting path rather than a lookup. It asks "Please enter the ID of the item with low stock:", then a validated number node asks "What is the current quantity of this item?" so the report carries a real figure rather than a vague warning. The bot confirms it is filing the report and closes with "Low stock report for item {low_stock_item_id} has been submitted. Thank you for your report." This is the branch that quietly does the most good -- it gives floor staff a two-tap way to flag a problem they would otherwise mention to no one.

6, 10, 14 and 17. Request restock

The fourth option asks "Please enter the ID of the item you want to restock:" and then "How many units would you like to restock?" through a number node. The bot acknowledges the processing step and confirms: "Restock request for {restock_quantity} units of item {restock_item_id} has been submitted successfully."

15 and 18. The loop

All four branches converge on one yes-or-no node: "Would you like to perform another inventory check?" with Yes, return to main menu and No, end session. Yes sends the user back to the four-option menu, which is what makes this usable during a shift -- a picker checking six items never restarts the chat. No ends on "Thank you for using the Inventory Checker. Have a great day!"

There is no human-handover node in this flow and no integration node. Both are sensible additions, and both are covered below.

Every row below already exists as a node in the shipped flow.

Conversations are visible in the shared inbox on every plan, so a supervisor can see what the team has been asking about even before you connect any data.

The conversation takes minutes. The data connection is the real project, and how long it takes depends entirely on what your stock lives in.

Step 1: Open the template and match your vocabulary

Create a bot from the template and the eighteen nodes load into the drag-and-drop canvas, already wired. First edit: make the prompts use your words. If your team says "bin" rather than "location", or "part number" rather than "item ID", change them. Small vocabulary mismatches are what make internal tools feel foreign.

Step 2: Decide who this is for

A staff-facing version and a customer-facing version are different bots. Staff get all four options. Customers should usually see only the stock check, with the reporting and restock branches removed and the wording softened. Deleting two branches in the builder takes a minute and it is worth doing rather than trying to serve both audiences from one flow.

Step 3: Replace the placeholder answers with real data

This is the step that matters. The [STOCK_LEVEL] and [LOCATION] lines are literal placeholder text. Replace each with a real lookup: a webhook node that queries your inventory API using the item ID or name the user supplied and returns the value into a variable, or -- for smaller catalogues -- a Google Sheets lookup against a stock sheet. Webhooks and API access require Starter or above; Google Sheets works from Free.

Step 4: Route the reports somewhere a person reads

Low-stock reports and restock requests currently end at a confirmation message. Add a Google Sheets node so each one appends a row with item ID, quantity and timestamp, and add a Slack or Gmail node so the purchasing team is notified rather than having to check a sheet. Both are shipped integrations.

Step 5: Connect a channel, test, publish

For staff, put it in Slack or Microsoft Teams; for customers, on the website widget. Then walk all four branches, including entering a deliberately invalid item ID to see what your lookup returns, and check that the loop back to the main menu works. Publish when all four behave. See pricing for the plan that matches your volume.

The shipped flow is a clean skeleton. These are the changes that make it operational.

Handle the not-found case

The flow assumes every lookup succeeds. Add a condition node after your stock lookup that branches when the item is not found, so the user gets "I could not find that item ID -- would you like to search by name instead?" rather than an empty answer. This single addition removes most of the frustration people report with internal lookup bots.

Add multi-location awareness

Most retailers have more than one store or warehouse. Insert a choice node before the item question asking which location the user means, and pass it to your lookup. You can then answer the far more useful question: not just how many, but how many here versus how many at the other branch.

Set an automatic low-stock threshold

Rather than relying on someone to notice, add a condition after the stock lookup that compares the returned figure against a reorder point and, when it falls below, offers to file a restock request immediately. The user goes from checking stock to fixing it without changing task.

Add approval and an escape hatch

Restock requests usually need sign-off. Route them to a human-handover node or a Slack notification so a buyer approves before an order is raised; the conversation arrives in your live-chat inbox with the full transcript. Adding a fifth menu option that simply reaches a person is also worthwhile, because someone will eventually need to ask something the four branches do not cover.

Connect it to the customer-facing flows

Stock questions rarely travel alone. The order tracking assistant answers the question that follows a purchase, the price drop alert system gives an out-of-stock shopper something to opt into, and the Shopify store chatbot and WooCommerce store chatbot cover the storefront conversation this bot slots into.

Every Conferbot channel is open on every plan including Free, so pick by audience rather than by price.

For staff, Slack and Microsoft Teams are the strongest fit by a distance. Your team is already in one of them, the bot becomes another conversation in the sidebar, and there is nothing new to install or log into. Stock questions asked in a channel also leave a visible trail, which is useful during a stocktake or a busy trading period.

The mobile SDK matters here more than for most templates, because warehouse and shop-floor staff are on handhelds. If you run an internal app, embedding the checker means a scanner can feed straight into the item-ID question.

WhatsApp suits distributed teams, field reps and franchise operators who are not on your corporate messaging platform, and Telegram serves a similar purpose. For the customer-facing version, the website widget on product pages is the right home, with the Shopify or WooCommerce integration if you are on one of those platforms. Whichever mix you run, the conversations land in one inbox -- that is what omnichannel gives you.

Be clear on this before you roll it out to a team.

It does not read your inventory system. The [STOCK_LEVEL] and [LOCATION] answers are literal placeholder text in the shipped template. Until you add a webhook or a Google Sheets lookup, the bot will reply with those brackets, which is fine while you are testing and confusing if staff meet it first. Wire the data before you announce it.

It does not write to your inventory either. A restock request is a message, not a purchase order, and a low-stock report is a record, not an adjustment. Both need routing to a system or a person who acts on them. It also has no user authentication of its own, so if stock figures are sensitive, run the staff version on Slack or Teams where access is already controlled rather than on a public web widget.

Finally, it does not reserve or allocate stock. A number returned to a customer is a snapshot, not a hold, and in 2026 shoppers treat an "in stock" answer as a promise. Word the customer-facing version carefully.