We're a Software as a Service (SaaS) company.
We offer unlimited users in our free plan and up. I know this is a bit weird. We get asked a lot about this, and people don't seem to believe us when we say that we do not charge for unlimited users. Let me explain so it doesn't feel so strange.
Unlimited users is not the norm
First, let me just get this out there: this is not normal. We know that. Many SaaS companies will charge per user or "seat" because that is where they know they can twist the knife into your wallet. I am not saying this is a bad strategy. In fact, it works very well for many SaaS platforms. Here is an example from Monday.com:
They offer "unlimited users" but also charge you for them. As a project management software, they know that you can see the immediate value of adding users to the platform and therefore can justify paying more for that "feature".
It is a quick way to get upsells and scale pricing plans, which is also beneficial for the users if we hold to the idea that a bigger team means a bigger budget.
More pricing pages
Just to show how common this is and why people don't necessarily believe us, let's look at some more software pricing pages for collaboration tools.
Atlassian's Jira Software, a project management platform for development teams, also charges per user and provides a calculator to help you figure it out.
Invision, a collaborative design tool isn't as straightforward about their user pricing and keeps it hidden. According to their knowledge base: "Once a team grows beyond 5 total users, we offer the option to upgrade to one of our Enterprise plans. - Invision Knowledge Base"
Here is Abstract, another design collaboration tool that also charges per user, per month. (Can you tell that I have been shopping for design software? 🙈).
And finally, Clubhouse, another innovative developer management tool, plainly states that this model helps you scale pricing as your team grows.
These pricing pages are a bit complex in that, all you need to do is choose a feature package and then get going. As you add users, you will be charged more.
How this actually goes down
We could also do this, but in our experience, this doesn't work well from a user perspective. It tends to lead to a bunch of poor practices like the following:
- Using the same login for multiple users to get around adding new users and jumping tiers
- Excluding people from the tool to keep costs low
- Choosing tiers that might forgo useful features for the sake of keeping the team in sync
These things are shameful, maybe, but they happen. We're human. The problem is that these things are hurtful. Using the same login means that keeping track of who did what becomes a serious trust exercise. It is also highly dubious in terms of platform security. While excluding people might sound logical, we've noticed that you usually end up excluding someone who might need access to the information but may not be an active user of the platform. Or maybe they need the information once in a blue moon. This creates unwanted silos and bottlenecks.
Choosing team over features is also not necessarily smart. Sometimes it leads to workarounds and other less than efficient practices.
How we see things
At Plytix, we know that our platform is also highly collaborative. Product Information Management (PIM) is dependent upon many different teams, skill sets, and decision-makers. The person who writes your content is not the same who approves it. The person who sets up your product feeds is also probably different from the person who imports your data. And there is likely a whole set of people who simply need access to the product data without ever editing a thing. Knowing this, we could also adopt a pricing strategy that charges per user.
But we don't.
We believe that our users shouldn't be limited by an arbitrary value indicator (that seems to only be slightly valuable for the person doing the charging). Adding users to our system doesn't cost us money. For example, if you add Stacey from marketing to the PIM, we aren't going to see a massive server spike.
What does cost us money is processing data. For this reason, we base our pricing on the number of SKUs and file storage. Both of these, in our experience, directly impact how much information will be processed through sending product feeds, generating PDF product sheets, and downloading content from a brand portal.
And that's why we don't charge per user. It just doesn't make sense.
Our own pricing journey
Pricing software is difficult. Don't let anyone tell you otherwise. It encompasses behavioral economics, actual economics, psychology, and a lot of this:
We have tried making SKU tiers, storage tiers, feature tiers, and other types of complicated calculations for scaling pricing. But things always felt too overwhelming for both prospects and for our sales team, even if the calculations were operationally sound. Instead, we have landed on a pricing system that is a lot more straightforward, but very different from the rest of the industry.
We only offer 3 types of plans:
We are open about our pricing.
Most PIMs, DAMs, and other similar systems keep this information under wraps. All our major processing features and main value-adding features fall into the PRO category. The PRO also lets you choose add-ons that make it easier to decide which features to use and pay for. We try to be as transparent as possible about pricing, including the prices for each add-on directly on our website.
Our standard plan, however, is designed to help users get their product information in a centralized, standardized format and get them started with basic tools to help grow their operations. For companies with needs outside our plans, we believe pricing should be a conversation. We learn about your needs and we work together to build a tailored plan that works for your company and for ours (we also need to make ends meet in this beautiful capitalist world we live in).
And though we know that pricing is a fickle beast that changes and evolves as we do, at no point do we see ourselves charging for users. Instead of adding value, we would be limiting it.