Ask HN: How do you handle account sharing on per-seat priced products?

9 points by throwaway_19393 8y ago ↗ HN

We operate a service operating on a per-seat license. We've found a lot of accounts which are sharing users. The other user is signed out immediately, which degrades our perceived quality of service. The problem with measuring sign-in metrics and raising flags is we only allow a user to be signed into either mobile or desktop at once to avoid even more excessive account sharing.

Is our pricing model broken? Are there any user-friendly and revenue-friendly solutions or are these mutually exclusive territories? Is this none of our concern, e.g. "They paid for seats and they never use more than those seats."?

Thanks!

3 comments

[ 483 ms ] story [ 505 ms ] thread

GrumpyNl 8y ago ↗

Ask your users if a different price plan would motivate them to register more seats.

patio11 8y ago ↗

we only allow a user to be signed into either mobile or desktop at once to avoid even more excessive account sharing.

I would perceive this to be hard broken if that happened to software which I or my employer was legitimately paying for.

Why don't you talk to users and figure out why the account sharing happens? Is it because they don't want to pay for more seats or is it organic behavior caused by the difficulty of the end-user _actually purchasing_ more seats, given how software is bought in their organization?

If you're going to log someone out, let _both_ sessions know that. "You've been signed out since you just signed in on Chrome from 123.45.XXX.XXX. Was this surprising to you? Click here to bug your account owner to purchase additional seats." (adjust copy to taste)

"Since you signed in, we automatically signed out your existing session on Firefox at 123.45.XXX.XXX."

(If you want to be really sneaky about it, open a chat window between the two sessions and give them ~90 seconds to come to an agreement about which should be signed out ;) Your desired outcome there is one of them says "Gah, boss, James signed me out again when I was filing TPS reports. I can't work in this environment! Figure it out!" or "Memo to all hands: if you kick our CFO out of a screen sharing session with the auditors again, update your resume.")

More broadly, I would generally suggest selling buckets of seats rather than strictly per-seat unless you're absolutely constrained by your market or your customers' headcount costs model (like e.g. CRM for sales reps or ticketing system for support agents, respectively). This makes it easier to add new users to the system most of the time, which is something you want to encourage. I'd also encourage you to look at how Slack does seat-counting; it's elegant, is user-friendly, and puts as few roadblocks as possible to capturing the business of everyone in the organization. (I bet their terms are different for true enterprise deals, though.)

P.S. If this isn't a huge issue for you I'd generally suggest removing the restrictions and ignoring it; there are likely higher points of leverage in the business. Stats will be your guide.

conductr 8y ago ↗

Sounds like you've identified the "offenders", could you just reach out and ask them why they're doing this? Obviously do so in a way that you're not threatening them (discontinue service) or accusing them of cheating (they may not be doing it on purpose). Do this and I'm sure you will hear some common themes. Then you will have the right data to adjust your pricing model, or not - you might just conclude that it's worth leaving the pricing model alone because of the value of the users to adhere correctly, and just allow some level of users to abuse it - because they might not/would not pay full price (I'm assuming you're margins still allow you to make money on these users).

I personally have see what you're talking about. And, I'm not a big fan of per-user pricing as a consumer. Because it creates silos where only Bill can login to get that info... But Bill's on vacation today... do we need to pay for another seat all year long just so we have a backup plan for when Bill is on vacation. So with that, my guess is they don't feel it's worth paying full per-user pricing for users that only login periodically. Or, the total price gets higher than they value your service (eg. I don't mind paying $100/m for your thing, but I have a team of 20 and your $19/user pricing doesn't jive with the value I think your product delivers, so I might be inclined to find a way around it). It might also be that most of the users are casual users and they only have one power user. You might need to consider creating different user classifications with pricing that reflects (eg. admin = $100/m, generic = $10/m); but this will complicate your product not just your pricing model.

I don't know anything about your product. But, consider fixed pricing / annual pricing. People fundamentally think about these differently. Selling a solution for $1200 for the year may be easier than $100 per month. Also if it suits your business, you could set pricing based on volume usage. More users probably correlate to more volume of use and it will remain revenue friendly. In this way, it become more "fair" for the companies who have 1 seat but use the product heavily.

Not sure anyone can really answer this for you but I hope this helps give you some ideas!