A few days ago, I argued that a company that wants to replace its old, limping systems with a brand, spanking new Oracle or SAP application should probably wait for the next generation of apps.

The post got a lot of approving comments, which surprised me. I think there are pretty good arguments for just hauling off and buying. Consider what one of these hypothetical companies might say in defense of a decision to buy now rather than later.

1. We’ve got the money now and we should spend it.

2. The product we’ll get will be much more reliable.

3. The cost of services surrounding the product will be lower.

4. We don’t know when the new products will be out (with the possible exception of Workday 10).

5. We don’t know what will be in the new product.

Imagine what idiots we’d look like, the buyer might say, if we waited for five years for a product that was no better than what we could buy today and far more incomplete and buggy.

I see the force of this, which is why I thought it was a close call. Ultimately, I did decide it’s better to wait for markedly better products that are coming, despite the risks and delays. But I saw why people would disagree.

So are my commenters intemperate or am I dithering? One test for this is to look at the case of somebody who is not considering a replacement, but is considering a fairly big investment in the existing platform. Maybe they’re considering an upgrade, or maybe they’re considering some extension products, or maybe they want to push their existing installation out to other geographies.

This is a very realistic case. Several companies I know fairly well are considering one or more of these options. One is upgrading to Oracle 11i; another wants to upgrade to Infor LN. Still another wants to extend its QAD implementation to another geography. Still another wants to buy a CRM system from its existing vendor.

For each of these companies, the details matter a lot, but on reflection, I think the same argument applies. It will be hard to get the return on this big new investment in the old platform, because the useful life of what is to you a new product is not long enough to justify the expense.

This raises two questions. First, how does one calculate “useful life.” Most of the companies I’m thinking of believe that the useful life is defined only by how long they’re willing to use it, and for some companies, that’s pretty long. (There are, after all, big SAP clients who are still using R/2.) I think this is wrong, but I’m going to have to hold off explaining why till a later blog.

The second question is, “Assuming that the commenters and I are right, what kinds of investments should companies who have decided to wait actually make?” I have no determinate answers to this, but I think there are some guidelines.

Start with Gavin’s comment on the previous post. Gavin points out that some investments in the Oracle infrastructure and in new Fusion-based products will actually take you toward the next Oracle generation. He is quite right; Oracle designed things this way, and partly because of the problem that I’m describing, they quite deliberately created some ways of investing in products from Oracle without locking yourself into an older technology.

There are many, many caveats, of course. Among other things, if you have an Oracle system now, you might not want Oracle in the future. The three main products I mentioned in the earlier post (Workday, Business by Design, and Fusion Applications) are all highly differentiated, each with its own flaws and virtues. A rational person would do well to look at all of them before deciding to stick with the vendor they have now. (This applies to SAP customers, too.)

Even if you are bent on Oracle, you still may want to take some time thinking through your infrastructure stack before investing in pieces of it. Even the examples Gavin gives like OpenID, which are likely to be pretty good, may not be right in the long run, and if they aren’t, that will be a lot of trouble and expense gone to waste.

You should note that Gavin’s argument almost certainly will apply to SAP, as well. SAP is also workng on “hybrid” intermediate solutions, and I’ll bet you dollars to donuts that they’re trying to figure out every way they can to ease the migration to the new system by asking you to make steady, rational investments in products that extend your current capabilities.

But what about customers for whom an infrastructure or extension investment isn’t right? Here, I think there are some interesting arguments, akin to Gavin’s, for small, light cloud-based apps, point solutions designed to solve highly specific problems. I’m not just talking about a CRM app or a call-center app or a recruiting app; I’m talking about things that are very, very specific to your industry, but really powerful, things like Tradestone in the apparel industry.

Another possibility is to spend some time and effort cleaning up your existing installation. This will improve its current effectiveness, extend its useful life, and very possibly lower the cost of the new system significantly. (A lot of the cost of any implementation is cleaning up after the mess left by a system that everybody has given up on.)

There’s a very smart analyst in Europe, Helmuth Gümbel, who has spent a lot of time thinking about this problem. He has a blog, and he also has a conference, Sapience, which goes into these questions at length. If you’re thinking about extending your current ERP to other geographies, a reasonable alternative might be to find lower-cost ERP systems to serve those geographies.

The basic theme running through these latter approaches is that while you’re waiting, you can focus on saving some money and preparing your current installation, thereby making the later transition to a newer technology faster and more affordable.

