We have been writing our own software since 1988
A few weeks ago, a specialist reseller asked me whether we could print delivery notes for his end customers with his logo, his sender details and his numbering system. He asked in the apologetic tone you develop when you are used to being told no to questions like that. At a distributor using off-the-shelf software, the answer would indeed have been no – or, more precisely: a ticket raised with the software provider, a place somewhere in the release schedule and an implementation date at some point next year. Our answer was: from Monday.
The reason goes back thirty-eight years and, at the time, it was not a strategy but a matter of necessity. When we started in 1988, there simply was no suitable software available to buy for what we do. We could have bought something and adapted our processes to fit it. We did the opposite and adapted the software to fit our processes. Looking back, it was the most consequential decision this company ever made, and I want to be honest: at the time, I had no idea just how significant it would prove to be.
Because a standard ERP system does something very specific to a business. It forces your own processes into a structure that somebody else designed for the average of all their customers. Every exception becomes a workaround, every workaround ends up as a separate Excel spreadsheet, and eventually half the company is working around its own software. You can spot this quite easily from the outside, incidentally: whenever you ask what should be a simple question and the answer is that unfortunately it cannot be done because the system does not allow it. No system refuses to allow anything. Nobody has written the code for it, that is all.
The second part came in 1995, although nobody called it the cloud back then. We had customers dialling into our system to see what we had in stock – at a time when the usual way to get that information was for somebody to call you back after they had checked the warehouse. The benefit was the same then as it is today: you do not ask, you see for yourself. None of this is spectacular. It is simply the difference between working and waiting.
The best way to understand why this matters is to switch sides for a moment and ask a manufacturer what they actually need from a distributor. The answer is rarely »revenue«. What they want is to know where their devices end up, promptly and in their format, not ours. They want a registered project to be genuinely protected rather than overtaken three weeks later by a list price. They want a price change made overnight to flow through every customer price list rather than ending in renegotiations. If there is a firmware problem, they want to know which serial numbers are affected – not be told that unfortunately we only track products at item level. And they want a new product to be available to order on the day it is announced, complete with all its technical specifications, rather than four weeks later when somebody somewhere has finally updated the master data.
In an off-the-shelf system, every single one of those requirements is either an expensive add-on module or a process that two people have to handle manually. For us, it is a question for our own developers. That is why manufacturers entrust us with things they would otherwise do themselves: preconfiguring entire device ranges, creating customer-specific bundles, and provisioning according to a rollout plan rather than the order in which purchases arrive. These are not standard processes, which is precisely why standard software cannot accommodate them.
For you as a reseller, the same mechanism simply works from the other direction. Your product numbers instead of ours on the order. Your price list, which your colleague also sees when they call on a Friday. Your framework agreements with call-off orders spread over several months. A live feed of stock levels and prices into your own webshop instead of a CSV file that arrives by email in the morning and is already wrong by lunchtime. Serial numbers on the delivery note so you can give your end customer documentation for their devices without having to copy them out manually. And, of course, a delivery note with your logo when we ship directly to your end customer.
Work out the value at just one of those points. A reseller manually entering two hundred orders a month instead of processing them through an interface spends, at four minutes per order, more than thirteen hours a month typing – over one hundred and fifty hours a year in which nobody is selling; somebody is simply re-entering information that was already digital in the first place. And a webshop operator whose stock data is half a day out of date will reliably sell something a few times a month that is no longer available. Each of those cancellations costs them not just the margin on the order, but the customer.
The real point, however, is that both sides are talking about the same system. The feedback the manufacturer needs and the data you want to extract are simply two ends of the same process. If you buy one system and bolt the other onto the side, you end up with two systems and an Excel spreadsheet connecting them – and that spreadsheet then has to be maintained by somebody who should really be on the phone to you.
Now for the uncomfortable part, because this approach does not come for free. If you build your own software, you bear the development costs alone – with a standard product, those costs are shared between a thousand customers. We pay for every line of code ourselves, and we also pay for every mistake ourselves. Because we do introduce bugs that would not exist in bought-in software, and when that happens there is no supplier we can point the finger at. That is uncomfortable, but it is the more honest arrangement: the people who made the mistake are also the people who fix it.
Ultimately, it is the same principle I wrote about recently. Whether a decision here takes a day or a quarter does not depend on how clever somebody is, but on how many doors stand between your question and the decision. When it comes to software, there is exactly one. That is why our answer to an unusual requirement is almost never »that can’t be done«, but »when do you need it?«
Remember: »No system refuses to allow something. Nobody has written the code for it – the only question is whether the person who can is in the same building.«
Distribution Mechanics: Beginning 11 September, things get serious – the Cyber Resilience Act affects you too
Over the past few weeks, I have written about the grey market and why that bargain from a broker could end up being the most expensive device you ever buy....
Over the past few weeks, I have written about the grey market and why that bargain from a broker could end up being the most expensive device you ever buy. Today, we come to the legal side of the same story – and it is considerably less romantic than anything I could tell you about warranties. The European Cyber Resilience Act is already in force. On the 11th of September 2026, the first major requirement takes effect: the obligation to report actively exploited vulnerabilities. From the 11th of December 2027, all newly placed products with digital elements on the market will then have to meet the full requirements.
I know exactly how that sounds. Another regulation, another acronym, another thing for manufacturers rather than for you – straight into the folder where the GDPR and Supply Chain Act are already gathering dust. And that is precisely where the misconception lies. The regulation recognises three roles – manufacturer, importer and distributor – and all three come with obligations. As a distributor, you must, among other things, carefully check whether a product meets the requirements before making it available, and you must not sell it on if you have reason to believe that it is not compliant. And anyone bringing goods into the EU from third countries outside official channels may find themselves legally classified as an importer rather sooner than they would like – along with the considerably less pleasant obligations that entails. Suddenly, that bargain purchase from the other day takes on a whole new meaning.
The good thing about this regulation is that it finally makes one question mandatory that was always the right one to ask anyway: Will this device continue to receive security updates, and for how long? In the future, manufacturers will have to specify a support period and address vulnerabilities during that time. This turns something that was previously a matter of trust into something that can actually be verified – and finally gives you something tangible in a sales conversation that cannot simply be argued away.
Because this is exactly where professional-grade products separate themselves from those that merely look cheap. Take a device that your customer intends to use for five years. Option A: €900, with a stated support period covering the entire intended service life. Option B: €640, unclear provenance, and when you ask about updates, everyone along the supply chain simply shrugs. Your customer saves €260 per device and is delighted. But if the device has to be replaced after three years because it is no longer permitted to operate on their network, they have effectively written off €640 and have to pay all over again. Across 200 devices: €52,000 saved, €128,000 lost. Nobody wants to walk into their own management meeting with those figures.
There is a second level to this that will soon matter more to your medium-sized customers than any discount: companies that are themselves subject to stricter security requirements have to document their supply chain. The buyer who only asks you about price today will soon be asking about declarations of conformity, support periods and product provenance. If you have clear answers ready, you make the sale. If your answer is, »I’ll have to check that«, you have just buried your own offer – and I have already written at length in this series about what I think of phrases like that.
And now for the uncomfortable part – fortunately, it is a short one. Get hold of the conformity documentation and stated support periods for your most important products and file them properly – you will be asked for them, you can count on that. Buy from sources that are actually able to provide this documentation, and steer clear of goods whose origins nobody seems willing to explain. And make the support period a standard line in every quotation, right next to delivery time and warranty. It costs you nothing and shifts the conversation away from price.
I am not normally a fan of using regulations as a sales argument – it feels too much like selling with a wagging finger, and we have all had more than enough of that in recent years. But this particular regulation clears up something that has been troubling our market for a long time: comparing the prices of things that simply are not comparable. Until now, a device with guaranteed support and documented provenance and one with neither could sit peacefully next to each other in the same Excel column as though they were twins. That will soon be a thing of the past. And I freely admit: I am looking forward to it.
So remember: »A device without guaranteed security support is not a cheaper device. It is a device with an expiry date nobody told you about.«
Distribution Mechanics: The complaint that never was
There’s a figure in our business that nobody likes to talk about because it’s embarrassing for everyone involved: a significant proportion of devices returned as...
There’s a figure in our business that nobody likes to talk about because it’s embarrassing for everyone involved: a significant proportion of devices returned as faulty are perfectly healthy. No fault, no defective component, nothing. Incorrectly configured, incorrectly paired, the wrong power supply, no proper introduction – or simply a user who expected something the device was never designed to do. The industry has come up with a wonderfully forgiving abbreviation for this: »NFF – no fault found«. Anyone who runs a service centre knows their percentage pretty accurately. They just don’t say it out loud.
The instinct to blame the user is understandable, but it’s still wrong. Because the user isn’t the one paying for the process. You are. Do the math: outbound and return shipping together, €30. Testing, even if nothing is ultimately found, an estimated €45. Your own time spent receiving the return, logging it, asking questions and chasing up on people – let’s generously call it an hour at €75. And then there’s the week during which one of your customer’s workstations is out of action. Even if we generously ignore that last point, you’re already at €150. Twenty cases like that a year comes to €3,000. You’ll never see them in any report because they spread themselves neatly across twelve months – like all the really expensive things do.
And now for the uncomfortable part: most of these cases could have been resolved with a twenty-minute phone call. No training course, no process, no service contract, no project with a steering committee. Just a call where somebody asks: »What exactly happens when you press the button?« In the majority of cases, that’s enough to sort it out. That’s why I don’t see support as a cost centre, but as the most effective lever there is for reducing your returns rate. And, purely by coincidence, it’s also the cheapest.
There’s a second point that is almost always underestimated: a return is also a matter of trust. Your customer bought something, it didn’t work, they sent it back – and three weeks later the device comes back with a note saying that everything is perfectly fine. From their perspective, that note says: »It was your fault, and nobody helped you.« You can be completely right about the facts and still lose the customer. When the next rollout comes around, they won’t remember your good price; they’ll remember those three weeks. Being right and doing business are two different disciplines in our industry, and you can be a champion at one while getting relegated in the other.
What actually helps: first, an initial assessment with four questions that are always the same. Since when? Does it affect every device or just one? What changed most recently – firmware, network, location, accessories? And: does an identical device work at another workstation? Those four questions eliminate half the cases before anyone even touches a cardboard box. Second: where possible, provide a replacement device on site rather than having the faulty one sent in. Third – and this is the part that takes a bit of courage – review your own cases once a quarter and count how many were »no fault found«. The number surprises everyone. It surprised me too, back then.
I’m explicitly pointing the finger in our own direction here as well. A distributor that simply processes returns instead of trying to help first is making life too easy for itself. For the distributor, the case is neatly closed; for you, it’s a customer who now thinks badly of you. So the question to ask your supplier isn’t »How quickly do you process an RMA?«. It’s: »What do you do to make sure I don’t need one in the first place?« The answers can be remarkably revealing. So can some of the faces.
There’s a reason I’m going into so much detail here. A device that gets sent in and returned with no fault found generates no revenue, no margin and no satisfaction. It’s the only process in our entire chain where everyone involved loses – and the only one that could have been prevented by a phone call.
So remember: »The most expensive complaint is the one where it turns out there was nothing broken in the first place.«
Opinion: why I no longer send price lists as PDFs
I’ve already had my say about PowerPoint in this series, and the response was so overwhelmingly positive that I thought I’d keep going while I’ve got the wind behind...
I’ve already had my say about PowerPoint in this series, and the response was so overwhelmingly positive that I thought I’d keep going while I’ve got the wind behind me. Because there’s a second document that gets passed around our industry with exactly the same unquestioning regularity: the PDF price list. Forty pages, accurate as of some point last week, emailed once – and immortal ever thereafter. I’m convinced there are still Jarltech price lists circulating today featuring products that haven’t existed for years. Sitting somewhere on a drive, in a folder called »important«.
The problem isn’t the format. It’s the shelf life. From the second a document like that is created, it is, at best, approximately correct. Exchange rates move, manufacturers announce price adjustments, promotions end, products are phased out. Four weeks later, it’s no longer a working document; it’s a historical source. And that’s the dangerous part: on day one hundred, it looks every bit as official as it did on day one. At least a carton of milk tells you when it’s gone bad. A PDF just sits there, politely keeping quiet while you get your calculations wrong.
Let me put a figure on what that can cost you. You price up a project for 150 units based on a list that’s two price rounds out of date. The purchase price has since risen by 4 per cent, while your sales price is already in the quotation and out with the customer. At a unit price of €480, that’s just over €19 per unit, or nearly €2,900 in total – out of your margin, not the customer’s. That’s more than most companies will have given away as a discount in the same tender. At least they got a negotiated outcome in return. You got an old folder.
The second reason is even more uncomfortable: a PDF knows nothing about availability. It tells you what a device costs, but not whether it actually exists. And let’s be honest – over the past few years, the crucial question in project business has rarely been »What does it cost?«, and almost always »When can I get it?«. If you’re sitting with a customer and can immediately tell them how many units are in stock today and how many more are arriving in three weeks, you have the edge over the person who says: »I’ll check and get back to you tomorrow.« I’ve written about that sentence elsewhere on this blog. There really are some remarkably elegant ways to run yourself in circles in our business.
The alternative isn’t glamorous, which is precisely why hardly anyone talks about it: you get prices and stock levels from where they originate – live. Through your shop login, through an interface connected to your ERP system, or via a feed your system pulls automatically overnight while you’re asleep. This isn’t some digitalisation fantasy dreamed up for a consultant’s slide deck. The companies leading the way in project business have been doing it for years. Implementation takes a few days, and a single order like the one above pays for it. After that, you never again have to wonder whether the price list sitting in your folder is still correct.
And now for the awkward part, because I don’t want to be a hypocrite: we still send out price lists ourselves. Customers ask for them, and I’m not going to force anyone to change the way they work. But these days I make it clear what they contain – a snapshot, valid today, not for the rest of the quarter. If you use it to calculate a project that won’t be ordered for another six weeks, you’re taking a risk that nobody is going to take off your hands afterwards. If you use live data instead, you never have to have the conversation about renegotiating in the first place. And let’s face it, nobody enjoys having that conversation twice.
And since I’m confessing things here: I genuinely get excited about a clean interface. Sincerely. Show me prices, stock levels and order statuses flowing between two systems without anyone having to touch them, and I think that’s a beautiful thing. Probably not the most exciting passion a person can have, but I’ve seen worse. The reason behind it is nevertheless entirely practical: it’s about response time. The difference between sending a quotation in twenty minutes and sending one the following morning decides who wins the order more often than a 5 per cent difference in price – because once the customer has found the first supplier who can deliver, the decision has often already been made in their head. Everything that comes afterwards is just a comparison quote. And comparison quotes are mostly written to give the filing system something to do.
So, to finish with a completely shameless plug: at Jarltech, we have an API team that spends all day doing exactly this – bringing prices, availability, product data and order statuses directly into your system, whether that’s an ERP platform, an online shop or your own costing tool. Give them a call. The conversation costs you nothing, takes half an hour, and by the end of it you’ll know whether it makes financial sense for you. If you still want to work with PDFs afterwards, that’s absolutely fine – but at least it’ll be a conscious decision, rather than simply because nobody has ever suggested an alternative.
So remember: »A PDF tells you what a device cost last week. Your customer wants to know what it costs today – and when they can get it.«
We have been writing our own software since 1988
A few weeks ago, a specialist reseller asked me whether we could print delivery notes for his end customers with his logo, his sender details and his numbering system....
A few weeks ago, a specialist reseller asked me whether we could print delivery notes for his end customers with his logo, his sender details and his numbering system. He asked in the apologetic tone you develop when you are used to being told no to questions like that. At a distributor using off-the-shelf software, the answer would indeed have been no – or, more precisely: a ticket raised with the software provider, a place somewhere in the release schedule and an implementation date at some point next year. Our answer was: from Monday.
The reason goes back thirty-eight years and, at the time, it was not a strategy but a matter of necessity. When we started in 1988, there simply was no suitable software available to buy for what we do. We could have bought something and adapted our processes to fit it. We did the opposite and adapted the software to fit our processes. Looking back, it was the most consequential decision this company ever made, and I want to be honest: at the time, I had no idea just how significant it would prove to be.
Because a standard ERP system does something very specific to a business. It forces your own processes into a structure that somebody else designed for the average of all their customers. Every exception becomes a workaround, every workaround ends up as a separate Excel spreadsheet, and eventually half the company is working around its own software. You can spot this quite easily from the outside, incidentally: whenever you ask what should be a simple question and the answer is that unfortunately it cannot be done because the system does not allow it. No system refuses to allow anything. Nobody has written the code for it, that is all.
The second part came in 1995, although nobody called it the cloud back then. We had customers dialling into our system to see what we had in stock – at a time when the usual way to get that information was for somebody to call you back after they had checked the warehouse. The benefit was the same then as it is today: you do not ask, you see for yourself. None of this is spectacular. It is simply the difference between working and waiting.
The best way to understand why this matters is to switch sides for a moment and ask a manufacturer what they actually need from a distributor. The answer is rarely »revenue«. What they want is to know where their devices end up, promptly and in their format, not ours. They want a registered project to be genuinely protected rather than overtaken three weeks later by a list price. They want a price change made overnight to flow through every customer price list rather than ending in renegotiations. If there is a firmware problem, they want to know which serial numbers are affected – not be told that unfortunately we only track products at item level. And they want a new product to be available to order on the day it is announced, complete with all its technical specifications, rather than four weeks later when somebody somewhere has finally updated the master data.
In an off-the-shelf system, every single one of those requirements is either an expensive add-on module or a process that two people have to handle manually. For us, it is a question for our own developers. That is why manufacturers entrust us with things they would otherwise do themselves: preconfiguring entire device ranges, creating customer-specific bundles, and provisioning according to a rollout plan rather than the order in which purchases arrive. These are not standard processes, which is precisely why standard software cannot accommodate them.
For you as a reseller, the same mechanism simply works from the other direction. Your product numbers instead of ours on the order. Your price list, which your colleague also sees when they call on a Friday. Your framework agreements with call-off orders spread over several months. A live feed of stock levels and prices into your own webshop instead of a CSV file that arrives by email in the morning and is already wrong by lunchtime. Serial numbers on the delivery note so you can give your end customer documentation for their devices without having to copy them out manually. And, of course, a delivery note with your logo when we ship directly to your end customer.
Work out the value at just one of those points. A reseller manually entering two hundred orders a month instead of processing them through an interface spends, at four minutes per order, more than thirteen hours a month typing – over one hundred and fifty hours a year in which nobody is selling; somebody is simply re-entering information that was already digital in the first place. And a webshop operator whose stock data is half a day out of date will reliably sell something a few times a month that is no longer available. Each of those cancellations costs them not just the margin on the order, but the customer.
The real point, however, is that both sides are talking about the same system. The feedback the manufacturer needs and the data you want to extract are simply two ends of the same process. If you buy one system and bolt the other onto the side, you end up with two systems and an Excel spreadsheet connecting them – and that spreadsheet then has to be maintained by somebody who should really be on the phone to you.
Now for the uncomfortable part, because this approach does not come for free. If you build your own software, you bear the development costs alone – with a standard product, those costs are shared between a thousand customers. We pay for every line of code ourselves, and we also pay for every mistake ourselves. Because we do introduce bugs that would not exist in bought-in software, and when that happens there is no supplier we can point the finger at. That is uncomfortable, but it is the more honest arrangement: the people who made the mistake are also the people who fix it.
Ultimately, it is the same principle I wrote about recently. Whether a decision here takes a day or a quarter does not depend on how clever somebody is, but on how many doors stand between your question and the decision. When it comes to software, there is exactly one. That is why our answer to an unusual requirement is almost never »that can’t be done«, but »when do you need it?«
Remember: »No system refuses to allow something. Nobody has written the code for it – the only question is whether the person who can is in the same building.«