Upsell, High Use and Abuse Limits
Services have various limits. They fall into different types, which should be treated differently:
1) Upsell Limits: These are put in place to encourage users to pay. For example, MockFlow is a prototyping tool that’s free to get started with, and the payment prompt came only when I tried to create a fourth screen in the prototype. By then, I already learnt how to use the tool and was impressed by how fast it was to get things done, so I paid. If the prompt appeared when I created the second screen, I wouldn’t have been impressed and so paid. If the prompt appeared when I tried to create the thirtieth screen, MockFlow would have lost a lot of revenue. These are the kinds of factors that determine when to upsell. It depends on psychology, competitive dynamics, and a lot of other factors that require iteration and A/B testing to figure out. Upsell limits should be under the control of the Product Manager, not the Engineering team.
2) High Use Limits: These are often put in place to prevent some customers from destabilising the system or using too many resources. But that’s the wrong way of thinking about it. The right way is to permit customers to use whatever they want to, and charge them for it. For example, Google Drive lets me store 20 terabytes of data. I just have to pay for it. It’s a paternalistic attitude to say what people should use. If I go to a restaurant every day, they don’t accuse me of eating too much of their food. If I fly every week, the airline doesn’t feel I’m wasting their fuel. They’re happy to have more business. If you’re incurring a lot of cost for certain customers that doesn’t match the fee they’re paying, to the extent that it’s a problem for the company as a whole 1, then the problem is with your pricing. It’s not capturing enough of the value customers are getting. In fact, you should want people to use your service more and more, so that you can bill proportionately more. This is where the idea of consumption-based pricing comes in. If I was offering a chat API as a service, I’d charge per concurrent user 2. Off-peak usage will be free, with unlimited MAUs, because costs are driven by peak usage, not total usage. This will also let me stand out from my competitors who charge for MAUs.
3) Abuse Limits: Abuse is when a user makes things bad for other users, like spam. Or when you can identify no possible reason for a user to do something, like creating 1000 events per day in a calendar. But when in doubt, err on the user’s side. People often use products in ways not expected by their creators, and that’s totally fine.
In summary, upsell limits should be decided by the PM, and high use and abuse limits, by the eng team. The last two should not be documented on the site, since the engineering team should have the flexibility to change these as needed to keep the service stable. And avoid high use limits.
If not, don’t obsess about it and take petty actions like complicating your pricing to catch one company that’s slipping through the cracks. Or, worse, just calling them up and asking for more money than your own web site documents, which tells them you’re not a real tech company.
Two users are considered to be concurrent if they’re active within a certain period of time, like a minute.