Writing

Software, technology, sysadmin war stories, and more. Feed
Friday, February 8, 2013

"Downselling" bad products

I imagine the concept of "upselling" is familiar to most people. If not, the basics are simple enough. Imagine you go into Target to buy the newest and shiniest game console which just came out. While you're there, the guy behind the counter informs you that there are prepaid value cards you can get to make it easier to buy things online later. This way you don't need to key your credit card info into your game console by virtually pointing at a keyboard on your TV set.

I had that happen when I bought my Wii U last fall. I was going to buy some credits to allow for purchasing things online anyway, so I went ahead and got the card while I was there. I knew exactly what was going on, and the guy probably got a little bonus for it, so I just said "hey, good upsell". He smiled and that was that.

There is an alternative concept, though. I called it "downselling". It's when I would purposely steer a customer away from a paid product in order to prevent badness down the road. It was basically my way of taking control of the "buckets of money" problem when Product pushed out something horrible.

One of my favorite things to "downsell" was a webmail product called Emumail. It was never that good in the first place, and then it just sort of stagnated while the world moved on. It was basically a server-side IMAP/POP client with a web interface. The IMAP side of it would frequently crash. If you set up a test account and accidentally let it use POP3, then it would just work and it would seem like nothing was wrong.

It would "figure out" your server name based on how you logged in. If you just said a username and not a full user@domain type thing, it would usually pick up the mail server ID as a default. The mail server ID was "localhost" in many cases, so if you sent mail, it would go out as "username@localhost", and that's not valid. You could hard-code the default to something else, but all of the existing accounts would still have bad values. All of those accounts had to be fixed by hand.

I seem to recall it also had its own little web server binary on port 1010, so you had to be library-compatible with the httpd in the package provided. Once Red Hat got up to RHEL ES 3, some libraries no longer existed and it wouldn't just run out of the box. ES 3 and Emumail were thus an unsupported combination, but occasionally Sales would sell them together. Then we'd get stuck with it in support.

Some of us in support decided it would be better to just get customers away from this thing. Most of the customers didn't have any particular attachment to Emumail and would have been fine with Squirrelmail which was a trivial thing to install and keep running by comparison. Besides that, RHEL ES 3 actually came with Squirrelmail installed by default, so newer machines already had it there. We just needed to turn it on and turn the customers loose on it.

As a result, I took pride in "downselling" Emumail. I'd set the customer up with something free which did a much better job and didn't create nearly as many intractable support issues. Squirrelmail and Horde/IMP problems, no matter how bad they got, always had a solution. Even simple Emumail tickets usually boiled down to "we can't do anything about it" or "it does that" (argh!), and that drove some of us nuts. Some of them would stick around in the queue as "pending vendor" for months. Then the customer would close them as "unsatisfactory".

It might have resulted in churn on the books for a loss of monthly revenue, but I didn't care. The lower number of support tickets and overall tech stress was worth it. Nobody really put a price on our sanity, because if they had, it would have been an obvious decision.

I should point out that we didn't do this in secret. We kept trying to get them to kill certain evil products which were pointless. We'd even go and talk to individual sales people to get them to stop trying to sell that. The bad experience customers got from having it installed for a day or two (that's about how long it lasted) didn't do us any favors as a company.

It wasn't the first time one of us had purposely dropped a few bucks of revenue short-term to make things better in the long run, and it wouldn't be the last.

There are people inside some service organizations who care about you more than every last dollar and cent. Just hope you can find them if you should ever find yourself in one of these sticky situations.

For some reason, folks like this aren't always that popular with management inside a company. I wonder why.