The 5 Golden Rules of Giving Awesome Customer Support

This is usually a tech blog, but every now and then, we make an exception when there’s something important to say.

Today, I’m going to criticise a lot of our industry’s understanding of support.

Who is this article for?

It’s for every software engineer giving support to users and/or customers, and every manager who works with software engineers. In fact, it isn’t restricted to software, but since this is a Java blog, let’s pretend it is only about software.

#1: All users are customers

While we’re at it, let’s use the terms “users” and “customers” as synonyms, because every user should be treated like a paying customer. In fact, every user should be treated like the only paying customer you have, on which your whole business depends. This is why I will put “customer” in quotes in this article.

This is something you should constantly remind yourself of. It doesn’t matter if your “customer” paid you millions for your software, or if they just use your quick and dirty Open Source library that you implemented in your free time.

Why is that? Because it’s your fault and problem as a vendor if you chose some business model (or if you don’t even have a business model) that generates (excessive?) support work. Change the model. Make more non-paying “customers” pay for support. Help them understand the value they’re getting from being your paying customers. Or keep doing stuff for free, it doesn’t matter as long as you will remember that it’s your problem, not theirs.

Always take Apple as a shining example. Apple customers love to pay excessive amounts for average hardware and software with nice-looking design. This has nothing to do with support, it just shows that Apple has gotten making customers pay right. Because Apple users want to be paying customers.

#2: Your customer took the time

Remember this:

Your “customer” took the time to report an issue.

Period. That’s all there is to say. When a “customer” gets in touch with you, they took the time to get in touch. So you should be thankful they took the time. Not all “customers” take the time. Most of them just rant and leave you silently if something goes wrong. Or worse, they rant in public and then leave you.

If a “customer” does take the time, this means they stand for thousands of others who don’t take the time but like your product and want to continue liking it. Don’t spoil that. Keep those customers!

#3: Your customer is abrasive and demanding

The food chain goes this way round. Accept that. Moreover, remember: You’re not some divine entity that grants an audience to an unworthy soul who should kneel before thy wisdom. You’re the supplier. They’re the customer. They’re the king. You’re the servant.

Of course they are abrasive and demanding. They are the “customer”. They had a bad day. They have an idiot boss. Their job sucks. They work on legacy code. They blame you (and everyone else). It’s not their fault. It never was.

So what? That happens from time to time. More often than not, however, “customers” are nice people, and again: They took the time to get in touch.

So, your job is to thank them for that. To make sure you do everything needed to help them. To solve their trouble and issues. Which often isn’t what they’re saying. They just want you to listen. A workaround might just be enough. They’ll understand you can’t fix things immediately. But do help them.

#4: Your customer doesn’t understand your product

You’ve spent all that time with your product. You know exactly how it works. You have accepted all the caveats. The bugs. The workarounds.

Your customer doesn’t. They have more important things to do than reverse engineer your funky product. If they don’t understand something, always assume it’s your fault. You could improve the product. Or the documentation. Or your SEO to make sure they will find the documentation. Or your support channels (see below). Whatever. Always assume that your “customer” doesn’t have the time to really understand your product. Why should they.

Learn from your “customers”. Their misunderstanding of your ways is your chance to do it better. Every single time.

#5: Your customer doesn’t care about your workflows

And here’s the one thing you must never, NEVER do:

NEVER tell your “customer” that they’ve used the wrong support channel

NEVER do the above. They’ll learn by themselves after a while. Or they don’t. Does it matter? It doesn’t. They’ve taken the time to reach out and that ought to be enough.

Perhaps, you’ve chosen a confusing setup of support channels. Or complicated products (looking at you, Bugzilla). Improve it, then. Make it easier for your “customers” to choose the right support channel if they have gotten it “wrong”.

What does wrong support channel even mean? Wrong support channels create administrative work to you. You have to copy a bug report from Google Groups to JIRA. From your E-Mail program to GitHub. Etc.

So, a “customer” has reported a bug on the discussion group. You prefer they create an issue in an issue tracker. How do you react?

  • Bad: This is a bug not a discussion, we have a bug tracker for this. Can you please create an issue??!?
  • Good: Thank you very much for bringing this to our attention. I have registered an issue #717863 for this problem. We’re looking into this as quickly as possible and let you know about our progress. If there’s anything … blah blah.

As simple as that.

Conclusion

There are many more things that help you get support right. And it isn’t always easy. Sometimes, it’s just too hard to get it right. We all have tons of things to do. And priorities.

But remember one thing. This is (almost) never the “customer”‘s fault. And even if it is, you should never make them feel as if it were. There are enough enterprise-y companies out there whose processes are too complex and heavy to ever give awesome support.

Don’t be like those companies. Be awesome for your “customers”.