Advertisement

Has it ever occurred to you that software salespeople get a bad rap? In the popular imagination, they have blood dripping from their fangs. But in my experience, that’s not what they’re like at all. don’t. The ones I know are pretty decent folk, live in the suburbs, maybe even coach soccer. Not one of them would actually throw their mothers under a bus in order to get the deal. At least, I don’t think they would.

So what accounts for this reputation? Well, in the course of writing this series of blogs on brittle apps, I think I’ve come up with an answer of sorts.

Start with a fact that you should know, but maybe haven’t paid much attention to. Good software salespeople don’t sell software. They sell benefits. They don’t try to confuse you with features or functions or architecture; they try to make you understand what those things will do for you.

This is what they should be doing. After all, the buyers of software don’t really know about or understand what the features do, and they don’t have the patience to figure out exactly how the features produce the benefits. You’re a CEO or CFO, you want to get to the point. What is the value that these products deliver?

Software salespeople have developed this reputation, I think, because people have discovered or heard or found that the benefits aren’t available. And they think the salesperson knew this all along and, like some snake-oil salesman was promising a cure for cancer in order to wrest the last dollar out of some old lady’s handbag.

But in my experience, that’s not what’s going on at all. The salespeople actually have a fairly rational, if optimistic view of their product. They know that the products are designed to achieve certain benefits; they can see themselves how the design could work; and they probably know of customers who have achieved the benefits they should achieve. At worst, they’re like a Ferrari or a Jaguar salesman, who focuses on the riding experience and doesn’t feel it is incumbent upon him to bring up the repair records.

People like Dennis Moore would go even further in the software salesman’s defense, and perhaps they’re right. They would say that the salesperson is more like a good physical trainer, who can genuinely promise to get you in better shape if you’ll work out. If after you buy, you don’t want to put in what it takes to get the benefits, that’s your problem not theirs.

So is Dennis right (assuming he would agree with the words I’m putting in his mouth); when somebody buys software and underutilizes or puts it on the shelf, is it entirely their problem. Well, no. I think it would be if they realized how brittle these applications really are. But in my experience, they rarely do. They buy this Ferrari, go out on a Sunday afternoon, and only when they find themselves riding back next to the tow truck driver, do they find out what they’ve bought.

So whose problem is it? Well, I’ve already gone on too long. You’ll have to wait until the next post.

In the last few posts, I’ve been talking about “brittle” applications, applications that just don’t work unless everything goes right. We all know lots of analogues for these apps in other areas: the Ferrari that coughs and chokes if it’s not tuned once a week or the souffle that falls if you just look at it funny. But it doesn’t occur to most people that many, if not most enterprise applications fall into the same category.

They don’t realize, that is, that ordinary, run of the mill, plain-vanilla enterprise apps are kind of like Ferraris: it takes a lot to get them to do what they’re supposed to do.

Here are some examples.

Consider, for instance, the homely CRM application. Many, if not most executive users go to the trouble of buying and putting one in because they want the system to give them an actionable view of the pipeline. Valuable stuff, if you can get it. When the pipeline is down, you can lay people off or try new marketing campaigns. When it’s up, you can redeploy resources.

Unfortunately, though, it takes a lot to get a CRM system to do this. If, for instance, the pipeline data is inaccurate, it won’t be actionable. Say a mere 10% of the salesforce is so good or so recalcitrant that their pipeline data just can’t be trusted. You just won’t be able to use your system for that purpose.

It’s kind of funny, really. Giving you actionable pipeline data is a huge selling point for these CRM systems. But when was the last time you personally encountered one that was 90% accurate.

Another example I ran into recently was workforce scheduling in retail. A lot of retailers buy these things. But it’s clear from looking at them that the scheduling can be very easily blown.

Finally, take the example I talked about before, MRP. When you run that calculation, you have to get all the data right, or the MRP calculation can’t help you be responsive to demand. If even 30% of the lead times are off, you won’t be able to trust much of the run. And when was the last time more than 70% of the lead times were right.

Notice that if you underutilize a brittle system, it can be somewhat serviceable. If you use the CRM system to follow the performance of the salespeople who use it and don’t try to use the totals, the inaccuracy doesn’t matter. If you just use MRP to generate purchase requisitions, the lead times don’t matter. But, as I said in the earlier post, if you do underutilize the system, the amount of the benefit available falls precipitously. And then the whole business case that justified this purchase and all this effort just crumples.

