01
Status accuracy
On a sample: whether what the system said matched the TMS at that moment, with its timestamp.
How it gets fixed
Live queries, never the index. It is the failure that makes the customer stop trusting the channel.
AI for logistics and transport
The question a logistics operator receives most is "where is my shipment?", and it has an exact answer in a system. The problem was never knowing it: it was delivering it on time, in the channel where people ask.
4–8 weeks to production · 10 years connecting enterprise systems · 48 hours to a proposal with fixed scope and price
- Shipment status
- Proactive notification
- Documentation
- TMS
- WMS
- Exceptions
Built on
An engineering team that has already been on the other side.
Ninety seconds: who we are, how we work and what you get at the end.
The same sourced answer on every channel
WhatsApp, the website or email land in the same system: it understands the question, searches your documents, answers with a citation and hands over to a person when unsure.
Example: a customer asks where their order is. The system locates it and tells them when it arrives.
WhatsApp connected
Web connected
Email connected
01 Channels
02Understands
Reads the message
Detects the entityroute = bogota_cali
Picks the sourceTMS · shipments
Where is order 5521 and when does it arrive?
03Searches
94 of 100finds the right chunk
142 mstakes
Searches by meaning and by exact words, and filters by the tag before choosing.
04Answers with a source
In Ibagué since 14:10; estimated arrival 19:30. Source: TMS, waybill 5521.
answers with a source · 91 of 100
05Hands over
- Not enough backing
- A person on the team is notified
- Full conversation attached
- Human answer logged
Swipe to follow the flow →
The five problems in a logistics operation
01
No shipment visibility for whoever is asking
The data exists in the TMS and does not reach the end customer, who ends up calling.
02
Support buried in the same query
Status, estimated date, exception, rescheduling. High volume and an exact answer.
03
Fragmented communication with carriers
Emails, calls and spreadsheets between several parties, with the exception surfacing late.
04
Errors in documentation
Delivery notes, manifests and receipts retyped by hand, and every error is discovered at the delivery point.
05
Inefficient routes
Real and expensive, but it is a constrained optimisation problem, not a conversational one.
01
The technical part
Live status, and telling people before they ask
Shipment status is the most volatile data in this domain: it changes several times a day. It gets queried live against the TMS at answer time, never from an index, and the answer carries the data’s timestamp. An assistant answering with last night’s status does not reduce calls: it multiplies them, because now the customer distrusts both sources.
The second decision pays most and almost nobody implements it: invert the flow. Instead of waiting for the question, the system detects the exception — the delay, the failed delivery, the route change — and tells people. An expectation managed in time costs one message; the same fact discovered by the customer costs a call, a complaint and sometimes the account.
And a warning about route optimisation: it is an operations-research problem with hard constraints — capacity, time windows, traffic regulations — and an optimisation engine solves it, not a language model. When the case justifies it we build the engine and the model explains the result to the planner. A vendor offering "AI-optimised routes" without naming the engine is selling text.
How it is measured
The numbers behind a logistics operation
02
Proactive notification coverage
Of the exceptions that occurred, how many were flagged before the customer asked.
How it gets fixed
Usually a missing event from the TMS or the carrier, not a system capability gap.
03
Resolution without a person
What share of status and rescheduling queries closes without escalating.
How it gets fixed
You widen what the system can do, not what it can say.
04
Document accuracy
Field by field on delivery notes and manifests, against a hand-validated batch.
How it gets fixed
An error in an address or a weight is discovered at the delivery point, which is the worst place.
When this does not apply
If the TMS does not expose status over API, or the operation runs on spreadsheets updated at end of day, the first project is that traceability, not the assistant. A system answering with last night’s data generates more calls than it saves.
And if what you want is route planning, we say it plainly: that is a constrained optimisation engine, not a language model. We build it when the case justifies it, but we do not sell it as conversational AI, because it is not.
Related services
Integrations and APIs
Connecting the systems that do not talk today
MCP servers against the systems already in operation.
AI automation
If someone does it by copying and pasting, it can be automated
Applied where there is volume and stable rules, not where there is expectation.
AI chatbots and assistants
Chatbots for businesses of every size
With the evaluation set run before it ever reaches production.
AI agents
Agents that do the work, not just talk about it
LangGraph orchestration, durable state and human approval on steps with consequences.
Key takeaways
Four things before the call
- 01
Most of a logistics operator’s support volume is a single question with an exact answer in the TMS. That is the case, and it is one of the most measurable there is.
- 02
Status is queried live against the system, never from an index. A stale status in the chat generates more calls than it saves.
- 03
Proactive notification is worth more than the answer: flagging the delay before they ask turns a complaint into a managed expectation.
- 04
Route optimisation is an operations-research problem, not a language one. An optimisation engine solves it, and the model explains the result.
This is where the data comes in
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
A RAG system in production: three years, two million users
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 →Frequently asked questions
01 Does it connect to our TMS or WMS?
Yes, over API or an MCP server against whichever system you run, and against carrier platforms when shipping is outsourced. It is the requirement rather than an enhancement: without reading live status, the assistant can explain how the process works but cannot say where a shipment is, which is the question that carries the volume.
02 Can it notify on its own when there is a delay?
Yes, and it is the highest-return part of all this. The system detects the exception in the TMS — delay, failed delivery, route change — and notifies through the customer’s channel before they ask. An expectation managed in time costs one message; the same fact discovered by the customer costs a call, a complaint and sometimes the account. The metric is what share of exceptions was flagged in time.
03 Does it optimise routes?
It can be built, with an important caveat: that is a constrained optimisation engine — capacity, time windows, regulations — not a language model. When the case justifies it we build the engine, and the model explains the result to the planner rather than producing a route out of text. If a vendor offers "AI-optimised routes" without being able to name the engine or the constraints it respects, they are selling a description.
04 Is this for a shipper rather than an operator?
Yes, and it is usually simpler. A company shipping its own orders needs to answer "where is mine?" and flag exceptions, against the platform of the carrier it hired. The requirement is the same: that platform has to expose status in a queryable way. If tracking lives in a shared spreadsheet, that is the first project.
05 Can it reschedule a delivery on its own?
It can, if the TMS allows it and you authorise it, and that is where the assistant moves from informing to resolving. We recommend explicit limits: what it can reschedule alone, up to how many days, and which cases always escalate. Those limits get defined with the operation before building and live in the system, not in a prompt that can be negotiated mid-conversation.
06 How long does it take and how is it priced?
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 how many systems and carriers have to be connected.
Fifteen minutes. A concrete answer.
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.