Open Source Doesn’t Need More Support. It Needs Better Business Models

Jamie Allen, Typesafe‘s Director of Global Services published an interesting point of view on Twitter:

And he’s right of course. We are constantly reminded of the fact that we should support FOSS projects on which we depend. Just recently, Wikipedia had this huge banner on top of it, asking for money, and we probably should. But do we really depend on them, and can we really make a difference? Let us look at the problem from a business perspective.

There isn’t a second Red Hat

About a year ago, there was an extremely interesting article on Tech Crunch by Peter Levine, partner at Andreessen Horowitz who have just invested $40M in Stack Exchange. The article was about Why There Will Never Be Another RedHat: The Economics Of Open Source. It compared Red Hat’s and VMWare’s market capitalisation and revenue with that of Microsoft, Oracle, or Amazon, showing that even Red Hat is a rather insignificant competitor in terms of these size metrics.

Why is this so?

Let’s go back to Groovy: There are probably tens of thousands of Groovy developers out there who have simply downloaded Groovy and then never again interacted with the vendor. It probably wouldn’t even be wrong to say that many developers weren’t aware of Pivotal having been the main sponsor behind Groovy. Sure, Groovy is a strong brand, but it is really “everybody’s brand”, and thus: nobody’s brand. Not being a strong brand, it attracted only techies with language interests (and it is a beautiful language to work with, indeed!)

Now, Pivotal has withdrawn their engagement from Groovy, for completely understandable reasons. Let’s review Jamie’s point of view:

Pivotal’s move to end support of Groovy is a stark reminder that enterprises who depend on FOSS projects should help support them.

Would it have mattered if “we” had supported Groovy?

Perhaps. A Groovy Foundation (similar to the Apache Foundation, or the Eclipse Foundation) might have made Groovy a bit less dependent on Pivotal, and this can still happen. Possibly, a couple of larger companies who depend on Groovy, or Gradle might chime in and become Silver or Gold or Platinum Sponsors, or something like that. Perhaps, Gradleware will seize the opportunity and “buy” Groovy to become THE Groovy company.

But will it work? Does the same work for Typesafe? Can monetising an Open Source language and platform work in times when even C# is now given away for free?

Red Hat can make money off Linux, because Linux is a very complex ecosystem that just requires a support subscription when you’re running it in production. No bank on this planet will ever run a server farm without the vendor promising 24h support with under 1h reaction time. But is the same true for Scala, Groovy? The “critical” work has long been done by the developers. The binaries are built and shipped onto production where operations takes over. Operations couldn’t care less if that binary is built with Groovy, Scala, Java, Ceylon, Kotlin, Fantom, or any of the other gazillion Java alternatives. All operations will ever care about is the JVM, or Weblogic – and the database, of course. And operations is where the long-term subscription money is, not development.

This doesn’t mean that no one should make money from developers. Companies like JetBrains, ZeroTurnaround, or also ourselves, Data Geekery show that it works, on a much smaller scale. But if a company is “selling” a programming language that doesn’t immediately help them upsell their customers to buy their significant other subscriptions, you should be wary as the vendor motivation to produce the programming language product is very unclear – and in the case of Pivotal, “unclear” is not even close to describe the vendor motivation.

Good examples of holistic platform strategies are these, because operations and the end user can immediately drive the decision chain that justifies the language lock-in for the developers:

  • C# -> Visual Studio -> SQL Server -> Azure, etc.
  • Java -> JVM / Weblogic -> Oracle Database -> Oracle Commerce, etc.

OK examples are these, although the upselling potential might not be viable enough to maintain a whole ecosystem. We’ll see how it works:

  • Kotlin -> IntelliJ

Less good examples are these, because the value proposition chain is really not obvious. There is no justification for the language lock-in:

  • Groovy -> Cloud Platform ??
  • Scala -> Reactive Programming ??
  • Ceylon -> RHEL ??

The Business Model

Jamie Allen’s Tweet shows a lot about what’s wrong with many Open Source vendors. While he claims that end users depend on OSS products from their vendors, the opposite is true. The end user can simply fork the OSS product and lead it to a graceful end of life before replacing it. But the vendor really depends on the goodwill and the benevolence of their FOSS communities. The vendor then tries to leverage goodwill to make a weird-sounding upselling between completely unrelated products. This cannot work.

So join us in our endeavours. Make Open Source a business. A viable business, a business driven by the vendor (and by the market, of course). A business that makes sense. A business that involves dual-licensing and reasonable upselling. A business that uses Open Source mainly as a freemium entry point for the actual business.

You can be romantic about F(L)OSS in your heart, that’s OK. But please don’t depend on it. It would be too bad if you don’t succeed, just because you ran out of money from your “sponsors”, because you didn’t care about the business aspect of your product.