What makes me think that a lot of enterprise applications are brittle? Well, I have a lot of practical, personal experience. But setting that to one side, it’s always seemed to me that the notion of brittle application explains a lot of data that is otherwise very puzzling.

Take for instance all the stuff that Michael Krigsman tells us about project failures. He is constantly reminding us that the cause of failure is a three-legged stool, that it could be the vendor or the consultant or the company, and he is surely right. What ought to be puzzling about this, though, is why there is no redundancy, why the efforts of one group can’t be redoubled to make up for failings in another. If the apps themselves are brittle, however, it takes all three groups working at full capacity to make the project work.

Or, more generally, look at the huge number of project failures (what’s the number, 40%, are abandoned?). Given how embarrassing and awful it is to throw away the kind of money that enterprise app projects take, you’d think that most people would declare some level of victory and go home, unless the benefit they actually got was so far from what they were hoping for that the whole effort became pointless.

How can you tell whether the enterprise app you’re looking at is brittle? Well, look at the failure rate. If companies in your industry historically report a lot of trouble getting these things to work, or if the “reference” installations that you look at have a hard time explaining how they’re getting the benefits that the salesman is promising you, it’s probably a brittle app.

Two questions remain. When do you want to bite the bullet and put in a brittle app? And why would vendors create apps that are intrinsically brittle?

Next post.

This is one of a series of posts on the high cost of buying enterprise applications and the high cost of selling the products. This high cost, I’ve been arguing, is just plain bad for both sides and almost certainly unsustainable. So the question for the analyst is, “What can be done about it?”

In the background, I’ve had a lot of discussion with industry pundits and the Twitterati: Vinnie Mirchandani, of course, and Jason Busch and @dahowlett and Brian Sommer and Dennis Moore and many others who don’t regularly comment over the airwaves. What accounts for the high cost, I’ve been asking? Two answers seem to emerge.

1. Too many cooks.

2. Too little trust.

If you’ve ever been involved in buying applications, you’ve seen the first one happen over and over again. Too many people get involved with the decision, each with their own agendas, each more or less connected to one of the contenders, and getting all these parties to agree requires too much head-banging. It’s Congress trying to pass health care, writ small, and it’s just as pathetic.

The lack of trust. Well, I get why people don’t trust, and I get why they erect structures that are supposed to control the vendor. But in my experience, it’s always been a losing game. Buyers are nowhere near as devious, oops, I mean sophisticated, as sellers–how could they be, the sellers do it for a living? So if you go into a deal, it’s natural to feel skittish, but giving in to the feeling doesn’t really protect you and does slow you down.

So what’s to be done? In the long run, you can’t do much about either problem without cooperation from the other side. If you’re going to have lots of cooks, the cost of sales for the vendor is just plain going to be astronomical, and the cost of buying will rise accordingly. If the vendor behaves in what has become the normal fashion, alas, defensive (and expensive) buying will be only too appropriate.

Granting that, you have to start somewhere, and here are some suggestions for the buyer, suggestions that should save money. All of these will really help, even though the second sounds completely ridiculous.

1. Limit the scope of what you’re buying as much as possible. Look only at what you clearly need; prefer things that you’ll use immediately; go for immediate results; and don’t buy anything else. You can always buy the rest later. (This reduces the number of cooks.)

2. Use a tape recorder and a camcorder. Keep track of what the vendor says, in full, precisely. Look the transcripts over. If you have questions or don’t understand, follow up. In the long run, it saves a lot of time. (This can help you to get more trust–kind of trust, but verify.)

3. Prototype, prototype, prototype. Get a small team to set it up and try it out, rather than assembling a large team to review demos that were set up by the vendor. If you have to pay the vendor to help you with the prototype, do it. You’ll save in the long run. (This, too, reduces the number of cooks.)

Enough from me. Suggestions from the readership are welcome.

The Oracle Quarter

June 23, 2009

I was following some Oracle deals, as their quarter closed last month, and what struck me most about some of these deals is that Oracle competitors are trying to out-Oracle Oracle–and failing.

Let me give you an example. One of the most common, best-known plays in the ERP salesperson’s playbook–the equivalent of post-right in football–is called elevating the deal.

