The Software Strip Club Model
You can look but you can’t touch
You read that right. I somehow made the connection between strip clubs and software. Believe it or not, this concept can help users use your application for longer, which can translate to more ad revenue, better metrics to show the higher ups and more purchases (if your software does that sort of thing).
The Origin Story
I’m leading the development of a live auctioning software alongside three other developers. We’re releasing it in an area of the world that isn’t accustomed to auctioning software and online purchases in general; so we realized that a vital barrier to entry to overcome is users’ apprehension of online payments. The question was: “How do we get users to start bidding?”.
After some market research and many internal conversations, we decided that we would not require a users payment information for the first product they bid on. The rationale behind this is that the initial boost in engagement and bids will offset the cost of those who win the auctions but choose not to pay. But what do we do to these bad customers?
Well, clearly for one they will obviously not receive the product they bid on, that’s a given. But then what?
Ban Them?
One approach that was suggested is to ban the user permanently. They signed up and verified using their phone number, so they won’t be able to create other accounts with the same information. But we decided not to go with this because it flushes future business opportunities down the drain.
Just because a user didn’t complete the payment once does not mean that will happen again. If anything, we know that the bidding user is an interested user who has gotten a taste of the system. The question becomes: How are we going to capitalize on this?
The Strip Club Model
Instead of banning them, we put a temporary hold on the product for X amount of days or until they pay, and have an attention-grabbing, attractive, non-dismissible banner at the top of the site showing them the product they can have if only they do the small step of inputting some information. Not only that, but we continue to allow them to browse products, we even make sure the bid button is enabled for them. And here it comes, the “You can look but you can’t touch” moment: As soon as they try to place a bid, they get a pop up dialog that asks for their payment information. They cannot bid until they input it.
The whole concept is to make the user feel like they can have it all. The product they initially wanted and ended up not paying for is one they already expressed interest in, and it’s right there in their face as long as they’re on the site. As they browse they don’t see a bunch of discouraging disabled buttons that take bidding out of the question, instead that possibility is always there and encouraged.
If we can get them to click on the bid button, then we’ve already provided them with the initial excitement of starting a bidding war. Given they’re excited to bid, we hope that makes it more likely for them to input the payment information as they encounter it immediately after pressing the button. They want their excitement to translate into willingness to pay.
By keeping them around instead of banning them, the worst case scenario is we keep them as a future potential customer. Best case scenario is they become avid users of the site and influence others to do the same.