Read also 5 lessons for any open source business transitioning to a revenue-based model

Suis-je Groovy? No! What Pivotal’s Decision Means for Open Source Software

Today there was great news in the JVM ecosystem.

Pivotal, the company who is committed to OSS has become a bit less committed:

committed

The reaction in the community were largely summarised by the hashtag #jesuisgroovy:

The interesting part in Pivotal’s announcement is this one:

The decision to conclude its sponsorship of Groovy and Grails is part of Pivotal’s larger strategy to concentrate resources on accelerating both commercial and open source projects that support its growing traction in Platform-as-a-Service, Data, and Agile development. Pivotal has determined that the time is right to let further development of Groovy and Grails be led by other interested parties in the open source community who can best serve the goals of those projects.

The official announcement can be read here.

Groovy is not a viable business (for Pivotal)

In other words, Groovy is not a viable business for Pivotal. And it’s hard to disagree here. Groovy has never been created with any commercial interests. Like many Open Source projects, Groovy was created in order to make something “better”, mostly for the sake of it being better. Of course it was useful as it introduced a lot of nice features into the Java ecosystem at a time before all these new JVM languages popped up. And before all these new JVM languages finally had an effect on Java-the-language itself.

On the other hand, the Groovy website’s rather geeky look-and-feel has never made it seem as though virtually anyone had any commercial interests in the language or the platform for that matter. I’m not trying to be harsh here, Groovy is an awesome language, created with love. But maintaining an Open Source ecosystem is hard work. It costs a lot of money and effort. And in the case of Groovy, it is just very hard to disagree with the fact that there is probably little money to be made out of it.

How to make money out of Open Source

When we moved on from a purely Open Source jOOQ to a dual-licensed one, we were criticised a lot by people who realised that they might fall into the dual-licensing category who no longer gets to ride for free. This was of course a disappointing evolution for those people. We see it as one step forward for a product that doesn’t just want to implement l’art pour l’art. We believe that we’re adding value on a small scale to a select set of customers with real SQL problems, and we want to continue to do so. Thus, commercial interests are now the driving force behind our developments, and dual-licensing is the easiest way to achieve that on our own small scale.

Many of those who had criticised us claimed that we should create a support-based Open Source business model instead (like Pivotal!). In other words: Let “them” pay for support – whoever “they” are. But that is not a viable model in the long run.

We create fishing poles. We don’t want to compete with our customers, the fishermen.

In software, the vendor of some product shouldn’t commoditize the main driver for innovation: The product. They should sell the product and create an ecosystem and a market for consultants that will be much better at applying the product to some concrete customer’s business. It is a win-win-win situation for everyone:

  • Vendors get money from licenses
  • Consultants get money from their specialist knowledge
  • End-users get a better, cheaper solution with a lower cost of ownership

Although, the consultant is always the one whose work is commoditized in the long run as demand for the product increases, and more consultants pop up trying to make money from their consulting business.

Joel Spolsky has written an extremely interesting Strategy Letter on the idea of commoditizing a complementary product (support, in this case) to increase the demand for the primary product (license, in this case). In the case of a PaaS company like Pivotal, however, we can only guess that even the commoditization of a whole programming language and ecosystem is no longer sustainable enough to increase demand for their PaaS offerings.

If that is the truth, then other platforms like Spring are at the stake as well! If Groovy is not sustainable, why should Spring be?

Am I Groovy?

Suis-je Groovy? To get back to the original claim:

No, I’m not Groovy. Groovy and every other piece of Open Source software that does not in any direct way produce a commercial value for both the vendor and the consumer is doomed to fail in the long run. Open Source software has created a tremendous amount of value in our industry. Companies like ourselves wouldn’t be possible if we’d still pay millions for an operating system license. The question is not whether software is free as in beer or as in freedom. The question is whether anyone has any viable commercial interests in making a particular software element cheap or even free. If they don’t, well, the joke will be on you as the vendor might just stop doing it. Open Source or not.

Modern Shareholder Value Hopes

So, everyone is discussing the $19B Facebook / Whatsapp deal, discussing it on every media. And Zuck says it was actually a bargain.

Yeah right. A bargain. Read CNN’s 10 other things Facebook could have bought with $19 billion.

We at Data Geekery are more down to earth, selling actual value to our own customers. So we take the opportunity to issue this friendly reminder about what happens when you and your shareholders believe that a primitive chat service is worth $19B because of its oh-so-many users:

So, should our own business not work out, we can still make tons of money this year through PUT warrants on FB. Because the above is not the only issue with Facebook. Check out this video:

On Degrading Merchandise Quality