When you elevate the deal, you try to take it out of the hands of the “team” that has been assembled to evaluate your product and put it in the hands of busy executives, preferably several levels up, who are in a position to override the team. When you’re put in front of these executives, you pitch business benefits, instead of functional capabilities, and fill their soft little heads with visions of flexibility and agility, competitive differentiators, and money dropping like rain to the bottom line. At this level, of course, you just assume that your software actually has the functionality that will allow you to gain those benefits, which is of course what that low-level team was taking all this time trying to assess.

Both Oracle and SAP are past masters of this particular play; when they run it, it’s Tom Brady to Randy Moss, man.

So this quarter, I heard about two situations where one ERP vendor tried to elevate the deal, at the express instructions of the coach, er, head of sales. In either case, was it Oracle? No, it was the other guy. And did it work? Not a bit. The only thing the competitor succeeded in doing was ticking off the selection team.

It’s a pretty small sample size, of course. But it made me wonder. I know that the applications themselves showing their age. Is it possible that the tactics that go along with those apps are beginning to fray, too? I have been saying for some time, now, that they’ve outlived their usefulness to the customer (if there ever was any). See my blog post, “Lawson’s New Office,” for instance. But now, I’m wondering, have the old sales tactics stopped working for the vendors, too?

I’d be curious to get comments on this; as I said, my sample size is too small. But assuming I’m right, there’s one other question to ask. Why has Oracle figured this out and other companies haven’t?

If so,

Lawson’s New Office

April 22, 2009

If you read this blog at all, you know that I hammer over and over again at a single theme: the middle-aged application. What is a middle-aged application? It’s one whose basic mode of interacting with data was invented almost 20 years ago. It stores data in tables; you interact with it by pushing data into those tables or taking the data out. It was a great model, 20 years ago. Today, in my view, it’s fading.

What do you do if you’re a vendor, and you have an app that was built on a paradigm invented 20 years ago? Well, one thing you can try is a new interface. That way, even though you’re still basically storing data in tables, you’re doing it in a way that’s brighter, more colorful, and possibly more useful.

Unfortunately, this is kind of an obvious idea, and the landscape of ERP systems is littered with “new” interfaces that turned out to be not so new after all. According to the vendor, every single one of these modernized the application completely. But all they really did was put lipstick on a pig–and not much lipstick on an exceptionally hairy pig.

The latest such attempt (and surely one of the most creditable) is an interface demo’ed by Lawson at its recent CUE conference. I got a chance to take a look at it (if not a look into it), and I would have liked nothing more than to say that it changes something important about the application.

Unfortunately, that’s not possible, but not for the reason you’d expect. It isn’t that I looked at it and saw, “Oh, it’s just like all the others.” It’s that Lawson made it impossible for me to tell one way or the other. This is not a good thing, of course; if Lawson really has something great, they should show it to people. But it does say something important about the software industry.

First, let me tell you what I know. Lawson told us at the conference that they’re offering two new things that might change the way users work with the application. The first is a search function, which allows you to search for records via their contents, rather than getting at them through the menu system. The idea of this is really good; if you had to name just one thing that makes the old ERP apps middle-aged, it’s the fact that you can’t Google through them in any way, shape, or form. The second is something called Smart Office, which puts a Microsoft Office-like skin on Lawson and lets you interact with Lawson through Microsoft Office products, like Excel and Outlook.

The search function is particularly exciting, because the problems with search are built into the way 20-year-old ERP systems work. ERP systems store their records in a database; to get the records out, you have to use the tools the database provides. Search isn’t one of those tools. (It is too slow.) Lawson gets around this problem by manages pushing all the records in the database out to an appliance, a separate virtual machine, and then using a tool that wouldn’t work on a database, the open source search-engine, Lucene.

From what I could tell, there are some really thoughtful things in the way they’ve implemented the search. Particularly impressive was the fact that you can search back on all the work you’ve done, which makes it easier for you to stop in the middle now, go back to something when somebody asks you about it, or correct mistakes.

Smart Office, alas, seems to be a little more ho-hum. Some of what SmartOffice does was actually built into PeopleSoft more than 10 years ago; much also looks like a knock-off of Duet, the much-vaunted SAP attempt to integrate with Microsoft Office. Still, when you take a quick look at it, it doesn’t seem too bad.

If either product had been introduced ten years ago, I think I would have left my reporting at that. Lawson had come up with something new in the interface and demo’ed it. It wasn’t really very clear exactly what. But who cares. One needed to give them the benefit of the doubt. Surely it was better than a green screen.

