Availability accuracy
On a sample: whether what the assistant said matched inventory at that moment.
What happens if it fails
Availability comes out of the index and gets queried live. It is the most expensive failure and the most common.
One thing separates a store assistant that sells from one that annoys: whether it knows what is in the warehouse right now. We build on live inventory and real order status, and measure accuracy against the system.
4–8 weeks to production · 2M+ users served on a loyalty and retail platform · 10 countries with different catalogues and languages
Built on
Ninety seconds: who we are, how we work and what you get at the end.
Contracts, price lists, email, the CRM: what you already have becomes sourced answers and agents that do the work. Pick a case and follow the path.
Example: a customer wants to return an item. The system checks whether it qualifies and issues the label.
Connected by API or uploaded. Nothing leaves your infrastructure when the case demands it.
8,400 rows → 8,400 cards
Searches by meaning and by exact word, and filters by the tag before choosing.
answers with source · 91 of 100
Swipe to follow the flow →
01
"Will it arrive before Friday?", "does this size run small?". With no answer in the moment, the purchase is not postponed: it is gone.
02
The store search does text matching; the shopper describes what they need, not the catalogue name.
03
Order status, exchanges, returns and warranties: high volume, mechanical answers, almost always available in a system.
04
Nobody suggests the accessory that goes with it, because nobody is watching the conversation at that moment.
05
A good share of online shopping happens at night, and there is nobody on the other side.
01
The technical part
This is the difference from almost every other retrieval case. An insurance wording or a manual changes occasionally; a catalogue changes every minute: products come in, sizes sell out, prices move, a promotion runs. Indexing the catalogue as if it were a document produces an assistant that answers confidently about last week’s inventory.
The right architecture separates two things. The semi-stable — descriptions, materials, size guides, returns policy — goes into the index. The volatile — price, availability, shipment status — is queried live over API at answer time, never from the index. The system retrieves the product and then asks how many there are, instead of remembering how many there were.
The practical consequence is that this is as much an integration project as an AI one. We work against Shopify, WooCommerce, VTEX or an in-house system, and if that integration cannot be built, we say so before quoting rather than shipping an assistant that improvises availability.
On a sample: whether what the assistant said matched inventory at that moment.
What happens if it fails
Availability comes out of the index and gets queried live. It is the most expensive failure and the most common.
Whether the price quoted is what the customer sees at checkout, with the active promotion applied.
What happens if it fails
Same fix: live price, never indexed. A different price in the chat and in the cart is a guaranteed complaint.
What share of status, exchange or return queries closes without a handoff.
What happens if it fails
Usually a missing integration with the carrier or the returns flow, not a model capability gap.
When the case leaves the script — a complaint, damaged goods — it reaches a person fast and with context.
What happens if it fails
An assistant that insists on solving what it cannot turns a lost sale into a lost customer.
If the store carries few SKUs and the questions are always the same five, a subscription platform with prebuilt flows solves it at a fraction of the cost, and it is the right call. We say so on the first call.
The conversation changes with a wide catalogue with variants, inventory that moves, several channels and aftersales volume — or when there is already a bot giving wrong stock answers, which is when the problem stops being about cost and becomes about reputation.
With the evaluation set run before it ever reaches production.
MCP servers against the systems already in operation.
LangGraph orchestration, durable state and human approval on steps with consequences.
Applied where there is volume and stable rules, not where there is expectation.
Key takeaways
A store assistant that does not query inventory is not an assistant: it is a brochure that talks. The integration is not a later improvement, it is the requirement.
The metric in this sector is not satisfaction but accuracy against the system: say there is a medium in stock when there is not, and you lost the sale and gained a one-star review.
Where it pays most is aftersales — "where is my order?", "how do I return this?" — the largest share of queries and the most mechanical.
Product recommendation only works over first-party behavioural data. Without it, the system recommends what sounds similar, which is not the same as what sells together.
An AI system is worth what its sources are worth. These are the standard connectors; anything with an API or a database connects the same way, and what has no API is handled by file.
SAP
Enterprise ERP
Oracle
ERP and database
NetSuite
Cloud ERP
Salesforce
CRM and service
HubSpot
CRM and marketing
PostgreSQL
Database and pgvector
Microsoft SQL
Database
Snowflake
Data warehouse
BigQuery
Google data warehouse
Databricks
Data platform
Redshift
AWS data warehouse
Synapse
Azure data warehouse
Supabase
Managed Postgres
Workday
Payroll and HR
QuickBooks
Accounting
Sage
Accounting and ERP
Xero
Cloud accounting
Shopify
Catalogue and orders
WooCommerce
Catalogue and orders
Magento
Catalogue and orders
Stripe
Payments and subscriptions
Google Drive
Documents and folders
CSV y Excel
Flat files
Nothing in this category
We built and operated the assistant for a loyalty platform serving more than two million active users across ten countries.
We built the full pipeline: document ingestion and normalization, chunking, embedding generation, vector store on Azure AI Search and Pinecone, and retrieval with grounded generation on LangChain.
We held it above 99% availability for three years.
RAG systems →Yes, to those and to in-house systems, over API or an MCP server. And it is the part that decides whether the project is worth doing: without reading inventory and order status, the assistant can describe products but cannot sell or resolve aftersales. When the platform does not expose what is needed, we say so before quoting rather than shipping something that improvises availability.
It can take the order, and on WhatsApp that is where it pays most in Latin America: it builds the cart, confirms address and payment method, and leaves the order created in the platform. The decision we recommend is where the flow cuts: payment usually stays on a gateway link rather than inside the chat, because handling card data in a conversation adds a compliance problem that is not worth what it saves.
Yes, and it works better when the message answers the specific doubt that stopped the purchase rather than being a generic reminder with a discount. That requires knowing where the customer dropped off, so it depends on the platform integration. We recommend measuring it with a control group: without one, every recovery gets attributed to the system, including the ones that were going to happen anyway.
Over first-party behavioural data — what got bought with what, what this customer looked at, what they returned — rather than what the model believes about the category. Without that connected history, the recommendation is text similarity: it suggests what sounds alike, which is not what sells together. If the history does not exist, we start with simple rules and catalogue data, and we say so plainly.
Yes, and it is often the highest-return case in Latin America because the channel is WhatsApp: checking availability by location, holding an item, answering hours and handling aftersales. The requirement is the same: inventory per location has to be queryable. If store inventory lives in a spreadsheet updated overnight, that is the first project, not the assistant.
Four to eight weeks to production depending on integrations, with something running from week one. It is quoted with fixed scope, price and date in a proposal 48 hours after the first call, and the price is driven by catalogue size, how many systems have to be connected, and how many channels it has to run on.
It gets fixed, it gets built, or it is not worth it. And if the diagnostic does not reach three actionable findings, it is not charged.
We use cookies to improve the user experience. Privacy