I’ve just replaced 4 halogen bulbs in my appartment. When I threw the old ones into our recycling bin, I’ve noticed that there were already around 8 bulbs in there. From the last 5-6 months, only! This made me sad, as it shows how our consumer society works. Read on to learn how jOOQ strives to be different with respect to endurability and long-lasting quality.

More stuff I’m made to buy because it falls apart

I’ve just bought a new mobile phone, because the old one didn’t really work anymore, after only 2 years!

I’ll be buying a new hard drive next week, because the one I’ve bought recently (to replace a broken, 3 year old one) heats up too quickly and doesn’t give me the throughput I want!

I buy 2 pairs of new Adidas a year, because they don’t last as long as my leather shoes!

I buy about 5 mini-umbrellas a year, because apparently, they’re made to last a mere 10 days of rainfall!

I buy about 2 new city bikes a year, because mending them is more expensive than buying new ones. It’s not that I’d just have to replace tires, they’re actually quite broken after 1/2 year!

I bought a Windows Surface RT tablet just to learn that almost no programs can run on it. I would have had to buy the Pro version and throw the old one away.

Should we really work this way?

I’m forced to buy new stuff. I buy new stuff because the previous stuff I’ve had breaks apart so quickly. And in many cases, it is very clear that it has been designed to break apart in a short period of time. Replacing things with new things is an industry of its own. If stuff were made to last and to work for 10 years (Hah 10 years. Our grandparents used the same stuff for 40 years!), corporations would make less money with new merchandise to replace their previous equivalent merchandise. Take my awesome Samsung flat screen TV, for instance. I had bought it around 7 year ago, and it still works like a charm. Samsung never got any money from me again, even if I’m a very happy customer. Is that a bad business plan for Samsung?

There’s more to life than making tons of money and keeping a paying customer base for your deliberately mediocre product line. There is a strong urge to contribute to making this world a better place. By selling quality products that do not fall apart very quickly. Products that do not require a lot of support. Products that are easy to use and long-lasting, such that the return on investment for your customer is extremely high, at the cost of making “only” a living instead of tons of money and waste.

At Data Geekery, producing such products is our highest credo. This is why we charge a bit of money for licensing with support included, because we think that our quality is so high, you might not even need any support. We could make a lot more money by lowering our quality and by hiring a lot of expensive consultants to explain to you how our complicated product works. But jOOQ is not complicated, it is extremely easy to use.

Many “free” Open Source products don’t work this way. They lure you in by being free and LGPL-licensed, unloading a lot of consulting and maintenance costs onto you only later on. It is your choice. Do you want to invest in your future by keeping maintenance costs low? Or do you want to get a cheap product and pay later on? Think about dirt cheap ink jet printers and how much you’ll pay on those quickly-emptying ink-cartridges later on. Think about dirt cheap coffee machines and how much you’ll pay on those capsules later on. Think about some computer products, and how often you have to pay for ridiculous updates, because the “old” minor release of the operating system is no longer supported.

Don’t think in short terms. Don’t fall for “free” stuff. There is no such thing as free lunch. You always pay. A little bit now, or much more later.

On MongoDB’s Success. Or Do Not Let Cynicism Kill Your Spirit

Success is a strange beast. On the bright side and true to entrepreneurial spirit, people admire those who are obviously successful. In the theory of our mostly capitalist societey, successful people worked hard for their success, and thus deserve it. In practice, there may be other mechanisms of success than working hard, but that’s another story which is quite off-topic on this blog.

MongoDB is successful. Extremely successful, as they have just raised $150M from a venture-funding round. They must be doing something right, at least from a marketing and sales perspective. As I admire this success, and as I am hoping to be similarly successful with jOOQ, I wanted to throw in the story at reddit for discussion. I’m curious what other business-oriented people think of this. But as always, when talking about MongoDB, cynicism arose. Heavily. See the following examples

Cynicism about the tech quality

Cynicism on the tech quality

Cynicism about the tech quality

Cynicism about getting rich

Cynicism about getting rich

Cynicism about getting rich

This was really disappointing to me. Is this just reddit being full of trolls? Or are people heavily envious if someone stands out and is successful? You may think about MongoDB whatever you want. But there is no doubt that this valuation and venture-funding round is a proof of MongoDB’s continuous success over the past years. Apparently, they are responding to a real market value with real market expectations. Raising this money will hopefully help them meet those expectations even more, in the future.

Do not let cynicism kill your spirit

No matter if this is just reddit or the “IT community” in general, it is not worth delving into such cynical discussions. I congratulate 10gen for being the only NoSQL database vendor in the DBMS popularity ranking that I’ve previously posted:

DBMS ranking. Reproduced with permission of DB-Engines.com

DBMS ranking. Reproduced with permission of DB-Engines.com

And I most certainly congratulate 10gen to this incredible milestone in their company history.