AI in trade brings to mind demand forecasts and dynamic pricing. Yet in a trade and distribution business — wholesale, distribution, B2B sales — the first projects that actually pay off concern the daily flow of documents: orders, quote requests, price lists and settlements — where the data already exists and a mistake is visible at once.
AI is sold to trading companies from the analytics side: demand forecasts, price optimisation, recommendations. Those projects can be valuable, but they share a precondition the offers stay silent about — a complete, tidy history of sales and stock. In practice that history tends to be patchy: stock-outs masquerading as no demand, unmarked promotions, the same product living under two codes. A forecast computed on such data is a number generator, not a decision tool.
Meanwhile, in the same company, a stream of work flows every day that AI can take over now: orders arriving by email and phone in a dozen formats, retyped into the ERP by hand; quote requests waiting for pricing assembled from the price list, the customer’s terms and availability; supplier price-list updates entered line by line; purchase invoices checked against orders and goods receipts by hand. These are document- and text-based processes — the data exists, the rules can be written down, and a mistake is detectable and reversible.
That is why a good first AI project in a trading company looks unspectacular: it does not predict the future, it puts the present in order. In return, it pays off in weeks — and builds the very data history the forecasts will one day need.
The common denominator: a person approves the output, the system prepares it. Which processes qualify for this kind of automation at all — the five conditions a good candidate must meet — is set out on our AI automation page; in a trading company those conditions are checked in exactly the same way.
Trade documents are this industry’s most sensitive data: purchase prices, margins, individual customer terms — information whose leak hurts more than many an outage — and the contact details of the people ordering are personal data. Before any document reaches a model, you have to settle which data leaves the company at all, where it goes and on what basis — from the choice of provider and processing region to limiting the data to the minimum the step needs. How we approach this, and what to ask any supplier, is set out on our security and GDPR page.
The same way as in any implementation: one process, a number measured before the start — for example, minutes from an order arriving to its ERP entry — the narrowest possible pilot in approval mode, and parallel running before the switch. The salespeople’s corrections are recorded and used in periodic tuning of the system — that is what improves the proposals over time. The full course is set out in our implementation methodology, and the full scope of the service, from process audit through to upkeep, on our AI implementation page.
Three things drive the cost: the number of systems to connect, the state of the data, and the level of certainty required. The size of the product range matters less than whether the orders and documents live in one system or in the mailboxes and spreadsheets beside it. All the components, upkeep included, are broken down in our note on what an AI implementation costs.
With the processes that recur daily and have their data in documents: orders retyped into the system by hand, quote requests waiting for pricing, supplier price lists entered line by line, purchase invoices checked against orders. There the data already exists, a mistake is reversible, and results show in weeks. Demand forecasting and price optimisation first require a complete sales history — which is why they are rarely a good first project.
A forecast is only as good as the data it is built on — and in trading companies the sales history tends to be patchy: stock-outs masquerading as no demand, unmarked promotions, the same product living under two codes. The honest order of work is to put the sales and stock data right first, then forecast. Pricing decisions are a separate matter: the system can prepare the analysis and a proposal, but the decision on price and margin stays with a person — it is too expensive a place for a model’s quiet mistake.
That is a question the audit at the start of a project settles, but the principle is simple: if the system has an API or file import, integration is a matter of scope, not possibility. The trade and warehouse systems in use vary widely here, and that difference affects the cost, not the point of the project. More important than the system itself is how orders and documents reach it: email, phone, the B2B shop, EDI — because that stretch of manual retyping is what we automate first.
Cost is driven by the number of systems to connect — ERP, shop, warehouse, email — the state of the data, and the level of certainty required. The size of the product range matters less than whether orders arrive through one channel into one system or through five into two. Upkeep is a separate line: per-operation fees and periodic retesting after model version changes. We break the components down in our note on what an AI implementation costs.
Purchase prices, margins and per-customer terms are a trading company’s most sensitive data, and the contact details of the people ordering are personal data. Before any document reaches a model, you have to settle which data leaves the company at all, where it goes and on what basis — from the choice of provider and processing region to limiting the data to the minimum the step needs. The principles, and the questions worth asking any supplier, are set out on our security and GDPR page.
Describe it in a few sentences. We will tell you whether we see a candidate for a first project — including when the answer is that it is not worth it yet.
Book a free consultation