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 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.«
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.«
Why we build our own AI
At the moment, everyone is sticking the word AI on their website, and the most honest test is always the same question: what difference does it make to you?...
At the moment, everyone is sticking the word AI on their website, and the most honest test is always the same question: what difference does it make to you? If a supplier tells you they are now using artificial intelligence and you notice no difference in your day-to-day dealings with them, then it was not an investment; it was a press release. So I am not even going to try to explain what this technology can do in general. I am going to tell you what you get out of it – and where we deliberately do not allow it to make decisions.
Let’s start with the obvious point, although most companies do it differently: we have not simply taken out a subscription somewhere and put our logo on it. Our systems run on our own computers, using our own data. That is more expensive and takes longer, and there is exactly one reason for doing it – but it is reason enough: your order history, your projects and your terms are nobody else’s business. Anyone who pours that data into somebody else’s service just to make the answers sound nicer is trading their customers’ business secrets for convenience. Your trust is worth too much to me for that kind of trade-off.
What you notice as a result is unspectacular, and that is precisely why it is valuable. The colleague responsible for your area has your history to hand when you call, instead of having to piece it together by asking three different people. Questions that used to be answered with »I’ll check and get back to you tomorrow« can now be answered during the same conversation. And if a manufacturer pushes back a delivery date, we do not find out when the goods fail to arrive; we know when the change happens – which, in turn, can save the week in which you need to make a commitment to your end customer.
The commercial principle behind all this comes down to a sentence I have written many times before: in this business, it is rarely price that makes the difference; it is almost always time. A project involving forty devices where two queries each cost you a day is not simply two days slower. It is lost if someone else has submitted their quotation in the meantime. Every hour between your question and a reliable answer is not a minor service detail; it affects your success rate.
And now for the part hardly anyone writes about in this context: this technology makes things up. It does not do so only occasionally, nor is it obvious when it happens. It does it confidently, in complete sentences and with a level of certainty that no human being in the same situation would ever display. Anyone who fails to take that into account is automating their mistakes rather than their work. That is why, at Jarltech, no machine decides on a price, makes a commitment on availability or sets a credit limit. It prepares, sorts and reminds. A human being makes the decision – and specifically one you can call and who takes responsibility for it.
The fact that we can build it this way has little to do with technology and a great deal to do with ownership. An investment that will not pay for itself for at least three years does not have to be justified here to a committee whose performance is measured by the quarter. It is the same decision we made with our own software back in 1988: more expensive at the beginning, independent in the long run. Back then, I had no idea just how much that decision would pay off, and today I still do not know which parts of what we are building now will prove to be the right ones five years from now.
What I do know is this: if you ever get the impression that you are talking to a machine rather than a person when you deal with us, then we have got it wrong – and I want you to tell me. The technology should make more time for conversation, not make conversation unnecessary.
Remember: »A machine that tells you something wrong more quickly is not progress. Progress is when a human being knows the right answer more quickly.«