AI and automation in industrial distribution

The first step is naming the process that costs handwork every day: capturing inquiries, chasing quotes, maintaining catalogs, checking invoices, working through the shared mailbox. Where that process is clearly defined and the input arrives in a fixed shape, classical workflow automation is the right answer: cheaper, faster, permanently auditable, with no per-case running cost. AI comes in where the input is unstructured — prose in an email, a PDF with no fixed layout, a spreadsheet full of somebody else’s part numbers. In practice the right cut is nearly always a mixture of the two, and which part is which you will hear from me before the quote.

Yes, and that is the normal case rather than the exception. There is no minimum setup you have to buy first. What matters is not what your systems are called but whether the data sits somewhere dependable and whether somebody can say which list wins in case of doubt. Spreadsheets that grew over the years are often more usable than a badly maintained specialist system — they are just more laborious to connect, and that is effort on my side, not yours. What can genuinely be missing is something else: if nobody in the company can decide which price or which part number is the correct one, then a foundation is missing that no software replaces. That is what we look at first.

Your project is broken into stages, each estimated and quoted on its own. So you only ever commission the next manageable stage, with a result that is useful on its own, and then decide whether the next one follows, without ending up owning something half-finished. Two items recur, and both belong in the quote rather than the small print: compute, which you pay per use with a cloud model or as a one-off machine plus power in-house, and maintenance when one of your systems changes. Because the automated tasks recur daily, the first stage has typically paid for itself within a few months. The initial conversation costs you nothing but time and can end with me advising against it.

That depends on your data. If product data is structured and access is stable, it moves quickly. If access to a core system has to be created first, that is where the bulk of the work sits. To judge that, we look together at what is in place and how the data comes together today. Out of that comes a plan with a defensible range for the first step — before anything is commissioned.

Yes, provided your system offers a way out, and the large ones do anyway. The other case matters more: niche industry software barely anyone has heard of, and systems grown in-house over years, almost always have one too — a programming interface, a scheduled export, sometimes just a file dropped somewhere overnight. Integration uses the vendor’s official routes rather than direct database access, so the connection holds when something changes there. If there genuinely is nothing, we settle it with your vendor before anyone improvises. We look together at what you have in place and derive a plan from it: what can be connected, in which order, and where it pays off first.

That is exactly the right worry, because a quote with the wrong line costs you either the margin or the customer. So a person decides on every line before it goes out. For every recognised line your sales desk sees what it rests on: which part number, which place in the document, and how unambiguous the match was. Unambiguous matches go through; everything else is flagged and put in front of your sales desk — ten queries beat one wrong order. Before the start we set the hit rate this has to reach to pay off for you, and it is measured in day-to-day operation, not just once at acceptance.

The question deserves asking, and your co-owner will ask it. Everything produced is yours and built so somebody else can carry it on: common standards, documented code in your own archive, written-down procedures, automated tests, and an installation that can be repeated at any time. An average systems house can take it over. On larger undertakings I work with your team or bring in established partners. And the first step stays small enough that you can judge me on a real result before anything important depends on it.

That matters more than any technical question, and it is decided before the start. The shape is deliberately one where the decision stays with your people: the proposal is automatic, the sign-off is theirs. I say it that way to them too, not only to you. Where work output becomes visible, your works council belongs at the table before the start. Which analyses exist and which explicitly do not, we put in writing.

This one comes up almost every time, usually from IT and often with the remark that the data protection officer will surely object. Three points ease it. First, most of the work needs no AI at all: routing a message by sender, subject, customer number or attachment type runs on fixed rules that nobody would call content analysis. Second, GDPR does not forbid automated processing of email; it requires a legal basis, a clear purpose, data minimisation and traceability. Third, and this surprises most people: a documented process meets that standard better than the current state. In a shared mailbox that grew over years, everyone sees everything, nothing is logged, and nobody can say who read which customer data and when. Afterwards there are graded access rights, defined retention periods and a log of every step. Where a language modelLLMA large language model that understands and generates text, forming the technical basis of modern AI assistants. genuinely is needed, it can run entirely on your own infrastructure. Every message then stays in the building, and your data stays yours. Coordination with your data protection officer and, where required, a data protection impact assessment still belong in any serious project.

Both yes, and the two are connected. GDPR compliance is not a product feature you buy; it follows from which data leaves your building, who processes it, for how long, and whether you can demonstrate it. The simplest case is when nothing goes out at all: model serving, search, permission checks and logging run on your own hardware with no outbound connection. For a local AI with a single-digit user count, one machine with a graphics card is usually enough. Two further points ease the situation: your product mastermaster dataThe durably maintained core records of a business — articles, customers, suppliers. Their quality caps whatever any analysis on top can achieve., attributes and pricing logic are not personal data, and I work under a data processing agreement and NDA with no transfer to third countries. The binding assessment is yours as the controller, with your data protection officer advising, and I supply the information they need.

No, and that would be the most expensive route. Your core systems stay exactly where they are; what gets automated is what happens between them. Replacing an ERPERPThe central system for commercial operations — orders, stock, pricing, invoices. Usually the authoritative source for numbers in the business. ties up a year or two, touches every department, and usually does not solve your actual problem — because that problem does not sit in the system but in the handovers between them. Those can be tackled one at a time, without anyone touching a running system.

For a while it is, and while it holds you should change nothing. It tends to break at the same points: nobody reliably sees who has already picked up an inquiry or how long it has been sitting, rules collide, holiday cover becomes manual work, and none of it can be analyzed afterwards. The deciding point is a different one: an email is communication, not a case. A case needs an owner, a status and traceability — and in distribution also the link to customer, quote and order, which Outlook knows nothing about. That needs neither a new mailbox nor a large ticketing system, just a layer above it.

I hear that often, and the cause is nearly always the same: the pilot ran against a test data export instead of your real product mastermaster dataThe durably maintained core records of a business — articles, customers, suppliers. Their quality caps whatever any analysis on top can achieve.. Tell me where it failed. It is usually quick to place whether the technology or the data was the problem — and what that means for a second attempt.

For inquiry capture, catalog maintenance and information lookup you are generally outside the strictly regulated applications. Three things remain: anyone talking to an AI system must be able to tell (Article 50). The people involved need adequate competence (Article 4, in force since February 2025). And documentation covering purpose, data sources and limits. Rarely asked but important: whoever develops an AI system and puts it into service under their own name counts as a provider rather than merely a deployer. As long as the application is not high-risk the obligations stay manageable; for high-risk applications they become considerably wider. An internal AI policy is the practical route there.

The vendor’s name is the wrong first question. What matters is whether the tool can reach wherever your article, pricing and customer data actually lives, and whether the answer can be substantiated. Once that is settled, ChatGPT, Claude, Gemini or a self-hostedself-hostedThe solution runs under your own control or in infrastructure you choose rather than exclusively with the provider. model are interchangeable. The choice becomes a cost question, and you stay independent of any vendor.

A chatbot answering general questions on your website is quick to set up and priced accordingly. But as soon as it should say anything about part numbers, availability or pricing, the cost no longer sits in the chatbot — it sits in how readily your systems hand over their data. With a well-maintained product mastermaster dataThe durably maintained core records of a business — articles, customers, suppliers. Their quality caps whatever any analysis on top can achieve. and an existing interface that is manageable; if the access has to be created first, that is where the bulk of the work is. So it does not start with the chatbot: we first look at which systems you run and how their data can sensibly be made reachable. The price follows from that — and along the way, whether a chatbot is the right first step for you at all.