Ten years later, though, I don’t think that’s right (even though that’s what most of the analysts did). Ten years later, there’s been a lot of experience with “major” interface improvements, and, as I said above, it’s been a disappointing experience. Most of these improvements have been at best, an injection of Botox, doing nothing about the basic problems with an aging interface, and possibly making things worse.

What this means for Lawson is that the burden of proof has changed. If they’re going to come up with a change in the way users get at data and claim that it’s a compelling, potentially transformative difference, they’re going to have to prove it, some way or another.

Certainly, if the language of the demos is any guide, Lawson does think that they have a compelling and transformative innovation. To listen to Dean Hager, their inimitable and endlessly enthusiastic spokesman for the product, Smart Office and Enterprise Search are, at the very least, what people were offered in the movie, “Seconds,” a brand new body and hence a second life.

So did they prove it? Nope. Yes, there were a few things in the demo which were encouraging. Some of the examples of how to use Search, for instance, were pretty insightful. And while the SmartOffice demo couldn’t be made out by those of us watching on the web, some of the claims sounded good, and the customers who were video’ed were enthusiastic.

But there were also a few things that were discouraging. Since I couldn’t actually see the demos (Lawson doesn’t invite me to their user conferences, even though I don’t ask them to pay my way), I can’t point to anything concrete. But I can say that I found the fact that Smart Office is a client technology (not a thin browser technology) provided by Microsoft less than heartening. (Anybody who doesn’t understand why that’s a problem should take about a ten-second look at a phone that runs Windows Mobile, then take a 10-second look at an iPhone.) Also not so heartening was the fact that Lawson’s broadcast of the event for “remote analysts,” that is, people they don’t think are very important, was incredibly web unsavvy. (Unless you use Microsoft products, you basically can’t even get a feed.)

Add up the discouraging and encouraging, though, and do you get proof? Certainly not. Both the positives and the negatives are way too vague.

And that’s precisely the trouble. It’s 2009. People have been working on these products for 20 years. There’s a great deal known about them. And today, there’s a presumption, born of bitter history, that when a vendor announces something fabulous, but most of what the vendor says is hand-waving, that what they’ve got isn’t really that fabulous.

So what would it take for me (or any rational person) to be convinced that the latest Lawson innovation is one that matters?

Well, let me tell you, it’s not easy. Even if I had full access to this application, something that there’s not a snowball’s proverbial chance that Lawson would give me, it would probably take me a day or two–I’m not kidding–to figure out how much of an improvement it is. To see why this is, let’s just take search as an example.

Lawson says they’ve made search of an application’s records as easy as Google search and that they’ve done this, as I said above, by putting the records on a separate appliance and using an open-source search engine. Certainly, doing this solves the problem of speed, which has been a serious problem.

But the trouble is that solving the speed problem does not make the record search as easy as Google. To make it as easy as Google, there are a lot of other problems you have to solve, too.

Here are some examples. You need some way of ranking what is sent to you in a way that makes sense for your uses; otherwise, as with Google, you’ll get tens of thousands of records when you make a search, and you’ll have to page through them. And you need to solve the ontology problem, the fact that you want to include synonyms in what you found, as well as exact matches. (Sometimes, these “synonyms” are nothing more than making sure that IBM, I.B.M., and International Business Machines are all included in the search results.) You need some way to use metadata descriptions. (Can you easily–and I mean easily, easily–restrict the search to sensible populations, like AR records, or sales orders from two years ago.) And above all, you need to deal with the problem of bad data. Many of the records you’ll grab in any search are records that shouldn’t be in the system. You need some way of filtering them out.

(Enterprise applications that have been in use for any time at all have this big, smelly layer of refuse in them, just the way lakes do. On the whole, I think, the bottoms of lakes smell better. Unless carefully managed, search has a way of stirring up all that stuff on the bottom, not something you want to do.)

If an enterprise application search product doesn’t deal with those problems, well, it isn’t much good. You can say it’s as easy as Google. But when the customer uses it, they just won’t have that experience.

There are still other problems, and one of them’s a real biggie: it’s what I call the transition problem.

You see, if the search (or Smart Office) is really going to change the way people interact with this 20-year-old app, people have to use it. So, in addition to providing a brand-new very hot, ultra-cool search capability (or Smart Office capability), Lawson has to make it possible for its existing customer base to take this capability up and take it up in a way that prevents the costs from overwhelming the benefits.

This transition problem is a thorny one for all the providers of middle-aged enterprise apps; I’ve seen versions of it at SAP, Oracle, and Infor, as well as Lawson. The provider figures out some way of getting an app to sit up and sing, “Rule Brittania,” as the old phrase goes. But then they tell the users that they’ll have to go through a massive upgrade and retrain all their users in order to make the trick happen. Then they’re surprised when most users opt to dispense with any stirring displays of patriotism.

To prove that Enterprise Search or Smart Office actually does something important, it seems to me that Lawson has to tell people (you, me, the customer, etc.) in a clear, simple way just exactly what it has done to deal with all these problems, and then it needs to provide us (you, me, the customer) with enough access so that we can genuinely see for ourselves.

Has Lawson done that? Well no, of course it hasn’t. I’m sure the thought of doing something like that never even entered Dean Hager’s head.

Not only is this unfortunate, it also says something important about the enterprise application industry and about the ability of Lawson (or any of the other middle-aged app companies) to modernize. The fact that Lawson (or SAP or Oracle or any other apps company that does this) doesn’t even realize that the burden of proof is now on them shows how far behind they really are. In a way, it’s puzzling. In the era of the iPhone and FaceBook and the collapse of GM, shouldn’t any company like Lawson be worried? But the answer seems to be, “No.”

Why don’t they think so? I”m not sure. What it comes down to, I guess, is that middle-aged apps and middle-aged apps companies are a lot like middle-aged people; it seems obvious to them that they’re still young, and so they don’t realize it when people start laughing at them. They think that they can give a cute demo at a user conference, have a lot of salespeople go out and tell their customers that it’s the latest, greatest thing, and then the IT staff will put it into the plans. That’s how it was ten years ago, and that’s how it is today. After all, the customers are paying maintenance, and Lawson is taking the maintenance money and working on things that keep the product up to date. What more is wanted?

Well, what is wanted is evidence. Without that evidence, the presumption has to be that applications like Salesforce (enterprise search three or four years ago) or Workday, which uses Flash, not Microsoft, and doesn’t use a 4GL, are now carrying the innovation banner.

Of course, the middle-aged apps vendors are unconvinced, just as all middle-aged employees are. We have the experience, they say; we have the know-how; we have the functionality; see, we can still dance a jig.

They say it, but in my view, they are wrong. Viewed by anybody who uses an iPhone every day, these apps just don’t work all that well any more, relative to how much they cost. They badly need to be brought up to speed. Ten years ago, we could assume that the companies were trying to keep up and we could accept mere assurance. But ten years later, that is no longer enough.

Yes, it may take the customers longer to figure this out than it does the analysts. But eventually, even the most ardent fan realizes that Elizabeth Taylor weighs a little more than she used to.

Try It!

March 18, 2009

Here’s a radical idea for you. Don’t buy it without trying it. I repeat. Don’t buy it without trying it.

It? What? A car or an iPod, right? No, I mean an enterprise-level application. If you can’t get a copy and set it up, don’t buy it. And I don’t mean a limited-functionality demo or a look-and-feel demo or maybe a video of the application. I mean try it and see if you like it.

I know. That’s impossible, right? Any vendor will tell you so. No human being can just get a copy of an app, install it, set up the data, and see whether it will work for them. It’s too difficult. It’s too complicated. It takes too long. It requires too much expertise. You need too much help. It would be a support nightmare. It’s completely impractical. It’s pointless.

I’ve heard all these things from the vendors. And they must be right, right?

Oh yes, I forgot all the things they don’t say. It would be too discouraging; the buyer hate the software. The buyer would screw up the implementation and then blame the vendor. The buyer would find problems and insist on their being fixed before he bought. The buyer might even compare capabilities with another vendor’s and use the comparison to drive down the price.

Or the biggest nightmare of all. The competitors get hold of the software, distort, exaggerate, and lie about what they found, and convince an all-too-gullible customer not to buy us and buy them again.

Such bad behavior. What vendor would even imagine this kind of thing?

All wrong. Every bit of it, at least from the customers’ point of view. It is possible to set up a company fairly quickly. And if you can’t, that’s a problem. If you don’t like it, that’s a problem. If something doesn’t work, that’s a problem. If it does something worse than some competitor, that’s a problem. It’s the kind of problem that you should find before you buy.

So try it. And if they won’t let you. Go somewhere else.

But oh, before you do, let me know who it was. And I’ll post the list here.